2. 数据质量维度（上）：完整性、准确性、一致性、及时性

聊数据质量，绕不开一个基础框架——质量维度。说白了，就是我们从哪几个角度去评判一批数据「好不好」。我个人习惯把维度比作体检指标：血压、心率、血氧，每一项都指向不同的健康问题。数据也一样，不同维度暴露不同病灶。

这一章我们先讲四个最核心的维度：完整性、准确性、一致性、及时性。另外四个（唯一性、规范性、关联性、稳定性）留到下章。嗯，一口气吃不成胖子，咱们分两趟搬完。

2.1 完整性（Completeness）

完整性，就是看数据有没有「缺胳膊少腿」。你想想看，一张客户表，身份证号空了一半，手机号缺了三分之一——这数据你敢用？

我在项目中遇到过最典型的场景：某电商平台做用户画像分析，结果发现「性别」字段缺失率高达 40%。模型跑出来，推荐准确率直接掉了 15 个点。后来一查，是前端注册页面没做必填校验。

完整性可以从三个层面去检查：

• 记录完整性：该有的行有没有少？比如日活报表，某一天的数据丢了。
• 字段完整性：该有的列有没有空？比如用户的邮箱、地址。
• 值完整性：字段值本身是否完整？比如身份证号只有 15 位（标准是 18 位）。

2.2 准确性（Accuracy）

准确性，说白了就是数据「对不对」。完整性保证数据没缺，准确性保证数据没错。两者是递进关系——数据不缺但全是错的，比缺数据更可怕。

我记得有一次帮一家银行做数据审计，发现某客户的「年龄」字段显示 180 岁。嗯，这显然不是寿星，是录入时把出生年份和当前年份搞反了。这种错误，完整性检查根本发现不了。

准确性检查通常包括：

1. 值域校验：年龄 0-150，超出就是异常。
2. 格式校验：手机号 11 位，邮箱必须带 @。
3. 精度校验：金额字段，小数点后不能超过两位。
4. 业务逻辑校验：下单时间不能晚于发货时间。

2.3 一致性（Consistency）

一致性，就是看数据之间「有没有打架」。同一个客户，在 CRM 系统里叫「张三」，在 ERP 系统里叫「张 三」（中间多了个空格），在财务系统里叫「Zhang San」。你说这是同一个人吗？

你想想看，跨系统数据集成的时候，一致性问题是重灾区。我见过最夸张的案例：某零售企业，库存系统显示某商品还有 500 件，但销售系统显示已售出 800 件。两个系统对不上，采购部门不知道该不该补货。

一致性检查主要分三类：

类型	说明	示例
格式一致性	同一字段在不同系统中格式统一	日期格式：2024-01-01 vs 01/01/2024
值域一致性	同一字段的枚举值定义一致	性别：男/女 vs M/F vs 1/2
逻辑一致性	关联字段之间的逻辑关系成立	订单总金额 = 各商品金额之和

2.4 及时性（Timeliness）

及时性，就是数据「到得够不够快」。数据再准再全，如果来得太晚，就失去了价值。比如风控系统，需要实时判断一笔交易是否欺诈。如果数据延迟 5 分钟，骗子早就把钱转走了。

我参与过一个物流调度项目，GPS 轨迹数据每 30 秒上报一次。但有一次因为网络抖动，数据延迟到了 10 分钟。调度系统拿到的位置信息严重滞后，导致车辆调度完全乱套。嗯，这就是及时性出了问题。

及时性通常用两个指标衡量：

• 延迟时间：从数据产生到可被消费的时间差。
• 时效性窗口：数据在业务上有效的时间范围。

不同业务场景对及时性的要求天差地别：

业务场景	容忍延迟	说明
实时风控	毫秒级	超过 1 秒就可能造成损失
交易对账	T+1	次日完成对账即可
经营报表	小时级	管理层看的是趋势，不要求实时
离线分析	天级	跑批任务，延迟一天正常

2.5 四个维度的关系

这四个维度不是孤立的。它们之间经常互相影响。举个例子：

• 完整性差 → 准确性也会受影响（缺数据导致统计偏差）
• 一致性差 → 及时性可能被拖累（数据对不上，需要人工核对，延迟就上来了）
• 及时性差 → 准确性也可能下降（数据过期了，业务逻辑变了，旧数据就不准了）

所以做数据质量诊断的时候，我习惯先扫一遍完整性，再看准确性，然后做一致性交叉验证，最后检查及时性。这个顺序，能帮你最快定位到根因。