赞
踩
所以数据质量监控是数仓建设的一个重要部分。
之前的工作中,我总结了一套数据质量监控方法论,在这记一下。
监控分为多个层次,从大到小说。
凡是数仓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,数据质量中心),可监控的内容细致也琐碎,我把字段监控分为两种类型,对指标字段的监控和对维度字段的监控。
对于指标字段,我们一般关心它的均值、最大、最小、中位数等。
指标字段,我们关心它的波动程度,一般来说,会把今天的指标与昨天(日)、近7天的平均值(周)、近30天的平均值(月)做比较,看波动率,波动率超过某个阈值,则告警给DQC任务配置的人(因为配置任务的人最关心这个指标数据的质量)。
维度字段,我们监控三个方面:维度覆盖率、维度占比、维度下指标的波动。
维度覆盖率:例如性别字段,男女,预期覆盖率90%,如果某天数据低于90%,则预警给DQC任务配置的人。
维度占比:例如男女对应的记录条数占比,如果今天男性40%、女性50%、未知10%,以往男性占60%、女性占30%、未知占10%(以往可能是昨天、7天平均、30天平均等)我们有理由怀疑数据质量有问题,预警给DQC任务配置的人。
维度下指标的波动:例如某应用(如微信)男女的平均使用时长,同样可与昨天、7天平均、30天平均作对比,有问题预警给DQC任务配置的人。
报表级别监控一般是把上述的某些监控内容可视化,并广播给项目组所有的人,让大家更直观地看到数据的变化。
报表监控一般用趋势图,陡升陡降在趋势图中会非常明显地看到。
总结一下,列个表:
监控级别 | 监控内容 | 对比指标 | 预警对象 |
---|---|---|---|
任务基线级别 | 所有任务运行时长 | 运行时长 vs 昨天运行时长 | 基线负责人 & 任务负责人 |
结果任务产出时间 | 产出时间 vs 基线规定时间 | 基线负责人 & 任务负责人 | |
任务级别 & 表级别 | 任务运行时长 | 运行时长 vs 昨天运行时长 | 任务负责人 |
任务产出时间 | 产出时间 vs 任务规定产出时间 | 任务负责人 | |
表产出大小 | 表当日分区大小 vs 昨日分区大小 | 表负责人 | |
字段级别 | 指标字段的监控 | 均值 vs 昨天、7天内、30天内的均值 | 配置DQC任务的人 |
最大值 vs 昨天、7天内、30天内的最大值 | 配置DQC任务的人 | ||
最小值 vs 昨天、7天内、30天内的最小值 | 配置DQC任务的人 | ||
中位数 vs 昨天、7天内、30天内的中位数 | 配置DQC任务的人 | ||
维度字段的监控 | 维度覆盖率 vs 昨天、7天内、30天内的均值 | 配置DQC任务的人 | |
维度占比 vs 昨天、7天内、30天内的均值 | 配置DQC任务的人 | ||
维度下指标 vs 昨天、7天内、30天内的均值 | 配置DQC任务的人 |
以上是基于我个人经验总结出来的数据质量监控方法,如果有遗漏的话,欢迎补充呀。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。