3. 数据质量维度：完整性、准确性、一致性、时效性、唯一性

聊数据管道健康度，绕不开数据质量。我见过太多管道，跑得飞快，延迟极低，但数据全是错的——这种管道，说白了就是「高速运垃圾」。所以这一章，我们得把数据质量的五个核心维度掰开揉碎讲清楚。

我个人习惯把这五个维度比作「数据体检的五项指标」。任何一个维度出问题，这条管道就得亮黄牌。咱们一个一个来过。

3.1 完整性（Completeness）

完整性，就是数据有没有缺胳膊少腿。字段为空、记录缺失、分区丢失，都算不完整。

我在项目中遇到过最典型的场景：某天凌晨的ETL任务因为上游表结构变更，导致三个字段没写进去。下游报表跑出来，营收直接少了30%。老板开会时脸都绿了。

检查完整性，我一般用这几招：

• 空值率监控：核心字段空值率超过阈值就告警
• 记录数波动检测：今天的数据量跟历史均值比，偏差超过±20%要排查
• 分区完整性校验：每天检查Hive/分区表是否所有分区都到位

3.2 准确性（Accuracy）

准确性，就是数据跟真实世界是不是一回事。字段值对不对？计算逻辑有没有偏差？

举个例子：用户年龄字段，有人填「-5」，有人填「200」。这种数据虽然完整，但明显不准确。你想想看，拿这种数据做用户画像，能靠谱吗？

我常用的准确性校验手段：

• 值域校验：年龄0-120，金额非负，日期不能是未来
• 业务规则校验：订单金额 = 单价 × 数量，这个等式必须成立
• 交叉验证：用两个独立数据源互相核对，比如系统日志和数据库记录

3.3 一致性（Consistency）

一致性，就是不同地方的数据能不能对得上。同一个用户ID，在A表叫「user_id」，在B表叫「uid」，在C表叫「customer_no」——这种不一致，够你喝一壶的。

我遇到过最头疼的事：两个团队各自维护用户画像，一个用手机号去重，一个用设备ID去重。结果同一个用户，在两张表里被算成两个人。最后做用户总量统计时，数据差了30%。

一致性检查要点：

检查类型	说明	常见问题
格式一致	同一字段在不同表中格式统一	日期格式混用 yyyy-MM-dd 和 yyyy/MM/dd
编码一致	枚举值、状态码定义相同	订单状态「已支付」vs「PAID」vs「1」
逻辑一致	关联字段能正确匹配	外键在关联表中找不到对应记录

3.4 时效性（Timeliness）

时效性，就是数据从产生到可用，花了多长时间。说白了，数据是不是「热乎」的。

不同场景对时效性的要求天差地别：

• 实时风控：延迟超过1秒，欺诈交易可能已经完成了
• 离线报表：T+1能出就行，晚两小时问题不大
• 实时大屏：延迟超过30秒，大屏上的数字就成「历史」了

我一般用「数据新鲜度」来衡量时效性。具体做法是：

-- 检查数据新鲜度的SQL示例
SELECT 
  MAX(event_time) AS latest_event,
  DATEDIFF('minute', MAX(event_time), NOW()) AS delay_minutes
FROM fact_orders
WHERE dt = '2024-01-15';

如果延迟分钟数超过SLA规定的阈值，就得告警了。

3.5 唯一性（Uniqueness）

唯一性，就是数据有没有重复。同一个业务实体，在数据里只应该出现一次。

重复数据的危害，我深有体会。有一次做用户留存分析，因为数据管道里有个去重逻辑写错了，同一个用户被算了两次。结果留存率从35%「涨」到了70%——老板差点因为这个错误决策多投200万预算。

唯一性检查方法：

• 主键唯一性：检查主键字段是否有重复值
• 业务唯一性：比如一个订单号只能对应一条记录
• 去重率监控：计算去重前后的数据量比值，异常波动要排查

3.6 五维度关系与评估框架

这五个维度不是孤立的。它们之间互相影响，甚至互相制约。你想想看：

• 为了追求时效性，可能牺牲完整性（数据还没全到就开始处理）
• 为了保证一致性，可能降低时效性（等所有数据对齐后再输出）
• 准确性和唯一性出问题，完整性再高也没用

下面这张图，是我做数据质量评估时常用的框架：

在实际项目中，我一般会给每个维度打分（1-5分），然后加权计算综合健康度。比如：

维度	权重	评分标准
完整性	25%	核心字段空值率 < 1% 得5分，< 5% 得3分，超过10% 得1分
准确性	30%	校验通过率 > 99% 得5分，> 95% 得3分，低于90% 得1分
一致性	20%	跨表关联匹配率 > 99% 得5分，> 95% 得3分
时效性	15%	延迟在SLA内得5分，超出50%以内得3分，超出100%得1分
唯一性	10%	重复率 < 0.1% 得5分，< 1% 得3分