目录
跑了几场面试，数据质量怎么监控是经常被问到的问题，仅次于自我介绍。
因为数据行业发展了几年，数仓大体都建设成型了，数仓建设的方法论大家总结的也都差不多了，现在大家都开始关心数据质量。
在大家心目中，一个合格的数仓要能产出及时、准确的数据，且对数据的质量有自检的过程，做到没问题，或先于别人发现问题。
所以数据质量监控是数仓建设的一个重要部分。
之前的工作中，我总结了一套数据质量监控方法论，在这记一下。
监控分为多个层次，从大到小说。
一、任务基线级别
凡是数仓ETL任务，都有上游和下游，就像B表必须依赖于A表产出，C表又依赖于B表产出。
所有的任务，按上下游的关系组织起来，会形成一个有向无环图，举个例子如下图：
假如E表非常重要（例如是线上服务表），需要对它进行基线级别的监控，把E表配置进基线监控任务后，E表的所有上游就都会进入基线的监控范围。
在上图中，
如果是E表配置基线，基线会同时监控根节点及ABCD表。
如果是D表配置基线，基线同时会监控根节点及AB表。
基线要监控什么呢？主要分为两个方面，所有任务运行时长及结果任务产出时间。
所有任务运行时长：假如A表每天的运行时长是1h，今天突然变成3h了，那么监控系统则会标志此 任务运行异常，会报警给基线负责人和任务负责人。
结果任务产出时间：如果和下游签订了SLA协议，规定E表每天7点前产出，那么如果E表今天6点30还没产出，基线直接预警给基线负责人和任务负责人，预警时间一般会比产出时间要提前一点，给检修任务留出时间。
二、任务级别 & 表级别
对于一个成熟的数仓来说，绝大多数情况下，表和ETL任务都是一一对应的。
上一点中，基线监控了一条任务流，监控强度是最大的，那么仅次于基线的就是单个任务的监控。
单个任务监控什么呢？主要三方面：任务运行时长、任务产出时间、表产出大小。
任务运行时长：某任务平时1h能运行完，今天突然变成3h，那么认为异常，告警给任务负责人。
任务产出时间：某任务平时7点产出，今天7点没产出，那么认为异常，告警给任务负责人。
表产出大小：某表平时每天产出大小1T，今天突然变成500G了，那么认为异常，告警给表负责人。
三、字段级别
任务定时产出，表大小也符合预期，那接下来，我们就要做更细致的监控了。
即字段级别的监控。
字段级别的监控一般通过DQC任务实现（ DQC = Data Quality Center，数据质量中心），可监控的内容细致也琐碎，我把字段监控分为两种类型，对指标字段的监控和对维度字段的监控。
1. 对指标字段的监控
对于指标字段，我们一般关心它的均值、最大、最小、中位数等。
指标字段，我们关心它的波动程度，一般来说，会把今天的指标与昨天（日）、近7天的平均值（周）、近30天的平均值（月）做比较，看波动率，波动率超过某个阈值，则告警给DQC任务配置的人（因为配置任务的人最关心这个指标数据的质量）。
2. 对维度字段的监控
维度字段，我们监控三个方面：维度覆盖率、维度占比、维度下指标的波动。
维度覆盖率：例如性别字段，男女，预期覆盖率90%，如果某天数据低于90%，则预警给DQC任务配置的人。
维度占比：例如男女对应的记录条数占比，如果今天男性40%、女性50%、未知10%，以往男性占60%、女性占30%、未知占10%（以往可能是昨天、7天平均、30天平均等）我们有理由怀疑数据质量有问题，预警给DQC任务配置的人。
维度下指标的波动：例如某应用（如微信）男女的平均使用时长，同样可与昨天、7天平均、30天平均作对比，有问题预警给DQC任务配置的人。
四、报表级别监控
报表级别监控一般是把上述的某些监控内容可视化，并广播给项目组所有的人，让大家更直观地看到数据的变化。
报表监控一般用趋势图，陡升陡降在趋势图中会非常明显地看到。
五、总结
总结一下，列个表：
————————————————
版权声明：本文为CSDN博主「疯狂的土豆1652」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_33310807/article/details/129016896