前几篇把分层、建模、指标讲完了。模型和口径都定好之后还有一个问题绕不开怎么保证每天跑出来的数据是对的数据质量不是一次性验收通过就完了。源系统会改、计算任务会偶发报错、业务规则会变——质量是一个持续运营的事不是一次性的检查。质量问题的三层分级数据质量问题按影响面可以分为三层表/分区级 → 数据到没到 字段级 → 数据对没对 业务逻辑级 → 数据能不能用越往下越难发现出问题的代价也越大。第一层表/分区级 —— 数据到没到监控两件事数据按时到了没有数据量是否正常。1. 数据及时性大多数数仓任务按天跑凌晨产出前一天的数据。如果某个分区的数据在预期时间点还没到说明上游出了问题——源系统没产出、ETL 任务挂了、依赖的上游表没更新。监控方式定时检查最新分区的ds是否等于当前日期 - 1或按业务 SLA 约定的时间窗口。到了约定时间还没产出告警。2. 数据量波动今天的分区 200 万行昨天 300 万行少了 33%——大概率有问题。波动监控不是死板地设阈值是看趋势单日环比波动超过 30%预警连续 3 天波动超过 20%升级告警人工介入分区行数直接为 0 或接近 0直接告警不需要等趋势周中和周末的量不一样月初和月末也不一样。所以波动阈值最好分时段设定工作日和节假日各一套否则周末正常的数据下降也会触告警。3. 分区数据是否重复同一个分区跑了两次数据写了两遍——行数翻倍所有聚合指标全偏。监控方式是检查分区ds 业务主键是否唯一。如果主键重复意味着数据被重复写入。场景举例某品牌的VOC数据每天凌从 ODS 写入 DWD。有一天上游 API 超时ODS 里少了 40% 的数据DWD 正常跑完行数骤降。由于 DWD 层没有配行数波动监控直到三天后业务方发现差评率异常下降才倒查找到 ODS 数据漏了。如果当时在 DWD 层配了行数环比波动 30% 告警当天凌晨就会发现。第二层字段级 —— 数据对没对表级监控告诉你有数据字段级监控告诉你数据能不能用。1. 非空率业务上不应该为空的字段主键、核心度量如果空值比例突变说明源数据或清洗逻辑出了问题。不是所有字段都要监控非空率——业务上允许为空的字段备注、可选属性空值是正常的。只监控不应该为空的核心字段。2. 枚举值范围状态字段的可取值是有限的已支付已取消已退款。哪天突然出现一个已摧毁要么是源系统改了枚举但没有通知数据团队要么是数据在传输过程中出错了。监控方式维护一份字段的合法枚举值清单。每天扫描出现不在清单内的值就告警。3. 格式一致性这个监控优先做高频查询字段日期、金额、编码低频字段优先级低。例如日期字段规定全是yyyy-MM-dd格式。如果出现了2025/1/5或20250105的混入说明某个数据源没有按约定的格式输出或者清洗逻辑没覆盖到新的来源。4. 数值合理性一个产品评分字段取值范围 1-5。出现 999 或者 -1要么是源数据出错了要么是空值补了不合规的占位符。数值范围监控就是兜底——合法枚举以外的异常值也能发现。场景举例某 VOC 数据的score字段正常范围是 1-5。有一天出现了一批score 0的数据。排查后发现是某个渠道的评分接口改版原接口在用户未评分时返回空值清洗后补默认值 3新接口改为返回 0。如果不是字段级的数值范围监控兜底这批 0 分的记录会一直混在正常数据里拉低全量均分。第三层业务逻辑级 —— 数据能不能用前两层发现的是明显的错第三层发现的是隐藏的错。1. 跨表一致性订单表和支付表的金额理论上应该对得上。如果两边的汇总值差异超过了一个阈值比如 1%要么是取消单没同步要么是退款没更新要么是某一边漏跑了一天的数据。跨表一致性监控不是逐行比——数据量太大性能扛不住。做法是按维度汇总之后比SUM(订单表.金额) GROUP BY 日期 vs SUM(支付表.金额) GROUP BY 日期差异在容忍范围内 → 通过。差异超出容忍范围 → 告警人工排查。2. 业务规则校验不是所有的正确数据都是有意义的数据。比如反馈备注字段里全是无意义字符、或者是明显的测试数据内容为test或测试——字段级监控不会告警非空、格式也没问题但业务上这些数据不该入表。这层规则需要和业务方一起定——什么算无效数据、什么只是低质量但不影响使用。规则太宽松漏掉问题太严格干扰太多。3. 逻辑矛盾同一张表里出现了订单状态 已支付, 支付时间 IS NULL——这两个字段的组合在业务上不可能存在。某个环节出了错。这类检查写起来简单WHERE 条件1 AND NOT 条件2难在事先想到有哪些矛盾的组合。通常是先踩坑再补规则。场景举例某次排查发现某天的已退款金额比订单金额还大——退款金额汇总 订单金额汇总。这是业务逻辑上不可能出现的情况。排查后发现是因为退款表里混入了部分非退款的负收入流记录来源系统在退款表里同时写入退款明细和财务冲销记录字段含义不同但都在同一张表汇总时被当成退款一起算进去了。修复方式是在 DWD 层加业务类型过滤退款表和冲销表分表。三级监控的配置原则层级异常类型动作覆盖范围表/分区级数据迟到告警 自动触发补跑全部表表/分区级行数波动异常告警核心表表/分区级分区重复阻断下游全部表字段级非空率异常告警核心字段字段级枚举值超范围阻断关键维度字段字段级数值越界告警度量字段业务逻辑级跨表不一致告警 人工排查关键业务链路业务逻辑级逻辑矛盾告警常用查询字段几点说明阻断发现异常后暂停下游所有依赖任务。只有当错误会直接导致下游数据全错时才用重复分区、核心枚举值出界。阻断太多会让整条链路停了等排查影响业务方按时看数据。告警发通知但不阻断。大部分质量异常用告警就够了——让负责人排查同时下游任务继续跑。核心表/核心字段由业务优先级决定不是所有表和字段都值得配同等密度的监控。覆盖面和告警噪音之间要平衡监控太多告警太多人会麻木监控太少漏掉问题没人知道。从一次性验收到常态化运营一次性验收在 ETL 任务上线前对历史数据做全量跑数和对账。验证行数是否和源系统一致关键字段值是否和源系统一致聚合指标是否和已知基准一致上线前验收通过代表数据在当下没问题。常态化运营上线后数据每天在变上游每天可能有改动问题是持续的。常态化运营要做三件事1. 质量任务按天自动跑和 ETL 任务一样做调度每天凌晨数据跑完后自动触发质量检查。不依赖人工记得去跑。2. 规则持续迭代新加的字段、新的数据源、新的枚举值——质量规则需要跟着迭代。不是上线时配一套规则就永远不动了。每踩一个坑就补一条规则。3. 问题闭环发现问题 → 告警通知 → 定位原因 → 修复数据 → 补规则防止复发每一步都需要可追溯。尤其是第四步修复数据不是改 DWD 表的一个字段就完了——上游 ODS 需要修复吗下游 DWS 和 ADS 需要重跑吗修复动作的范围和顺序要明确否则修了一个地方别的地方还是错的。总结质量监控分三层到没到表/分区级→ 对没对字段级→ 能不能用业务逻辑级阻断和告警有边界——只有会直接导致下游全错的问题才触发阻断覆盖面和告警噪音要平衡监控配太多和配太少同样危险一次性验收只保证当下常态化运营才是真正在管质量每踩一个坑补一条规则质量体系是长出来的不是设计出来的怎么让数据质量监控规则配置自动化且能够兼顾不同表的一般性与特殊性一网打尽我还没有很好的思路期待讨论交流