数据质量规则：脏数据不是技术细节，是业务风险

数据质量规则脏数据不是技术细节是业务风险数据分析里最怕的不是 SQL 写错而是没人知道数据已经脏了。看板还在更新指标还在展示报告还在发但底层口径、延迟、重复、缺失已经悄悄出问题。脏数据不是技术细节它会直接变成业务误判。数据质量规则要尽早建设哪怕一开始很简单。先把关键表、关键字段、关键指标守住比等事故后全量补治理更现实。一、质量规则先覆盖关键链路不要试图第一天把所有表都治理完。先找核心链路用户、订单、支付、商品、内容、曝光、点击。对这些表建立基础规则非空、唯一、范围、枚举、波动、延迟。flowchart TD A[核心数据表] -- B[字段规则] A -- C[行数波动] A -- D[产出延迟] A -- E[指标一致性] B -- F[质量报告] C -- F D -- F E -- F数据质量不是为了让平台好看而是为了让分析结论有地基。为什么数据质量是最容易被先放一放的基础建设因为脏数据的危害有延时性——今天数仓里订单行数少了 10%看板上转化率可能只是轻微下降没人会立刻警觉。但三天后运营团队基于下降的转化率做了一个投放策略调整多花了 50 万预算但效果更差——这时候才发现原来不是业务问题是数据少了一截。数据质量的每一笔债都会在未来的业务决策中偿还而且利息很高。先守核心链路不是偷懒而是把有限的 QA 资源花在最能避免重大事故的地方。二、规则要写成可执行配置质量规则不能只写在文档里。它应该能被调度系统执行失败后能告警。checks: - table: dwd_order_pay_di partition: dt rules: - type: not_null column: order_id - type: unique column: order_id - type: range column: pay_amount min: 0 - type: row_count_change max_drop_rate: 0.3这类规则很基础但非常有效。订单 id 为空、支付金额为负、行数突然下降这些问题应该在数据层被发现而不是等业务同学截图问今天怎么怪怪的。为什么 YAML 配置化比文档里写的质量规范有效十倍文档里写订单 ID 不能为空这只是一种声明。配置化的规则意味着每天凌晨数据产出后调度系统自动执行这 4 条校验任何一条失败自动发告警。不需要任何人记得去检查系统替所有人记着。而且配置可以版本控制、可以 Review、可以在新表接入时复制一份改改就行。反观文档里的规范三个月后已经没人知道这文档在哪了。把规则写成代码 把规范变成约束。三、SQL 校验要保留证据每次质量检查都要保存结果检查时间、分区、规则、通过与否、异常样本。没有样本排查会很痛苦。SELECT order_id, pay_amount FROM dwd_order_pay_di WHERE dt 2026-07-02 AND (order_id IS NULL OR pay_amount 0) LIMIT 100;异常样本不要全量写进告警但要能在后台查看。告警负责提醒质量报告负责排查。四、质量分级决定处理方式不是所有质量问题都要半夜叫人。核心收入表缺分区严重低频画像字段少量缺失可以次日处理。质量规则要有等级。severity: P0: 核心指标不可用或严重错误 P1: 核心维度异常影响主要分析 P2: 非核心字段质量下降有分级团队才不会被低优问题淹没也不会错过真正要停报表的事故。为什么质量分级是避免狼来了效应的关键如果每次质量检查失败都发一样的告警——核心收入表缺字段和画像标签表少 0.1% 的数据都用红色感叹号推送到群里——不出两周大家就会开始忽略所有质量告警。P0/P1/P2 分级的作用是P0 直接打电话核心指标不可用必须立刻处理P1 发群消息影响分析但不影响对外报表P2 记日志本周内修复即可。分级之后团队知道收到 P0 告警 放下手头的事立刻处理而不是又是质量告警先不管了。告警的信用是一点点攒出来的。踩坑提醒坑1规则只在建表时跑一次之后忘了更新— 业务在变昨天的枚举值范围今天可能增加了一类比如新增了一个支付渠道。规则也需要随表结构更新建议规则文件和表的 DDL 放在一起 Review。坑2行数波动阈值设太死周末和大促期不停报警— 如果max_drop_rate: 0.3是全时段统一阈值周末流量下降 40% 可能触发 P0。正确做法是按工作日/周末/大促分设不同的波动阈值或者用同环比替代绝对值阈值。坑3质量失败后只看告警不看影响链路— 某张表质量失败了依赖它的 5 张下游表和 3 个看板都会出问题。除了告警还应该做影响分析自动标出依赖链路通知对应报表 owner避免他们基于脏数据发日报。五、总结数据质量规则不是锦上添花而是分析工作的底线。先守关键链路规则配置化保留异常证据并按严重程度处理。数据不会自己变干净。有人把质量规则写进系统业务决策才不会踩在松动的地板上。