2. 数据质量维度详解:完整性、准确性、一致性、及时性、唯一性、有效性
聊数据质量,绕不开这六个维度。我做了这么多年数据治理,见过太多团队一上来就搞复杂规则,结果连最基本的完整性都没守住。说白了,这六个维度就是数据质量的「体检指标」——你得先知道查什么,才能谈怎么治。
我个人习惯把这六个维度分成两组:基础三要素(完整性、准确性、一致性)和保障三要素(及时性、唯一性、有效性)。基础三要素决定数据「能不能用」,保障三要素决定数据「好不好用」。
2.1 完整性:数据有没有「缺胳膊少腿」
完整性是数据质量的第一道防线。它衡量的是数据记录、字段、关系有没有缺失。你想想看,一个用户表里手机号字段 30% 是空的,这数据你敢用吗?
衡量标准其实就三个层面:
- 记录完整性:实际记录数 vs 预期记录数。比如每天应该同步 100 万条订单,实际只到了 80 万,那就是 80% 的完整率。
- 字段完整性:非空字段的填充率。核心业务字段(如订单金额、用户 ID)必须 100% 填充。
- 关系完整性:外键关联是否存在悬空引用。比如订单表引用了不存在的用户 ID。
核心公式:字段完整率 = (非空记录数 / 总记录数) × 100%
阈值建议:核心字段 ≥ 99.9%,非核心字段 ≥ 95%
我在项目中遇到过最典型的场景:某电商平台做用户画像分析,结果发现「年龄」字段缺失率高达 40%。一查原因,原来是前端注册页面把年龄设为选填,但后端做数据分析时直接当必填字段用了。嗯,这里要注意——完整性监控必须从数据源头开始,不能等数据进了数仓再补救。
2.2 准确性:数据是不是「对的」
完整性只告诉你数据「有没有」,准确性告诉你数据「对不对」。这是两个完全不同的概念。
举个例子:用户表里「年龄」字段填了 200 岁——完整性是 100%,但准确性是 0%。
衡量标准我一般分三类:
| 准确性类型 | 定义 | 衡量方式 | 示例 |
|---|---|---|---|
| 值域准确性 | 数据值是否在合理范围内 | 范围校验、枚举校验 | 年龄 0-150,性别只能是男/女 |
| 业务准确性 | 数据是否反映真实业务 | 交叉验证、抽样核对 | 订单金额 vs 支付流水金额 |
| 格式准确性 | 数据格式是否符合规范 | 正则匹配、格式校验 | 手机号 11 位,邮箱含 @ |
我的经验:准确性监控最容易踩的坑是「过度校验」。我曾经见过一个团队给地址字段写了 50 条正则规则,结果误杀率高达 30%。建议先做值域校验,再逐步加业务校验,别想一口吃成胖子。
2.3 一致性:数据之间「打架」了吗
一致性解决的是「同一个数据在不同地方是不是同一个说法」。说白了,就是数据之间别互相矛盾。
我遇到过最经典的案例:某银行客户系统里,同一个客户在理财系统里叫「张三」,在信贷系统里叫「张 三」(中间多了个空格)。两个系统数据一交叉,直接导致风控模型跑出来的结果自相矛盾。
衡量标准:
- 跨系统一致性:同一实体在不同系统中的关键属性是否一致。比如客户姓名、身份证号。
- 跨表一致性:同一数据库内,关联表之间的数据是否逻辑自洽。比如订单总金额 = 订单明细金额之和。
- 时间一致性:数据的时间戳、版本号是否对齐。比如更新时间不能早于创建时间。
避坑指南:我曾经在做一个数据仓库项目时,发现两个源系统的「客户等级」字段定义完全不同——一个用 A/B/C,一个用 1/2/3。如果不做映射转换就直接合并,一致性校验永远过不了。所以,一致性监控的前提是统一数据标准。
2.4 及时性:数据「过期」了没
及时性衡量的是数据从产生到可用的时间差。你想想看,做实时风控的数据如果延迟了 10 分钟,那跟没有数据有什么区别?
衡量标准:
| 指标 | 定义 | 适用场景 |
|---|---|---|
| 数据延迟 | 数据产生时间 - 数据到达时间 | 实时/准实时系统 |
| 处理时效 | ETL 作业完成时间 - 作业开始时间 | 离线数仓 |
| 调度成功率 | 按时完成调度的作业数 / 总作业数 | 所有场景 |
我个人习惯给不同业务线设定不同的 SLA。比如交易数据要求延迟 ≤ 5 分钟,报表数据可以放宽到 T+1。千万别一刀切——及时性标准要跟业务价值挂钩。
2.5 唯一性:数据「重复」了没
唯一性,说白了就是「一条数据只出现一次」。重复数据会直接导致统计结果失真、主键冲突、存储浪费。
衡量标准:
- 主键唯一性:主键字段是否有重复值。这是数据库层面的硬约束。
- 业务唯一性:业务逻辑上不应该重复的数据是否真的唯一。比如同一笔订单不应该出现两条记录。
- 重复率:重复记录数 / 总记录数。一般要求 ≤ 0.1%。
核心公式:重复率 = (重复记录数 / 总记录数) × 100%
阈值建议:核心实体(用户、订单)重复率 ≤ 0.01%,非核心实体 ≤ 0.1%
我曾经在做一个 CRM 系统数据迁移时,发现客户表里同一个手机号出现了 3 次,但姓名、地址都不一样。一查才知道,是不同渠道录入时没有做去重。嗯,这里要注意——唯一性监控不能只靠数据库唯一索引,业务层面的去重逻辑更重要。
2.6 有效性:数据「合规」吗
有效性是六个维度里最容易被忽视的。它衡量的是数据是否符合业务规则、法律法规和格式要求。
举个例子:用户身份证号必须是 18 位,最后一位可以是 X。如果出现 19 位或者中间有字母,那就是无效数据。
衡量标准:
| 有效性类型 | 定义 | 校验方式 |
|---|---|---|
| 格式有效性 | 数据格式是否符合规范 | 正则表达式、格式模板 |
| 业务有效性 | 数据是否满足业务规则 | 业务逻辑校验、枚举值校验 |
| 合规有效性 | 数据是否符合法律法规 | 敏感数据脱敏、隐私合规检查 |
我的建议:有效性规则一定要跟业务方一起定义。我见过太多技术团队自己拍脑袋写规则,结果上线后业务方说「这个字段本来就是允许为空的」。记住,有效性是业务规则的技术映射,不是技术人员的自嗨。
2.7 六个维度怎么选?
你可能会问:是不是每个数据表都要监控全部六个维度?当然不是。我一般按这个优先级来:
- 核心业务表(订单、用户、支付):完整性 + 准确性 + 唯一性,必须全量监控
- 中间层表(汇总表、宽表):一致性 + 及时性,重点监控
- 日志/流水表:完整性 + 及时性,抽样监控即可
说白了,监控维度不是越多越好,而是越精准越好。你想想看,一个日志表你非要监控唯一性,那不是给自己找事吗?
总结一下:
- 完整性:数据有没有缺失
- 准确性:数据是不是对的
- 一致性:数据之间是否矛盾
- 及时性:数据有没有过期
- 唯一性:数据有没有重复
- 有效性:数据是否合规
这六个维度不是孤立的,它们互相影响。比如完整性差,准确性肯定受影响;一致性差,有效性也会出问题。所以,搭建监控体系时,一定要从全局视角出发。