数据质量校验排在最后一步 报表发出去才发现空值 40%

日报早上 9 点发出去，运营发现转化率是 0。回头查 ETL，dwd 表里 40% 的行 device_id 是空值，校验脚本排在整条链路的最后。碰到这种情况，我一般先确认改动有没有真的生效。

原因不复杂，质量校验放在末尾，前面的脏数据一路传下来，到校验时已经写进了对外表。校验失败也只打一行日志，没有阻断发布。上游字段改名这种变更，正好会造出大批空值。

「数据质量校验滞后」这个问题文档写得含糊，实际行为以当前版本为准，别照旧版本的结论套。别只看报错的最后一行，往上看几行，真正的起因通常在上面。

SELECT COUNT(*) total,
       SUM(device_id IS NULL) null_cnt,
       ROUND(SUM(device_id IS NULL)/COUNT(*), 4) ratio
FROM dwd_order WHERE dt = '2026-03-01';

同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。

具体做法是，把空值和枚举校验前移到 ods 入仓那一步；关键字段加非空约束 让脏数据在写入时就失败；校验不通过直接中断任务 不要只告警；每天跑一次分布对比 空值率突变就报警。

最后用这个标准收尾，空值率从 40% 降到 0.2% 日报转化率回到正常数值。