2. 数据质量六大维度：完整性、准确性、一致性、及时性、唯一性、有效性
聊数据质量，绕不开这六个维度。
我刚开始做数据治理那会儿，觉得这玩意儿就是理论框框。后来踩了坑才发现——这六个维度，就是衡量数据能不能用的六把尺子。少一把，你的数据质量监控体系就漏风。
核心观点：六大维度不是并列关系，而是分层关系。完整性是地基，准确性和一致性是承重墙，及时性是门窗，唯一性和有效性是装修。地基不稳，后面全白搭。
2.1 完整性 —— 数据有没有缺胳膊少腿？
完整性，说白了就是数据该有的字段有没有，该有的记录齐不齐。
我记得刚接手一个用户画像项目，ETL 跑完一看，用户手机号字段 30% 是空的。业务方直接炸了——营销活动没法做。这就是完整性出问题。
我的经验：完整性监控要分两层。第一层是字段级——非空约束、默认值检查。第二层是记录级——主键是否存在、关联表是否有孤儿记录。别只盯着字段，记录缺失往往更致命。
完整性检查的常见场景：
- 必填字段为空：比如订单表中的用户ID、金额字段
- 记录缺失：比如某天的交易流水没入库
- 关联断裂：比如订单引用了不存在的用户
- 数据稀疏：比如某个维度下数据量骤降
2.2 准确性 —— 数据是不是在胡说八道？
完整性只保证数据存在，不保证数据正确。准确性才是硬道理。
我遇到过最离谱的事——某报表系统显示公司月营收 200 亿，财务总监差点报警。查了半天，是某个字段的单位从「元」变成了「分」。你想想看，这误差有多大。
避坑指南：我曾经在准确性监控上犯过一个错——只做值校验，没做波动率校验。结果数据从 100 变成 101，值偏差 1%，看起来没问题。但业务说正常应该是 1000。所以，准确性校验一定要结合业务基线。
准确性监控的常用手段：
- 值域校验：年龄 0-150，超出就是异常
- 格式校验：手机号 11 位，邮箱必须带 @
- 业务规则校验：下单时间不能晚于发货时间
- 统计分布校验：均值、中位数、标准差是否在合理范围
2.3 一致性 —— 不同系统之间别打架
一致性，就是同一份数据在不同地方长得一样不一样。
我做过一个数据中台项目，CRM 系统里用户等级是「VIP1」，订单系统里叫「V1」，数据仓库里又变成「金卡会员」。三个系统，三种叫法。你说这数据怎么用？
| 系统 | 用户等级字段 | 值 | 问题 |
|---|---|---|---|
| CRM | user_level | VIP1 | 标准定义 |
| 订单系统 | level_code | V1 | 编码不一致 |
| 数据仓库 | member_type | 金卡会员 | 命名不一致 |
一致性监控的核心：
- 跨系统字段对比：同一业务含义的字段，值必须可映射
- 汇总数据对账：源系统总数 = 目标系统总数 ± 允许误差
- 编码标准检查：字典值、枚举值是否遵循统一规范
我的建议：一致性监控最好在数据交换层做。每次数据同步完成后，立刻跑一个对账脚本。别等到第二天才发现两边数据对不上，那时候业务已经用错误数据做决策了。
2.4 及时性 —— 数据来晚了就是废纸
及时性，衡量的是数据从产生到可用，花了多长时间。
做实时数仓那会儿，业务要求交易数据 5 分钟内可见。结果有个接口延迟了 20 分钟，运营团队拿着过时的数据做促销，优惠券发重了，损失几十万。嗯，从那以后我再也不敢忽视及时性。
及时性监控的关键指标：
- 数据延迟：源系统产生时间 vs 目标系统落地时间
- 调度超时：ETL 任务是否在规定窗口内完成
- 数据新鲜度：当前时间 vs 数据最新时间戳
- 批次间隔：相邻两次数据更新的时间差
小技巧：我习惯给每个数据表加一个 etl_update_time 字段。监控脚本每隔 5 分钟扫一次，如果某个表超过 30 分钟没更新，立刻告警。简单粗暴，但有效。
2.5 唯一性 —— 别让同一条数据出现两次
唯一性，就是数据有没有重复。
唯一性问题最常见，也最隐蔽。我见过一个用户表，同一个身份证号出现了 3 次，原因是三个系统分别注册，没有做去重。结果营销活动给同一个人发了 3 份礼品，成本翻了三倍。
唯一性监控的检查点：
- 主键唯一性：表主键是否有重复值
- 业务唯一性：业务上应该唯一的字段（如身份证号、手机号）是否重复
- 联合唯一性：多个字段组合是否唯一（如订单号+商品ID）
- 全表去重率：重复记录占总记录的比例
-- 唯一性检查 SQL 示例
-- 检查订单表主键是否重复
SELECT order_id, COUNT(*) as cnt
FROM orders
GROUP BY order_id
HAVING COUNT(*) > 1;
-- 检查业务唯一性：同一用户同一天不能有重复订单
SELECT user_id, order_date, COUNT(*) as cnt
FROM orders
GROUP BY user_id, order_date
HAVING COUNT(*) > 1;
2.6 有效性 —— 数据符合业务规则吗？
有效性，是数据在业务语境下是否合理、是否合规。
举个例子：用户年龄字段填了 200 岁，从完整性看它不为空，从准确性看它是个数字，从唯一性看它不重复。但它有效吗？显然不。200 岁的人不可能存在。
有效性监控的常见规则：
- 业务规则校验：如「折扣率不能大于 100%」
- 逻辑关系校验：如「结束时间必须大于开始时间」
- 合规性校验：如「手机号必须符合国家编码规范」
- 引用完整性校验：如「外键值必须在主表中存在」
注意：有效性规则一定要和业务方确认。我曾经自作主张把「用户年龄超过 120 岁」定义为无效数据，结果发现有个特殊业务场景——历史数据里确实有 130 岁的用户（长寿老人）。所以，规则要灵活，要有白名单机制。
2.7 六大维度的优先级怎么排？
你可能会问：六个维度都重要，但资源有限，先搞哪个？
我个人习惯按这个优先级来：
- 完整性 —— 数据都不全，后面全白搭
- 准确性 —— 数据错了，比没有数据更可怕
- 一致性 —— 多系统协同，数据必须统一
- 及时性 —— 数据再准，来晚了也没用
- 唯一性 —— 重复数据会放大所有问题
- 有效性 —— 最后一道防线，确保数据可用
当然，这不是的。不同业务场景优先级不同。比如金融行业，准确性和一致性排第一；实时推荐系统，及时性排第一。关键是要根据业务目标来定权重。