4. 实验数据采集端的完整性保障
数据校验这件事，说起来简单，做起来其实挺讲究。我见过不少团队，一上来就在ODS层搞全量校验，结果跑了一晚上没跑完，第二天ETL全挂了。说白了，校验策略得跟着数仓的层次走，每一层有每一层的脾气。
我个人习惯把校验策略拆成三个维度来设计：分层维度、增量与全量维度、离线与实时维度。这三个维度交叉起来，基本能覆盖90%以上的校验场景。
4.1 分层校验策略
数仓分几层，校验就分几层。每一层关注的点不一样，校验的粒度、频率、手段也都不一样。
4.1.1 ODS层校验：源头把关
ODS层是数据进入数仓的第一道门。这一层的校验，核心就两个字：保真。数据从源系统拿过来是什么样，ODS层就应该是什么样，不能丢、不能改、不能乱。
ODS层校验重点：
- 记录数校验：源表多少条，ODS表多少条，一条不能少
- 唯一键校验：主键不能重复，不能有空值
- 字段完整性校验：必填字段不能为空
- 时间戳校验：增量时间戳不能出现断层或回退
我记得有一次做电商项目，ODS层每天从MySQL同步订单表。有一天突然发现记录数对不上，源表有120万条，ODS只有118万条。查了半天，发现是binlog解析的时候丢了一条delete操作。从那以后，我坚持在ODS层必须做记录数+主键的双重校验，缺一不可。
4.1.2 DWD层校验：清洗与标准化
DWD层是数据从"原始"变成"干净"的地方。这一层的校验，核心是质量。数据经过清洗、去重、类型转换、维度退化之后，有没有引入新的问题？
嗯，这里要注意。DWD层的校验不能只盯着记录数了，因为清洗过程可能会过滤掉脏数据，记录数减少是正常的。那校验什么呢？
- 数据格式校验：日期字段是不是标准格式？金额字段有没有负数？
- 业务逻辑校验：订单金额 = 单价 × 数量，这个等式成立吗？
- 维度关联校验：事实表的外键，能不能在维度表里找到对应的记录？
- 去重校验：同一个业务主键，不应该出现两条记录
我的小技巧：在DWD层，我习惯建一个"数据质量监控表"，把每一张表的校验规则、校验结果、异常记录数都记录下来。这样出了问题，一眼就能看到是哪张表、哪个规则挂了。
4.1.3 DWS层校验：聚合的正确性
DWS层是轻度汇总层，数据从明细变成了聚合。这一层的校验，核心是一致性。聚合结果对不对？跟明细层对得上吗？
说白了，DWS层的校验就是"向上对口径，向下对明细"。我建议做两种校验：
- 向上校验：DWS层的汇总数据，跟ADS层（或者报表）的指标对一下，看趋势是否一致
- 向下校验：随机抽几个维度的汇总值，回算DWD层的明细，看能不能算出来
举个例子。DWS层有个"每日销售额"指标，按日期+商品维度汇总。我会随机抽一天、一个商品，去DWD层把明细捞出来，手动加一下。如果对不上，那肯定是聚合逻辑有问题。
4.1.4 ADS层校验：最终交付
ADS层是面向应用的数据层，报表、大屏、接口都从这层取数。这一层的校验，核心是可用性。数据能不能用？用户看到的对不对？
ADS层的校验，我一般关注三点：
- 指标波动校验：今天的销售额比昨天涨了50%，正常吗？是不是数据有问题？
- 数据时效性校验：报表数据是不是最新的？有没有延迟？
- 数据一致性校验：同一个指标，在不同报表里应该是一样的值
曾经踩过的坑：有一次，ADS层的"月活跃用户"指标突然下降了30%。业务方急得跳脚。查了半天，发现是DWS层的一个聚合脚本改了过滤条件，把一部分用户给过滤掉了。从那以后，我要求ADS层的每个指标都必须有"同比/环比波动告警"，超过阈值自动发通知。
4.2 增量校验与全量校验
校验的第二个维度，是看数据量的大小和变化频率。全量校验和增量校验，各有各的适用场景。
| 校验类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 全量校验 | 首次加载、数据量小、月度/季度对账 | 覆盖全面，不漏一条 | 耗时长，资源消耗大 |
| 增量校验 | 日常增量同步、实时流处理 | 速度快，资源消耗小 | 可能漏掉历史数据的变更 |
我个人建议：全量校验做兜底，增量校验做日常。比如每天跑增量校验，每周或者每月跑一次全量校验。全量校验就像体检，增量校验就像每天的体温测量，两者结合才靠谱。
实践建议：
- 首次加载数据时，必须做全量校验
- 日常增量同步，做增量校验就够了
- 每月/每季度做一次全量校验，作为数据质量的"大扫除"
- 全量校验和增量校验的结果要能互相印证
4.3 离线校验与实时校验
第三个维度，是看数据的处理时效。离线校验和实时校验，关注的点完全不同。
4.3.1 离线校验：批处理场景
离线校验，说白了就是T+1的校验。数据今天跑完，明天校验。这种场景下，校验的深度和广度都可以做得很大。
离线校验的典型流程：
- ETL任务跑完，触发校验任务
- 校验任务读取校验规则配置表
- 逐条执行校验规则（记录数、唯一键、业务逻辑等）
- 校验结果写入校验结果表
- 如果有异常，发送告警通知
我习惯把离线校验做成一个独立的调度任务，跟ETL任务解耦。这样ETL失败了，校验任务不会跟着跑，避免误报。
4.3.2 实时校验：流处理场景
实时校验就麻烦多了。数据一条一条地来，你不能等攒够了再校验。实时校验的核心是轻量、快速、可容忍。
实时校验我一般只做三种：
- Schema校验：来的数据字段对不对？类型对不对？
- 非空校验：关键字段不能为空
- 阈值校验：数值字段不能超出合理范围
你想想看，实时场景下如果做复杂的业务逻辑校验，延迟就上去了，得不偿失。复杂的校验，还是留给离线去做吧。
我的经验：实时校验的告警阈值要设得宽松一些。因为实时数据本身就有一定的波动，阈值设得太紧，告警满天飞，反而没人看了。我一般设两套阈值：一个"警告"阈值，一个"严重"阈值。警告阈值可以频繁触发，严重阈值必须人工介入。
4.4 分层校验策略全景图
说了这么多，咱们用一张图把整个校验策略串起来。这张图展示了数仓各层、校验类型、校验维度的关系。
4.5 校验策略落地建议
最后，聊点落地的东西。校验策略设计好了，怎么落地？我总结了几条经验：
落地四步法：
- 规则配置化：校验规则不要写死在代码里，放到配置表里，方便增删改
- 校验自动化：校验任务要自动触发，不要等人手工跑
- 告警分级化：P0级告警（数据丢失、主键重复）直接打电话；P1级告警（记录数偏差）发邮件；P2级告警（格式问题）记日志
- 结果可视化：校验结果要有看板，一眼能看出数据质量是好是坏
我曾经在一个项目里，把校验规则全部写死在Python脚本里。后来业务变了，要加一个新规则，得改代码、重新部署，折腾半天。后来我改成配置表+通用校验引擎，加规则只需要在配置表里加一行，省心多了。
嗯，校验策略这块就聊到这儿。记住一句话：校验不是一次性的，是持续的过程。数据在变，业务在变，校验策略也得跟着变。