数据质量六大维度：从理论到实战
数据质量这个话题，说实话，我入行头三年都没真正重视过。直到有一次，我负责的一个用户画像项目，因为数据质量问题导致模型准确率直接腰斩——嗯，从那以后，我再也不敢小看数据质量了。
今天咱们聊聊数据质量的六大维度。这六个维度，说白了就是衡量数据「好不好用」的六把尺子。我个人习惯把这六个维度分成两组：基础质量（完整性、准确性、一致性）和业务质量（时效性、唯一性、规范性）。
核心观点：数据质量不是一次性工程，而是持续治理的过程。你想想看，数据每天都在产生，质量怎么可能一劳永逸？
一、完整性：数据有没有「缺胳膊少腿」？
完整性，说白了就是数据该有的字段有没有、该填的值是不是空的。我见过最离谱的情况——某个客户表里，手机号字段空值率高达40%。这种数据你敢用？
完整性检查通常分两个层面：
- 记录完整性：有没有缺失行？比如某天的日志少了一小时的数据
- 字段完整性：关键字段是否为空？比如用户的身份证号
我的经验：完整性检查最好在数据入库时就做。我曾经接手过一个项目，数据已经跑了三个月才发现某个字段一直为空——那感觉，就像盖完楼才发现地基没打。
-- 完整性检查示例：找出手机号为空或格式异常的用户
SELECT
COUNT(*) AS 总记录数,
SUM(CASE WHEN phone IS NULL THEN 1 ELSE 0 END) AS 手机号缺失数,
ROUND(SUM(CASE WHEN phone IS NULL THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) AS 缺失率
FROM user_profile
WHERE created_date = '2024-01-15';二、准确性：数据是不是「靠谱」？
完整性只解决了「有没有」的问题，准确性解决的是「对不对」。举个例子：用户年龄填了200岁，字段是完整的，但明显不准确。
准确性问题的常见类型：
- 值域错误：年龄超过150、性别填了「未知」以外的值
- 格式错误：手机号11位却填了10位、邮箱没有@符号
- 逻辑矛盾：出生日期晚于注册日期、已婚但年龄只有5岁
避坑指南：我曾经遇到过一个坑——上游系统把日期格式从YYYY-MM-DD改成了YYYY/MM/DD，但没通知我们。结果下游所有日期计算全部出错。所以，准确性检查一定要包含格式校验。
三、一致性：数据之间「打架」怎么办？
一致性，就是不同数据源、不同表之间对同一事物的描述要统一。你想想看，CRM系统里客户叫「张三」，订单系统里同一个客户叫「张先生」——这数据怎么用？
一致性检查的典型场景：
| 检查类型 | 说明 | 示例 |
|---|---|---|
| 跨表一致性 | 同一实体在不同表中的属性一致 | 用户表性别与订单表性别一致 |
| 跨系统一致性 | 不同系统对同一数据的定义一致 | CRM和ERP中的客户ID映射正确 |
| 汇总一致性 | 明细汇总等于汇总值 | 各门店销售额之和等于总销售额 |
核心原则：一致性问题的根源往往是「数据孤岛」。我个人习惯在数据接入层就建立统一的映射关系，而不是等到数据仓库里再处理——那成本太高了。
四、时效性：数据「过期」了没有？
时效性，就是数据从产生到可用的时间差。有些数据晚几分钟就废了——比如股票行情、实时风控。有些数据可以容忍几小时甚至几天——比如月度报表。
我一般把时效性要求分成三个等级：
- T+0（实时）：秒级到分钟级延迟，比如交易流水
- T+1（准实时）：小时级到天级延迟，比如用户行为日志
- T+N（批量）：天级到周级延迟，比如财务月报
我的建议：别盲目追求实时。我见过一个团队，为了把T+1的报表改成实时，花了三个月重构架构，结果业务方说「其实我们每天看一次就够了」——先搞清楚需求再动手。
五、唯一性：数据「重复」了没有？
唯一性，就是同一实体在数据集中不能出现多次。这个问题在用户数据里尤其常见——同一个用户注册了两次，生成了两个不同的用户ID。
唯一性问题的典型表现：
- 主键重复：同一ID出现多条记录
- 业务主键重复：同一身份证号对应多个用户
- 自然键重复：同一手机号出现在多条记录中
-- 唯一性检查：找出重复的身份证号
SELECT
id_card,
COUNT(*) AS 出现次数,
STRING_AGG(user_id::text, ',') AS 重复用户ID列表
FROM user_profile
WHERE id_card IS NOT NULL
GROUP BY id_card
HAVING COUNT(*) > 1;避坑指南：我曾经处理过一个案例——某系统没有做唯一性约束，导致同一个客户在数据库里出现了7次。更坑的是，这7条记录的地址、电话都不一样。最后花了整整两周做数据归并。所以，唯一性约束一定要在源头做。
六、规范性：数据「长」得标准吗？
规范性，就是数据格式、编码、命名是否符合统一标准。这个问题看似小事，但实际影响很大——你想想看，如果日期格式有YYYY-MM-DD、YYYY/MM/DD、YYYYMMDD三种，下游处理起来得多痛苦？
规范性检查的常见维度：
- 格式规范：日期、时间、金额等字段格式统一
- 编码规范：性别用0/1还是M/F，状态码是否统一
- 命名规范：字段名用snake_case还是camelCase
- 单位规范：金额单位是元还是分，长度单位是米还是厘米
我的经验：规范性是最容易被忽视的维度。很多团队觉得「能跑就行」，结果数据量一大，各种格式问题全冒出来了。我建议在数据建模阶段就制定好规范文档，并且用自动化工具做校验。
好了，六大维度就聊到这儿。这六个维度不是孤立的——它们之间互相影响。比如，完整性差往往导致准确性也差，规范性不好会影响一致性。实际工作中，我一般会先抓完整性和准确性，这两个是基础。基础打好了，再谈其他的。
记住一句话：数据质量不是检查出来的，是设计出来的。从源头控制，比事后清洗要高效得多。