📚 课程目录第1章数据校验概述

1. 数据校验概述：为什么需要数据校验、数据质量维度、数仓中数据校验的挑战

大家好，我是老张。做数仓这行十几年了，踩过的坑比写过的代码还多。今天咱们聊聊数据校验——这个听起来基础、但真正做好的人不多的环节。

先问个问题：你凭什么相信你数仓里的数据是对的？

别笑，这个问题我问过很多刚入行的朋友。他们的第一反应往往是：「ETL 跑完了啊，没报错啊。」嗯，ETL 没报错，不代表数据是对的。我见过太多案例——任务跑得漂漂亮亮，报表出来全是错的。

说白了，数据校验就是给数据质量上保险。没有校验的数仓，就像没有质检的工厂——产品能不能用，全凭运气。

我个人习惯把数据校验的必要性归纳为三点：

源头不可信：业务系统数据本身就有脏数据。空值、格式错误、逻辑矛盾，这些在源系统里比比皆是。我曾经接手过一个项目，源系统的订单表里居然有 30% 的订单金额是负数——业务方说「那是退款单，没单独建表」。
加工会出错：ETL 代码是人写的，人就会犯错。字段映射错了、过滤条件写反了、聚合逻辑有 bug，这些坑我全踩过。有一次我写了个 join 条件漏了分区键，结果数据膨胀了 10 倍，查了两天才定位到。
下游依赖强：数仓的数据最终要支撑报表、分析、甚至 AI 模型。数据错了，决策就歪了。这个责任，谁都担不起。

核心观点：数据校验不是「锦上添花」，而是「雪中送炭」。没有校验的数仓，本质上是一个黑箱——你永远不知道它什么时候会出问题。

聊数据质量，绕不开这四个维度。我习惯把它们记成「完准一及」——完整性、准确性、一致性、及时性。咱们一个一个说。

维度	定义	常见问题	校验手段举例
完整性	数据是否缺失、记录是否齐全	字段空值、分区缺失、记录数不对	非空校验、行数对比、主键唯一性检查
准确性	数据是否真实反映业务事实	金额算错、日期格式错误、逻辑矛盾	业务规则校验、交叉验证、阈值检查
一致性	不同系统/表之间的数据是否吻合	汇总表与明细表对不上、跨系统口径不同	汇总比对、关联校验、口径对齐检查
及时性	数据是否在预期时间内可用	延迟到达、调度超时、数据滞后	时间戳监控、调度耗时告警、SLA 检查

完整性是最基础的校验。你想想看，如果一张订单表少了 10% 的记录，后面的分析全白搭。我在项目中遇到过最典型的场景：每天凌晨跑批，某天源系统挂了，数据没推过来，但 ETL 任务照常跑完了——结果那天的报表全是空的。从那以后，我坚持在每个表加载后做行数对比。

准确性比完整性更难搞。数据不缺，但内容是错的。举个例子：金额字段把「分」当「元」存了，或者日期字段混入了「2025-13-01」这种非法值。我建议在数据入仓的第一层就做格式校验和业务规则校验，别等到下游才发现。

一致性是数仓里最容易出问题的维度。为什么？因为数据经过多层加工后，口径很容易走样。我记得有一次，DWD 层的订单金额和 DWS 层的汇总金额差了 0.5%，查了半天发现是 DWD 层用了「下单时间」，DWS 层用了「支付时间」——口径不一致。这种问题，靠人工查基本查不出来，必须靠自动化校验。

及时性往往被忽视，但它直接影响业务决策。数据再准，如果晚了两个小时，对业务来说就是废的。我曾经负责过一个实时数仓项目，要求数据延迟不超过 5 分钟。结果上线第一天，某个环节的 Kafka 消费 lag 飙到了 30 分钟——业务方直接炸了。从那以后，我坚持在每条数据管道上加时间戳监控。

个人经验：这四个维度不是孤立的。完整性出问题，往往会导致准确性也出问题；及时性不达标，一致性校验也会失效。建议建立「维度联动」的校验体系，而不是单独看某一个维度。

理论说完了，咱们聊聊现实。数仓里的数据校验，远没有想象中那么简单。我总结了几个核心挑战：

数据量大：动辄 TB 级的数据，全量校验成本太高。你不可能每天把几十亿条记录全扫一遍。怎么办？抽样？还是分区校验？这是个取舍问题。
链路长：从源系统到 ODS，再到 DWD、DWS、ADS，中间经过多层加工。每一层都可能引入新的问题。我曾经在一个项目里，数据在 DWD 层是好的，到了 DWS 层就坏了——中间有个聚合逻辑写错了。定位问题花了三天。
口径复杂：不同业务方对同一个指标的理解可能完全不同。比如「活跃用户」，运营部按「登录次数」算，产品部按「使用时长」算。口径不统一，校验规则就没法写。
时效性要求高：很多数仓有严格的 SLA，比如「每天 8 点前必须出报表」。校验本身需要时间，但业务方等不起。怎么在有限的时间内完成校验？这是个工程难题。
环境差异：开发环境、测试环境、生产环境的数据量级和分布完全不同。在测试环境能通过的校验，到了生产环境可能直接崩掉。我见过太多「测试全绿，上线全红」的案例了。

避坑指南：我曾经在一个大项目里，因为没考虑「环境差异」，把生产环境的全量校验跑挂了——直接把 Hive 集群搞崩了。后来我学乖了：生产环境的校验一定要做「资源隔离」和「限流」，别让校验任务把集群资源吃光。

下面这张图，是我个人习惯用来梳理数据校验知识体系的。你可以把它当作本章的「地图」——后面每一节的内容，都能在这张图上找到位置。

这张图把本章的核心内容串起来了。你可以看到，数据校验不是孤立的技术动作，而是从「为什么需要」到「质量维度」再到「现实挑战」的完整链条。后面的章节，我们会沿着这个框架一步步深入。

好了，第一章就到这里。记住一句话：数据校验不是可选项，而是数仓的「安全带」。系好它，你才能放心踩油门。