3、核心能力一：数据质量监控（完整性、准确性、时效性、一致性）
数据可观测性，说白了就是给数据系统装一套「仪表盘+报警器」。而数据质量监控，就是这套系统里最核心的传感器。你想想看，如果数据本身都是错的，那后面做的分析、训练出的模型，全白搭。
我个人习惯把数据质量拆成四个维度来监控：完整性、准确性、时效性、一致性。这四个维度，基本覆盖了数据从产生到消费的全生命周期。下面我一个个说，每个都会带上我在项目里踩过的坑。
3.1 完整性：你的数据「缺胳膊少腿」吗？
完整性，就是检查数据有没有缺失。最常见的场景：某张表的某个关键字段，突然出现大量 NULL 值。或者某天本该有 100 万条记录，结果只来了 80 万条。
我在项目中遇到过最典型的一次：某电商大促期间，订单表的「用户ID」字段突然有 30% 是空的。排查下来，是上游埋点系统升级时漏了一个参数。如果没有完整性监控，这批数据直接进报表，GMV 算出来能差好几个亿。
完整性监控的核心指标，我列了个清单：
| 指标 | 说明 | 常见阈值 |
|---|---|---|
| 行数波动率 | 当日行数 vs 历史均值的变化幅度 | ±20% 触发警告 |
| NULL 率 | 关键字段的空值占比 | 超过 5% 报警 |
| 主键唯一性 | 主键或业务键是否有重复 | 重复率 > 0 即报警 |
| 字段缺失率 | Schema 中定义的字段是否都存在 | 缺少必填字段即报警 |
3.2 准确性：数据「说真话」了吗？
完整性只解决了「有没有」的问题，准确性解决的是「对不对」。这是最难搞的一个维度，因为「对」的定义往往很模糊。
举个例子：某张报表显示「今日新增用户 10 万」，但业务方说「不对，我们后台看到只有 8 万」。谁对？可能两边口径不同，也可能数据管道里发生了重复计算或丢失。
我一般把准确性监控分成两类：
- 规则型准确性： 基于明确的业务规则。比如「订单金额必须大于 0」、「年龄字段必须在 0-150 之间」。这些规则写起来简单，但覆盖不了所有场景。
- 统计型准确性： 基于历史分布。比如「某字段的均值突然从 100 跳到 1000」，或者「某个枚举值的占比从 30% 变成 3%」。这种监控能发现规则覆盖不到的「隐性错误」。
我曾经遇到过一个坑：某数据管道在 ETL 过程中，因为类型转换错误，把「金额」字段的数值全部放大了 100 倍。规则型监控没触发（因为金额 > 0 这个规则依然成立），但统计型监控发现「金额均值」从 200 跳到了 20000，立刻报警。嗯，这就是统计型监控的价值。
3.3 时效性：数据「迟到」了怎么办？
时效性，就是数据能不能在规定时间内到达。实时流处理里，这通常叫「延迟」；离线批处理里，这通常叫「产出时间 SLA」。
我见过最夸张的情况：某离线报表每天凌晨 2 点就该出，结果因为上游任务阻塞，拖到早上 10 点才跑完。业务方等着数据开晨会，结果会都开完了数据还没出来。这就是典型的时效性问题。
时效性监控的几个关键点：
- 定义 SLA： 明确每条数据管道或报表的「最晚产出时间」。比如「每日销售报表必须在 8:00 前产出」。
- 监控延迟： 实时流处理中，监控每条消息从产生到被消费的时间差。离线任务中，监控任务的实际完成时间 vs 预期完成时间。
- 设置缓冲： 不要等 SLA 超时了才报警。我习惯设置「预警线」，比如 SLA 是 8:00，那 7:30 还没跑完就发一条黄色预警。
这里有个常见的误区：很多人只监控「任务是否成功」，不监控「任务是否按时」。任务跑成功了，但跑了 6 个小时，这算成功吗？在时效性监控里，这算失败。
3.4 一致性：不同系统「口径统一」吗？
一致性，是四个维度里最容易被忽视的。它关注的是：同一份数据，在不同系统、不同时间点、不同计算方式下，结果是否一致。
我举个例子：你的实时大屏显示「今日订单数 10 万」，但离线报表跑出来是「9.5 万」。差了 5000 单。为什么？可能实时系统包含了未支付订单，离线系统只统计已支付订单。这就是口径不一致。
一致性监控的常见场景：
| 场景 | 对比对象 | 常见差异原因 |
|---|---|---|
| 实时 vs 离线 | 同一指标的实时值与离线值 | 口径不同、时间窗口不同、去重逻辑不同 |
| 上游 vs 下游 | 源表与目标表的汇总值 | ETL 逻辑错误、数据丢失、重复计算 |
| 不同数据源 | 两个独立系统对同一实体的描述 | 主数据不一致、同步延迟 |
我曾经踩过一个坑：某金融项目里，风控系统用的用户标签和推荐系统用的用户标签，来自两个不同的数据管道。结果同一个用户，在风控系统里被标记为「高风险」，在推荐系统里却是「优质用户」。这就是典型的一致性灾难。后来我们强制要求所有系统消费同一份「用户标签主表」，才解决了这个问题。
3.5 四个维度的协同：一张图看懂
这四个维度不是孤立的。它们共同构成了数据质量的「四道防线」。我画了一张图，帮你理清它们之间的关系：
从这张图你可以看到，数据管道是中心，四个维度从不同方向对它进行「体检」。完整性检查数据有没有到齐，准确性检查数据对不对，时效性检查数据到得及不及时，一致性检查数据在不同地方是不是「说同一句话」。
3.6 落地建议：从哪里开始？
如果你刚开始搭建数据质量监控体系，我建议按这个顺序来：
- 先做完整性监控。 这是最容易上手的，也是性价比最高的。先保证数据不缺、不丢。
- 再做时效性监控。 确保数据能按时产出。这一步能解决大部分「数据出不来」的投诉。
- 然后做准确性监控。 从简单的规则型开始，逐步加入统计型监控。
- 最后做一致性监控。 这一步需要跨系统协作，通常是在数据体系相对成熟后才开始做。