数据校验核心概念：五类校验方法详解

数据校验这件事，说白了就是给数据做体检。我在数仓项目里摸爬滚打这些年，见过太多因为校验不到位而翻车的案例。今天咱们就把五类最核心的校验方法掰开揉碎了讲清楚。

1. 记录数校验：最基础也最容易被忽视

记录数校验，就是对比源表和目标表的行数。听起来简单吧？但我见过太多团队在这上面翻车。

我记得有一次做电商数仓迁移，源表有1.2亿条订单数据，ETL跑完后目标表只有1.1亿。差了1000万条！排查了半天，发现是某个分区条件写错了，把上个月的数据全过滤掉了。要是没有记录数校验，这问题可能要等到业务方发现数据对不上才暴露。

实现方式也很直接：

-- 源表记录数
SELECT COUNT(*) AS src_cnt FROM source_orders WHERE dt = '2024-01-15';

-- 目标表记录数
SELECT COUNT(*) AS tgt_cnt FROM dwd_orders WHERE dt = '2024-01-15';

-- 对比结果
SELECT 
  src_cnt,
  tgt_cnt,
  CASE WHEN src_cnt = tgt_cnt THEN 'PASS' ELSE 'FAIL' END AS status
FROM (SELECT COUNT(*) AS src_cnt FROM source_orders WHERE dt = '2024-01-15') a
CROSS JOIN (SELECT COUNT(*) AS tgt_cnt FROM dwd_orders WHERE dt = '2024-01-15') b;

2. 空值校验：别让NULL悄悄溜进数仓

空值校验，检查的是关键字段里有没有不该出现的NULL。你想想看，一个订单表的订单金额字段如果是NULL，那下游的汇总报表会出什么问题？

我个人习惯把字段分成三类：

字段类型	空值容忍度	校验规则
主键/业务键	零容忍	NULL率 = 0%
核心业务字段	低容忍	NULL率 < 1%
辅助/扩展字段	可容忍	NULL率 < 20%

实际项目中，我一般这样写空值校验：

-- 检查核心字段空值率
SELECT 
  'order_id' AS field_name,
  SUM(CASE WHEN order_id IS NULL THEN 1 ELSE 0 END) AS null_count,
  ROUND(SUM(CASE WHEN order_id IS NULL THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) AS null_rate
FROM dwd_orders
WHERE dt = '2024-01-15'

UNION ALL

SELECT 
  'order_amount' AS field_name,
  SUM(CASE WHEN order_amount IS NULL THEN 1 ELSE 0 END) AS null_count,
  ROUND(SUM(CASE WHEN order_amount IS NULL THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) AS null_rate
FROM dwd_orders
WHERE dt = '2024-01-15';

3. 重复值校验：主键的唯一性不能妥协

重复值校验，说白了就是检查主键或业务唯一键有没有重复。这是数据质量的底线，没有商量余地。

为什么这么说？你想想看，如果订单表里同一个订单ID出现两次，那汇总订单金额的时候就会翻倍。业务方拿着翻倍的报表去对账，那画面太美我不敢看。

-- 检查主键重复
SELECT 
  order_id,
  COUNT(*) AS dup_count
FROM dwd_orders
WHERE dt = '2024-01-15'
GROUP BY order_id
HAVING COUNT(*) > 1;

-- 如果返回0行，说明没有重复
-- 如果返回有数据，就需要排查重复原因

嗯，这里要注意：重复值校验不只是针对单字段主键。复合主键也要检查：

-- 复合主键重复检查
SELECT 
  order_id,
  product_id,
  COUNT(*) AS dup_count
FROM dwd_order_details
WHERE dt = '2024-01-15'
GROUP BY order_id, product_id
HAVING COUNT(*) > 1;

4. 业务规则校验：让数据符合真实世界的逻辑

业务规则校验，是五类校验里最灵活也最考验业务理解能力的。它检查的是数据是否符合业务逻辑约束。

举个例子：

• 订单金额必须大于0
• 下单时间必须早于支付时间
• 会员等级和折扣率必须匹配
• 年龄字段不能超过150岁

这些规则看起来简单，但实际落地时坑不少。我记得有一次做金融数仓，业务规则要求"交易金额不能超过账户余额"。听起来合理吧？但实际跑起来发现，有些交易是跨行转账，到账有延迟，余额还没更新。这时候就需要和业务方确认：到底是以交易发起时的余额为准，还是以实际扣款时的余额为准？

-- 业务规则校验示例：订单金额必须为正数
SELECT 
  order_id,
  order_amount,
  '订单金额不能为负数或零' AS rule_name,
  'FAIL' AS check_result
FROM dwd_orders
WHERE dt = '2024-01-15'
  AND order_amount <= 0;

-- 时间逻辑校验：支付时间不能早于下单时间
SELECT 
  order_id,
  order_time,
  pay_time,
  '支付时间不能早于下单时间' AS rule_name,
  'FAIL' AS check_result
FROM dwd_orders
WHERE dt = '2024-01-15'
  AND pay_time IS NOT NULL
  AND pay_time < order_time;

5. 跨表关联校验：表与表之间的数据要能对得上

跨表关联校验，检查的是不同表之间的关联关系是否完整一致。数仓里表多了，表与表之间的数据一致性就成了大问题。

最常见的场景：

• 事实表中的外键，在维度表中是否存在对应的记录
• 两张表通过某个字段关联后，关联上的记录数是否合理
• 汇总表的数据，和明细表汇总后的数据是否一致

我习惯用这种方式做关联校验：

-- 检查事实表的外键是否都在维度表中存在
SELECT 
  COUNT(*) AS total_fact_records,
  SUM(CASE WHEN dim.product_id IS NULL THEN 1 ELSE 0 END) AS orphan_records,
  ROUND(SUM(CASE WHEN dim.product_id IS NULL THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) AS orphan_rate
FROM dwd_order_details fact
LEFT JOIN dim_product dim ON fact.product_id = dim.product_id
WHERE fact.dt = '2024-01-15';

-- 明细汇总 vs 汇总表对比
SELECT 
  '明细汇总' AS data_source,
  SUM(order_amount) AS total_amount
FROM dwd_orders
WHERE dt = '2024-01-15'

UNION ALL

SELECT 
  '汇总表' AS data_source,
  total_amount
FROM dws_daily_order_summary
WHERE dt = '2024-01-15';

五类校验方法的对比与选择

最后，我整理了一个对比表，方便你在实际项目中快速选择：

校验方法	检查对象	发现的问题类型	执行频率	优先级
记录数校验	表级	数据丢失、重复加载	每次ETL	P0
空值校验	字段级	字段缺失、上游变更	每次ETL	P0
重复值校验	记录级	主键冲突、重复数据	每次ETL	P0
业务规则校验	逻辑级	业务逻辑异常	每日/每周	P1
跨表关联校验	表间级	关联断裂、数据不一致	每日	P1

这五类校验方法，说白了就是一套组合拳。单用哪一种都有盲区，组合起来才能构建完整的数据质量防线。我个人建议：先把P0的三类校验做成自动化脚本，每天定时跑；P1的两类校验可以做成周报或月报的形式，定期检查。