📚 课程目录第3章数据质量监控体系总览

3. 数据质量监控体系总览：目标、核心架构与分层设计

说实话，很多团队一上来就急着写规则、配告警，结果搞了几个月发现——监控是有了，但业务该出问题还是出问题。为什么？因为没想清楚监控体系到底要解决什么问题。

我个人习惯，在动手搭任何系统之前，先画一张总览图。把目标、架构、分层逻辑理清楚，后面才不会跑偏。这一章，我们就来聊聊数据质量监控体系的全局设计。

说白了，数据质量监控不是为了「监控」而监控。它的终极目标就三个：

我遇到过最典型的反面案例：某团队每天跑 2000 条质量规则，告警邮件堆满收件箱。结果呢？没人看。因为告警太多，大家已经麻木了。监控体系的目标不是「告警数量多」，而是「有效告警覆盖率高」。

所以，你在设计监控体系时，脑子里要始终绷着一根弦：这个监控能帮谁、在什么时候、做什么决策？ 想不清楚，就别急着写代码。

我习惯把监控体系拆成四层。你想想看，从数据产生到最终被消费，中间经过了多少环节？每一层都可能出问题。

层级	名称	核心职责	典型监控对象
L1	源端接入层	数据是否按时、完整到达	采集延迟、文件大小、记录数
L2	加工处理层	ETL 过程是否正确、无异常	空值率、重复率、字段格式
L3	存储模型层	数仓模型数据是否一致、准确	主键唯一性、业务逻辑约束
L4	应用输出层	报表、接口数据是否可用	指标波动、数据时效性

嗯，这里要注意：不是所有层都要同时上。我见过不少团队，一开始就想把四层全铺开，结果资源不够，每层都做得半吊子。我的建议是：先搞定 L1 和 L2，再逐步扩展到 L3 和 L4。

每一层的监控重点不一样，用的手段也不一样。我们一层一层拆开看。

这一层最基础，也最容易出问题。我记得有一次，业务方早上 9 点开会，发现昨天的报表数据是空的。查了半天，原来是上游系统凌晨 3 点挂了，数据没传过来。但我们的监控只检查了「文件是否存在」，没检查「文件是否完整」。

L1 层我建议至少监控这几个维度：

避坑指南：我曾经踩过一个坑——只监控了「数据是否到达」，没监控「数据是否完整」。结果某天数据只到了 80%，系统认为「到达了」，业务方用着用着发现数据对不上。后来我加了一个「数据量级波动检测」，超过 ±20% 就告警。

这一层是 ETL 的主战场。数据进了数仓，经过各种清洗、转换、聚合，最容易引入质量问题。

我个人的经验是，L2 层要重点关注：

举个例子，某电商平台的订单表，突然某天「订单金额」字段的空值率从 0.1% 飙升到 15%。这就是典型的 L2 层问题——上游改了接口，新字段没映射过来。

到了这一层，数据已经进了数仓的模型表。这里的问题往往更隐蔽，比如：

L3 层的监控，我建议用业务规则引擎来做。不是简单的「字段不为空」，而是「如果订单状态是已支付，则支付时间不能为空」这种跨字段的逻辑校验。

这一层直接面向业务用户。监控的重点是：

注意：L4 层的告警要特别谨慎。因为指标波动可能是业务本身的变化，不一定是数据质量问题。我建议 L4 层的告警走「观察-确认-升级」的流程，不要直接触发 P0 告警。

下面这张图，是我在多个项目中沉淀下来的监控体系架构。你可以把它当作一个模板，根据自己团队的实际情况裁剪。

架构图看完了，你可能想问：这么多层，先搞哪层？

我的建议是分三个阶段走：

我个人的经验：很多团队在第二阶段就卡住了。为什么？因为 L3 层的规则需要业务方深度参与，而业务方往往很忙。我的做法是：先挑 3-5 个核心业务场景，和业务方一起梳理规则，跑通后再推广。不要一上来就搞全量。

这一章我们聊了监控体系的总览设计。核心就三件事：