数据质量六大维度：从理论到实战
聊数据质量，绕不开这六个维度。完整性、准确性、一致性、及时性、唯一性、有效性。我见过不少团队，一上来就搞复杂的数据质量平台，结果连最基本的维度都没定义清楚。说白了，这六个维度就是数据质量的「体检指标」，每个维度对应一类常见问题。
我个人习惯，在项目启动阶段先拿这六个维度做一次「数据健康度扫描」。你会发现，很多坑其实在源头就能堵住。
2.1 完整性：数据有没有缺胳膊少腿？
完整性检查的是数据有没有缺失。字段为空、记录丢失、文件行数不对，都算。
我在项目中遇到过最典型的场景：业务方说「订单表每天应该有 100 万条」，结果某天只来了 80 万。上游系统挂了，但没报错。完整性监控没做，数据就悄无声息地丢了。
- 必填字段是否为空（如订单 ID、用户 ID）
- 记录数是否在合理区间（环比/同比波动）
- 文件是否完整到达（行数校验、文件大小校验）
代码层面，我一般这样写完整性校验：
-- 检查订单表必填字段
SELECT
COUNT(*) AS total_rows,
SUM(CASE WHEN order_id IS NULL THEN 1 ELSE 0 END) AS null_order_id,
SUM(CASE WHEN user_id IS NULL THEN 1 ELSE 0 END) AS null_user_id,
SUM(CASE WHEN amount IS NULL THEN 1 ELSE 0 END) AS null_amount
FROM dwd_order_di
WHERE dt = '2024-01-15';2.2 准确性：数据对不对？
完整性只关心「有没有」，准确性关心「对不对」。数据值是否在合理范围内？计算逻辑是否正确？
举个例子：订单金额字段，完整性检查通过——没有空值。但准确性检查发现，某笔订单金额是 -100 元。嗯，这明显不对。还有更隐蔽的：金额字段存的是「分」，但下游按「元」解析，结果所有数据都放大了 100 倍。
我曾经踩过一个坑：实时流里有个金额字段，上游改了单位但没通知我们。等发现时，已经影响了三天的报表。从那以后，我要求所有关键字段必须做「值域校验」。
| 校验类型 | 示例 | 常见问题 |
|---|---|---|
| 值域校验 | 金额 > 0 | 负数、超大数据 |
| 格式校验 | 手机号 11 位 | 多一位、少一位、含字母 |
| 业务逻辑校验 | 下单时间 < 支付时间 | 时间倒挂 |
| 统计分布校验 | 均值 ± 3σ | 离群点、数据漂移 |
2.3 一致性：不同系统说的是一回事吗？
一致性，说白了就是「同一个东西，在不同地方得长一样」。用户 ID 在 MySQL 里是整数，在 Hive 里是字符串，在 Redis 里又变成了带前缀的编码——这就算不一致。
流批一体架构下，一致性问题尤其突出。批处理跑出来的汇总数据，和实时流算出来的结果对不上，这是最常见的扯皮场景。
我建议从三个层面做一致性校验：
- 模式一致性： 字段名、类型、长度是否统一
- 枚举一致性： 状态码、类型值的定义是否一致
- 数据一致性： 同一份数据在不同存储中的值是否相同
2.4 及时性：数据来得够快吗？
及时性衡量的是数据从产生到可用之间的延迟。实时场景下，延迟可能是秒级；离线场景下，可能是小时级。关键不是「多快」，而是「是否满足 SLA」。
我记得有一次做实时大屏，要求数据延迟不超过 5 分钟。结果某天 Kafka 消费积压，延迟飙到了 30 分钟。业务方直接炸了——大屏上的数字和实际业务差了半小时，根本没法用。
及时性监控的核心指标：
- 数据产生时间 vs 到达时间： 端到端延迟
- 处理时间 vs 事件时间： 流处理中的 watermark 延迟
- 调度延迟： 离线任务是否按时启动
2.5 唯一性：数据有没有重复？
唯一性，就是同一份数据不能出现多次。听起来简单，但实际中重复数据防不胜防。
你想想看：实时流里，上游重发了消息；离线任务失败重跑，数据被重复写入；接口超时后重试，结果两次都成功了。这些都是重复数据的来源。
我处理过最夸张的一次：某张用户表，因为去重逻辑写错了，同一个用户出现了 17 条记录。下游做用户画像时，一个用户被算了 17 次，数据直接废了。
-- 检查订单表是否有重复主键
SELECT
order_id,
COUNT(*) AS dup_count
FROM dwd_order_di
WHERE dt = '2024-01-15'
GROUP BY order_id
HAVING COUNT(*) > 1;2.6 有效性：数据符合业务规则吗？
有效性，是检查数据是否满足业务定义的规则。它比准确性更「业务化」。比如：
- 用户状态只能是 'active'、'inactive'、'banned' 三种
- 订单金额必须大于 0 且小于 100 万
- 邮箱地址必须包含 '@' 符号
有效性和准确性的区别在哪？准确性是「值对不对」，有效性是「值合不合法」。一个合法的值不一定准确，但一个不合法的值肯定有问题。
我在项目中习惯把有效性规则维护在「数据质量规则库」里，用配置化的方式管理。这样业务方也能自己加规则，不用每次都找开发改代码。
{
"rule_name": "用户状态有效性",
"field": "user_status",
"type": "enum",
"allowed_values": ["active", "inactive", "banned"],
"action": "reject"
}六大维度全景图
下面这张图，是我自己梳理的六大维度关系。你可以把它当作数据质量建设的「导航图」。
这六个维度不是孤立的。举个例子：数据重复（唯一性问题）可能导致汇总值偏高（准确性问题），进而影响跨系统对账（一致性问题）。所以做数据质量，不能只盯着一个维度看。
我个人习惯，在项目初期先定义好每个维度的「质量门禁」——哪些规则是硬性的，不通过就阻断；哪些是软性的，只告警不阻断。这样既能保证数据质量，又不会因为过度校验拖慢开发进度。