2. 数据质量六大维度详解
数据质量不是一句空话。你得有具体的尺子去量。
我个人习惯把这六个维度当作数据质量的「体检指标」。就像人做体检要查血压、血糖、心率一样，数据也得从完整性、准确性、一致性、及时性、唯一性、有效性这六个角度去检查。缺了哪个维度，你的数据都可能「带病上线」。
核心观点：六个维度不是孤立存在的。一个字段可能同时违反多个维度规则。比如「用户手机号为空」既违反完整性，也违反有效性。实际分析时，要综合判断。
2.1 完整性
完整性，说白了就是「该有的数据有没有」。一个字段如果本不该为空，结果空了一大片，那就是完整性问题。
我记得有一次做电商订单分析，发现「收货地址」字段有 30% 是空的。这直接导致物流系统无法发货。后来一查，是前端页面把地址设为非必填了。你看，一个完整性问题，源头可能在前端设计。
实战技巧：完整性检查不只是看 NULL。空字符串、空格、占位符（如 'N/A'、'-'）也算「事实上的缺失」。我习惯用 TRIM(字段) = '' OR 字段 IS NULL 来统一判断。
完整性检查的常见场景：
- 必填字段缺失：身份证号、手机号、邮箱等关键标识为空
- 关联记录缺失：订单表引用了不存在的用户 ID
- 历史数据断层：某段时间的数据完全没有入库
- 部分字段缺失：一条记录中只有部分列有值
2.2 准确性
数据有了，但值对不对？这就是准确性要管的事。
准确性和完整性不一样。完整性是「有没有」，准确性是「对不对」。举个例子：用户年龄字段填了「200」岁，完整性没问题，但准确性一塌糊涂。
我在项目中遇到过最典型的准确性问题是金额字段。某系统把「分」当成了「元」来存，结果所有报表金额都差了 100 倍。这种问题，光靠完整性检查根本发现不了。
注意：准确性检查通常需要外部参照。比如用身份证号校验位验证号码真伪，用第三方地址库验证地址是否存在。没有参照，你很难判断一个值「对不对」。
准确性检查的常用方法：
- 范围校验：年龄 0-150，月份 1-12
- 业务规则校验：下单时间不能晚于发货时间
- 参照数据校验：城市名必须在国家标准城市列表中
- 统计分布校验：均值、标准差是否在合理区间
2.3 一致性
同一个数据，在不同地方应该长得一样。这就是一致性。
你想想看，用户表里性别存的是「男/女」，订单表里存的是「M/F」，日志表里存的是「1/0」。这三个表一关联，你根本没法直接做统计。这就是典型的不一致。
我见过最夸张的一个案例：同一个客户的姓名，在 CRM 系统里叫「张三」，在财务系统里叫「张 三」（中间多了个空格），在物流系统里叫「Zhang San」。三个系统各自为政，最后做客户画像时数据完全对不上。
| 不一致类型 | 示例 | 影响 |
|---|---|---|
| 格式不一致 | 日期：2024-01-01 vs 2024/01/01 | 关联查询失败 |
| 编码不一致 | 性别：男/M/1 | 统计结果偏差 |
| 单位不一致 | 金额：元 vs 分 | 计算错误 |
| 精度不一致 | 价格：10.00 vs 10 | 汇总对不上 |
我的建议：一致性问题的根因往往是「没有统一的数据标准」。解决之道是建立企业级数据字典，所有系统按同一套规范来。但这需要组织层面的推动，光靠技术很难搞定。
2.4 及时性
数据来得太晚，等于没来。及时性衡量的是数据从产生到可用的时间差。
举个例子：风控系统需要实时判断交易是否欺诈。如果数据延迟了 5 分钟，骗子早就把钱转走了。这时候数据再准确也没用。
我曾经帮一家物流公司排查过及时性问题。他们的运输轨迹数据每天凌晨才批量同步，但业务部门需要实时查看车辆位置。结果就是：调度员看到的永远是昨天的位置，根本没法做实时调度。
衡量指标：我常用「数据新鲜度」来衡量及时性。公式很简单：当前时间 - 数据产生时间。对于实时场景，这个值应该控制在秒级；对于离线场景，可以放宽到 T+1。
及时性问题通常来自：
- ETL 调度延迟：任务排队、资源不足导致跑不完
- 源系统推送延迟：上游系统没有及时产生数据
- 网络传输瓶颈：数据量太大，带宽不够
- 批处理窗口过长：全量同步代替增量同步
2.5 唯一性
唯一性，就是「同一个实体不能出现两次」。听起来简单，做起来难。
你想想看，一个用户注册了两次，生成了两个用户 ID。这两个 ID 对应的是同一个人，但在系统里是两条记录。这就是重复数据，违反了唯一性。
我在做客户数据清洗时遇到过这种情况：同一个手机号出现了 3 次，但姓名、地址都略有不同。后来发现是不同渠道的注册入口没有做去重。嗯，这种问题在数据集成时特别常见。
避坑指南：唯一性检查不能只看主键。主键唯一不代表业务唯一。比如两个订单 ID 不同，但都指向同一笔真实交易，这仍然是重复数据。我曾经就因为这个被业务部门投诉过——「你们说数据没问题，但报表里订单数翻了一倍！」
唯一性检查的关键点：
- 主键唯一：数据库层面的硬约束
- 业务主键唯一：如身份证号、手机号、订单号
- 组合唯一：多个字段联合判断是否重复
- 模糊匹配去重：姓名+地址相似度判断
2.6 有效性
有效性，就是「数据是否符合规定的格式和规则」。它和准确性有点像，但更偏重格式层面。
举个例子：手机号字段填了「123456」，格式不对，这就是无效数据。但你说它「不准确」吗？它确实是个号码，只是不符合手机号的规则。
我记得有一次做数据迁移，发现大量邮箱地址没有「@」符号。一查，是旧系统允许用户随便填。这些数据迁移到新系统后，连邮件都发不出去。这就是有效性没把关的后果。
| 字段类型 | 有效性规则示例 | 无效数据示例 |
|---|---|---|
| 手机号 | 11 位数字，以 1 开头 | 12345678901（非 1 开头） |
| 邮箱 | 包含 @ 和域名 | zhangsan（无 @） |
| 身份证号 | 18 位，含校验位 | 11010119900101001X（少一位） |
| 日期 | YYYY-MM-DD 格式 | 2024/13/01（月份超范围） |
| 枚举值 | 必须在码表中 | 性别填「未知」但码表无此值 |
核心思路：有效性检查最好在数据入口就做。前端校验、API 校验、数据库约束，层层设防。等数据进了数仓再发现无效，修复成本就高了。我习惯在数据接入层就配置好有效性规则，不合格的数据直接拒掉或进死信队列。
2.7 六个维度的关系
这六个维度不是各自为政的。它们之间有很强的关联性。
举个例子：一条记录完整性没问题（所有字段都有值），但准确性有问题（年龄填了 200）。另一条记录准确性没问题，但唯一性有问题（重复了 3 次）。你修复的时候，得综合考虑。
我个人习惯用「维度矩阵」来分析问题。比如：
- 完整性 + 准确性：数据既要有，还要对
- 一致性 + 唯一性：跨系统不打架，同系统不重复
- 及时性 + 有效性：来得快，格式还对
实战建议：刚开始做数据质量评估时，不要六个维度一起上。先挑 2-3 个最关键的维度切入。比如金融行业先抓准确性和一致性，电商行业先抓完整性和及时性。等团队成熟了，再逐步覆盖所有维度。