下游报表数据异常，你怎么快速定位问题？
先说结论
数据异常的排查思路是：从下游往上游逐层追溯。就像医生看病：先看症状（报表哪里不对），再做检查（逐层核实数据），最后定位病因（找到出问题的那一层）。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
这是数据开发的日常——业务方突然发消息说“今天的ROI报表数据不对”，你要在最短时间内定位到底是哪层哪个作业出了问题。我在每家公司都经历过无数次这种场景，今天把我的排查方法论和防御体系讲清楚。
业务场景：广告花费比昨天少了40%
有一天早上运营同事发消息说：“今天的广告花费报表比昨天少了40%，是不是数据出问题了？”我的排查过程如下：
排查五步法
第一步：确认异常现象
先搞清楚“什么数据不对”。查ADS报表表，发现不是所有渠道都少，只有TikTok渠道的花费少了60%。其他渠道正常。这说明问题不是全局的，而是特定渠道的。
第二步：检查ADS层
看ADS层的作业是否正常执行、逻辑是否正确。我查了作业日志，作业正常完成，没有报错。说明问题不在ADS层本身。
第三步：往上追溯DWS/DWD层
-- 检查DWD层TikTok渠道的数据量
SELECT dt, COUNT(1) AS cnt
FROM dwd_ad_cost
WHERE channel = 'TikTok' AND dt IN ('2025-03-13', '2025-03-14')
GROUP BY dt;
-- 结果：
-- 2025-03-13 5800万
-- 2025-03-14 2300万 ← 少了60%，问题在DWD或更上游第四步：检查ODS层（原始数据）
查ODS层，发现同样少了60%。说明问题不是ETL逻辑导致的，而是数据源本身就没拉到。
第五步：检查数据采集链路
最终定位原因：TikTok的广告API的拉取作业在凌晨3点执行时超时失败，重试后只拉到了部分数据。修复方案：调大API拉取的超时时间，增加数据完整性校验。
我怎么建数据质量防御体系的
每次等业务方发现问题再排查，太被动了。我在出海硬件公司建了一套自动化监控：
① 行数波动监控： 每张核心表每天的行数和昨天、上周同期对比，波动超过20%自动发告警。
-- 行数监控SQL示例
SELECT
today.tbl, today.cnt AS today_cnt, yest.cnt AS yesterday_cnt,
ROUND(ABS(today.cnt - yest.cnt) / yest.cnt * 100, 1) AS change_pct
FROM
(SELECT 'dwd_ad_cost' AS tbl, COUNT(1) AS cnt
FROM dwd_ad_cost WHERE dt='2025-03-15') today,
(SELECT 'dwd_ad_cost' AS tbl, COUNT(1) AS cnt
FROM dwd_ad_cost WHERE dt='2025-03-14') yest
HAVING change_pct > 20; -- 超20%告警② 关键字段NULL率监控： user_id、ad_id等关键字段的NULL占比超过5%告警。
③ 跨层对账： DWD层和ADS层的核心指标（总花费、总收入）做交叉核验，不一致告警。
有了这套体系后，多数数据问题在业务方发现之前我们就已经知道了。埋点数据质量问题减少60%。
总结
排查思路：确认现象→逐层追溯→定位根因。防御体系：行数波动 + NULL率 + 跨层对账。面试的时候能说清楚“如何救火”和“如何防火”，说明你不只是执行者，还是建设者。
下一篇聊一个每个写Hive ETL的人都踩过的坑：动态分区插入时有哪些致命的坑？最危险的那个能把你整张表删干净。
你们的数据质量监控是怎么做的？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长