数据质量监控
总结
| 记忆点 | 内容 |
|---|---|
| 四维度 | 完整性、准确性、一致性、及时性 |
| ETL卡点 | 主键唯一+行数波动+NULL率，不通过不写入 |
| SLA监控 | 核心报表产出时间，逐级告警，留buffer |
| 指标巡检 | 自动校验核心指标的合理性 |
| 溯源四步 | 确认范围→追血缘→比对上下游→修复复盘 |
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
进阶 | 大数据面试 · 数仓建模系列
| 面试真题 你们数仓的数据质量是怎么保证的？有什么监控和告警机制？ |
|---|
质量四维度
| 维度 | 定义 | 监控方式 |
|---|---|---|
| 完整性 | 数据有没有漏 | 行数对比、NULL率检查 |
| 准确性 | 数据对不对 | 关键指标波动、逻辑校验 |
| 一致性 | 多处数据一不一样 | 跨表/跨层对数 |
| 及时性 | 数据准不准时 | 分区产出时间监控 |
| Wood的实战经验 我在短剧出海公司，数据质量最常出的问题是「及时性」。海外数据源有时差+网络延迟，上游数据经常比预期晚1-2小时到达，导致下游报表空白。为了解决这个问题，我们把核心报表的调度依赖从「固定时间触发」改成了「数据就绪触发」——上游分区产出成功后才触发下游任务，而不是固定凌晨3点开跑。 |
|---|
三层监控体系
第一层：ETL卡点（写入前拦截）
不通过就不写入下游，从源头拦截问题。核心检查项包括：
主键唯一性检查——GROUP BY primary_key HAVING COUNT(*) > 1，有结果就阻断写入。
行数波动检查——今天的行数和昨天对比，波动超过20%告警。这个阈值根据业务特点调整，比如电商大促期间可以放宽到50%。
关键字段NULL率检查——核心字段如user_id、amount的NULL率超过阈值就告警。
| -- 主键唯一性检查 SELECT user_id, COUNT(*) FROM dwd_user WHERE is_current = 1 GROUP BY user_id HAVING COUNT(*) > 1; -- 有结果 -> 阻断写入，告警通知 -- 行数波动检查 WITH today AS (SELECT COUNT(*) AS cnt FROM fact WHERE dt='${today}'), yest AS (SELECT COUNT(*) AS cnt FROM fact WHERE dt='${yesterday}') SELECT ABS(today.cnt - yest.cnt) * 1.0 / yest.cnt AS change_rate FROM today, yest; -- change_rate > 0.2 -> 告警 |
|---|
第二层：产出SLA监控
核心报表的数据必须在每天8:00 AM前产出。7:30未完成→黄色预警（通知数据开发）；8:00未完成→红色告警（通知数据开发+业务方）；8:30未完成→升级告警（通知Leader）。
经验：SLA要留buffer。如果业务方8点看报表，你的SLA设7:30，留30分钟处理突发情况。不要把SLA设成8:00——那意味着一旦出问题就没有任何缓冲时间。
第三层：指标巡检（准确性兜底）
每天自动跑一遍核心指标的合理性检查。比如DAU不可能为负数，GMV不可能比昨天翻10倍，支付率不可能超过100%。这些规则看似简单，但能兜住很多意想不到的问题。
问题溯源四步法
数据质量告警了，怎么快速定位问题？
第一步：确认影响范围——哪些表/报表受影响？核心还是非核心？
第二步：追数据血缘——从告警表往上游追，找到第一个出问题的节点。
第三步：比对上下游——上游行数正常→问题在当前层ETL逻辑；上游就不正常→继续往上追。
第四步：修复+复盘——修数据→通知业务方→写复盘文档→补监控规则。
| Wood的实战经验 我经历过一次严重的质量事故：广告ROI报表数据突然翻了3倍。按血缘往上追，发现是ODS层接入的广告平台API改了字段名，我们的解析逻辑没更新，金额字段解析到了展示次数字段上。一个字段名的变化导致整条链路数据全错。 从那以后ODS层加了字段Schema校验——每次接入数据先检查字段名和类型是否和预期一致，不一致就告警阻断，不让脏数据流入下游。这一个小改动避免了后续好几次类似的问题。 |
|---|
| 面试加分提示 这题分三个层次回答： 「我们建了三层质量监控体系。第一层是ETL卡点，每个任务写入前校验主键唯一性和行数波动，不通过不写入下游。第二层是产出SLA监控，核心报表必须在8:00前产出，7:30未完成开始逐级告警。第三层是指标巡检，每天自动校验核心指标的合理性——比如DAU不能为负，GMV波动不能超过阈值。」 「出过一次事故：广告平台API改了字段名，ROI翻了3倍。从那以后ODS层加了Schema校验，上游字段变化第一时间告警。」 |
|---|