4. 数据质量保障体系总览：事前预防、事中监控、事后修复

聊到数据质量保障，很多人第一反应就是「出问题了赶紧修」。但说实话，这种救火式的做法，在大数据量、高时效的流批一体架构里根本行不通。你想想看，一个实时管道跑着几百张表，凌晨三点突然告警说数据延迟了，你爬起来查半天，发现是源头字段类型变了——这种痛，我经历过太多次。

所以这一章，我想跟你聊聊一个更体系化的思路：事前预防、事中监控、事后修复。这不是三个孤立的阶段，而是一个闭环。我习惯把它叫做「质量保障的三角模型」。

4.1 事前预防：把问题扼杀在摇篮里

事前预防，说白了就是在数据进入管道之前，先把规矩立好。我见过太多团队，上线前不检查 Schema，结果生产环境跑着跑着，某个字段从 int 变成了 string，整个管道直接崩掉。

我个人习惯把事前预防拆成三个层次：

• Schema 强校验：源头表结构变更时，必须经过审批和兼容性检查。比如新增字段允许，但删除字段必须走变更流程。
• 数据血缘标注：每张表、每个字段的上下游关系要提前画清楚。这样出了问题，你能快速定位影响范围。
• 质量规则预定义：在数据接入之前，就定义好「非空率」「唯一性」「值域范围」等规则。规则不是上线后再加的，而是设计时就定好的。

4.2 事中监控：实时感知，快速响应

事前做得再好，也挡不住线上环境的各种幺蛾子。网络抖动、上游服务超时、数据倾斜……这些事我几乎每周都会遇到。所以事中监控必须做到「实时感知，快速响应」。

这里有几个关键点：

1. 实时指标计算：延迟、吞吐量、数据量波动、空值率……这些指标要按分钟级甚至秒级计算。不能等第二天跑完离线任务才发现问题。
2. 多级告警策略：不是所有异常都要半夜打电话。我一般分三级——P0 是管道中断，直接电话；P1 是数据延迟超过阈值，发群消息；P2 是轻微波动，记录日志即可。
3. 异常自动熔断：当某个环节连续出现质量问题时，系统应该自动暂停该链路，避免脏数据扩散。嗯，这里要注意，熔断后要保留现场，方便事后排查。

4.3 事后修复：兜底方案，闭环改进

不管你怎么预防、怎么监控，总会有漏网之鱼。事后修复不是简单的「把数据修好」，而是要形成闭环。

我把它分成三步：

举个例子。有一次我发现某个实时表的数据量突然少了 30%。查了半天，发现是上游的一个过滤条件被误改了。修复数据只花了 2 小时，但真正花时间的是后续的改进：我在事前预防里加了一条「过滤条件变更必须审批」的规则，同时在事中监控里增加了「数据量波动超过 20% 自动告警」的指标。

4.4 三者如何协同？

你可能会问：这三个阶段怎么配合？我画了一张图，其实就是上面那个三角模型。简单来说：

• 事前预防 输出规则和基线，给事中监控提供判断依据。
• 事中监控 发现异常后，触发事后修复流程。
• 事后修复 的根因分析，反过来优化事前预防的规则。

这个闭环跑得越久，你的数据质量体系就越成熟。刚开始可能每天都有问题，但坚持跑三个月，你会发现告警越来越少，修复越来越快。