数据质量六大维度详解
数据质量这个话题，说起来好像人人都懂。但真到了线上数据出问题的时候，你会发现大家连「什么叫质量好」都没对齐。我这些年踩过的坑，十有八九都跟质量维度的定义模糊有关。
所以这一章，咱们把六个核心维度掰开揉碎了讲。完整性、准确性、一致性、及时性、唯一性、有效性。每个维度我都会结合真实案例，告诉你到底该怎么衡量、怎么监控。
核心观点：六个维度不是孤立存在的。一个数据质量问题，往往同时违反多个维度。比如重复订单既违反唯一性，又可能导致统计准确性出问题。
1. 完整性：数据有没有缺胳膊少腿？
完整性，说白了就是该有的数据有没有。字段不能为空，记录不能缺失，文件不能少行。听起来简单，但实际做起来坑很多。
我遇到过最典型的场景：业务方说「订单表数据不全」，结果一查，是上游系统在凌晨批量删除历史数据时，把当天还没跑完的增量数据也删了。嗯，这种问题光靠字段非空校验是抓不住的。
完整性检查的三个层次
| 层次 | 检查内容 | 常见问题 |
|---|---|---|
| 字段级 | 必填字段是否为 NULL 或空字符串 | 用户手机号为空、订单金额为 NULL |
| 记录级 | 主键是否存在、记录数是否在合理范围 | 某天订单记录数突然下降 50% |
| 文件级 | 数据文件是否完整到达、行数是否匹配 | Hive 分区文件缺失、Kafka 消息丢失 |
我的习惯：完整性检查一定要做「基线对比」。比如每天记录数跟过去 7 天均值比，偏差超过 20% 就告警。光靠非空校验，你永远发现不了「少了一整张表」的问题。
2. 准确性：数据跟真实世界对得上吗？
准确性是数据质量里最难搞的维度。为什么？因为「真实世界」本身就不容易定义。你想想看，用户填的地址、系统自动计算的折扣、第三方接口返回的汇率——这些数据到底准不准，往往需要跨系统交叉验证。
我记得有一次，数仓里的「订单金额」比业务系统高了 0.01 元。业务方说「差一分钱无所谓」，但财务说「一分钱对不上账」。最后查出来，是浮点数精度问题导致的四舍五入差异。你看，准确性有时候就是个精度问题。
准确性校验的常用方法
- 交叉验证：同一指标在不同数据源之间比对。比如数仓的 GMV 跟业务数据库的 GMV 做差值。
- 业务规则校验：比如「订单金额 = 商品单价 × 数量 + 运费 - 折扣」，这个等式必须成立。
- 统计分布校验：看数据分布是否异常。比如某天客单价突然从 200 跳到 2000，大概率是数据有问题。
避坑指南：我曾经在某个项目中，只做了「字段级准确性校验」，结果漏掉了「跨表关联后的数据失真」。比如用户表和订单表 join 之后，因为用户 ID 类型不一致（一个用 int，一个用 string），导致大量订单匹配不到用户。这种问题，单表校验永远发现不了。
3. 一致性：不同地方的数据能对上吗？
一致性，就是同一个东西在不同系统、不同表、不同时间点，定义和取值必须一样。说白了，不能出现「A 系统叫客户编号，B 系统叫客户 ID，C 系统叫 customer_code」这种混乱局面。
我见过最离谱的案例：同一个「订单状态」，业务库用 0/1/2/3 表示，数仓用 '待支付'/'已支付'/'已发货'/'已完成' 表示，报表系统又用 'PENDING'/'PAID'/'SHIPPED'/'DONE'。三个系统各说各话，最后对账对了一个月。
一致性检查清单
| 检查类型 | 说明 | 示例 |
|---|---|---|
| 命名一致性 | 同一字段在不同表中名称相同 | 统一用 user_id，不用 uid、userId、用户ID |
| 类型一致性 | 同一字段在不同系统中数据类型一致 | 金额统一用 decimal(18,2)，不用 float |
| 枚举一致性 | 枚举值的含义和编码一致 | 订单状态编码统一，不出现歧义 |
| 计算逻辑一致性 | 同一指标的计算口径一致 | GMV 是否包含退款、是否含税 |
核心原则：一致性问题的根因，90% 是「没有统一的元数据管理」。你想想看，如果每个字段都有明确的定义、类型、取值范围、计算口径，怎么可能对不上？
4. 及时性：数据来得够快吗？
及时性，就是数据从产生到可用，花了多长时间。不同业务对及时性的要求天差地别。实时风控要求毫秒级，日报可以接受 T+1，月报 T+7 都行。
我个人的经验是：及时性指标一定要跟 SLA 绑定。比如「每日报表必须在早上 8 点前产出」，那你就得监控每个环节的耗时。如果 ETL 跑了 3 小时，数据同步花了 1 小时，那总耗时 4 小时，8 点前肯定出不来。
及时性监控的关键指标
- 数据延迟：从数据产生到进入数仓的时间差。比如 Kafka 消息延迟、CDC 同步延迟。
- ETL 耗时：每个调度任务的执行时间。超过基线就告警。
- 产出时间：最终数据对用户可用的时间点。比如报表在 7:55 刷新完成。
我的建议：及时性监控不要只看「平均耗时」，要看「P95 耗时」。因为平均耗时会被少数快任务拉低，而 P95 耗时才能反映真实体验。我曾经就因为只看平均值，漏掉了某个分区表每周五都会慢 20 分钟的问题。
5. 唯一性：数据有没有重复？
唯一性，就是同一个实体在数据集中只能出现一次。用户不能重复注册，订单不能重复提交，商品编码不能重复。
唯一性问题最常见的场景是：数据同步过程中，因为网络重试、消息重复消费、幂等性没做好，导致同一笔数据被插入了多次。嗯，这种问题在实时数仓里尤其常见。
唯一性检查的三种方式
| 方式 | 适用场景 | 检查方法 |
|---|---|---|
| 主键唯一性 | 单表内主键不能重复 | COUNT(DISTINCT pk) = COUNT(*) |
| 业务唯一性 | 业务逻辑上不能重复 | 同一用户+同一商品+同一时间只能有一条记录 |
| 跨表唯一性 | 不同表之间不能有重复实体 | 用户表与用户扩展表的 user_id 一一对应 |
避坑指南：我曾经在实时数仓项目中，Kafka 消费者因为 offset 提交失败，导致同一批数据被重复消费了 3 次。结果订单表里出现了大量重复记录，下游的报表全部翻倍。从那以后，我要求所有实时任务必须做「幂等写入」，并且在目标表上建唯一索引兜底。
6. 有效性：数据符合业务规则吗？
有效性，就是数据在业务语义上是否「合理」。比如年龄不能是负数，手机号必须是 11 位，邮箱必须包含 @ 符号。有效性跟完整性有点像，但更强调「业务约束」。
我遇到过最经典的案例：某个系统的「性别」字段，允许用户输入任意文本。结果有人填了「奥特曼」，有人填了「保密」，还有人填了「不告诉你」。这种数据在数仓里就是垃圾，任何统计分析都会被污染。
有效性规则示例
- 格式校验：身份证号 18 位、手机号 11 位、邮箱包含 @
- 范围校验：年龄 0-150、金额 ≥ 0、折扣率 0-1
- 枚举校验：性别只能是 '男'/'女'/'未知'，订单状态只能是预定义的几种
- 依赖校验：如果订单状态是「已发货」，则物流单号不能为空
核心观点：有效性规则一定要在数据接入层就做拦截。不要等到数据进了数仓再清洗，那时候已经晚了。我习惯在 ETL 的入口层（Staging 层）就做有效性校验，不合格的数据直接进异常表，并触发告警。
六个维度的优先级排序
你可能会问：这六个维度，哪个最重要？说实话，没有标准答案。不同业务场景，优先级完全不同。
但我个人的经验是：完整性和准确性是底线。数据都不全、都不准，其他维度谈都没意义。其次是唯一性和一致性，这两个维度出问题，会导致数据「不可信」。及时性和有效性，更多是体验层面的优化。
| 优先级 | 维度 | 典型影响 |
|---|---|---|
| P0 | 完整性、准确性 | 数据不可用，决策错误 |
| P1 | 唯一性、一致性 | 数据不可信，对账困难 |
| P2 | 及时性、有效性 | 体验下降，分析偏差 |
我的习惯：在项目初期，先搞定 P0 维度的监控。等数据稳定了，再逐步加上 P1 和 P2 的检查。不要一上来就想面面俱到，那样反而什么都做不好。