2. 数据质量维度体系：六大维度的定义与度量
聊数据质量，绕不开这六个维度。我做了这么多年数据治理，见过太多团队一上来就搞「数据质量评分」，结果连维度都没对齐——你说你的完整性，我说我的准确性，最后吵成一锅粥。
所以这一章，咱们把六大维度掰开揉碎讲清楚。每个维度怎么定义、怎么度量、有什么坑，我都会结合项目里的真实案例来说。
2.1 完整性
定义：数据是否缺失。说白了，就是该有的数据有没有。
完整性分两个层面：
- 记录完整性：表里该有多少行，实际有多少行
- 字段完整性：某列该填的值，空值比例是多少
度量公式：
完整性 = 1 - (空值记录数 / 总记录数)或者按字段粒度：
字段完整性 = 非空记录数 / 总记录数我在项目中遇到过一件事：某客户说他们的订单表完整性是 99.9%，结果一查，订单金额字段空了 30%。为什么？因为他们只统计了主键的完整性。嗯，这里要注意——完整性度量必须指定字段范围，不能只看主键。
我的习惯：做完整性检查时，我会把字段分成「必填字段」和「可选字段」两套标准。必填字段完整性必须 ≥ 99.5%，可选字段可以放宽到 95%。
2.2 准确性
定义：数据值是否真实反映客观事实。你想想看，数据填得再全，如果内容是错的，那还不如不填。
准确性是最难度量的维度，因为它需要「真相源」。常见的做法有：
- 与权威系统比对：比如客户姓名跟身份证系统核对
- 业务规则校验：比如年龄不能超过 150 岁
- 人工抽检：随机抽取样本，人工确认
度量公式：
准确性 = 通过校验的记录数 / 总记录数我曾经踩过一个坑：某项目用「与源系统一致」作为准确性标准，结果源系统本身就是错的。后来我学乖了——准确性校验必须先确认参考源的权威性，否则就是拿错误验证错误。
避坑指南：我曾经见过一个团队，把「格式正确」当成「准确」。比如手机号是 11 位数字就算准确，但号码本身是空号。这其实是有效性，不是准确性。别搞混了。
2.3 一致性
定义：同一数据在不同系统、不同表中是否保持一致。说白了，就是「同一个东西，别到处长不一样」。
一致性常见问题：
- 跨系统不一致：CRM 里客户叫「张三」，ERP 里叫「张先生」
- 跨表不一致：订单表的客户 ID 在客户表里找不到
- 时间维度不一致：昨天统计的销售额和今天统计的不一样
度量公式：
一致性 = 1 - (不一致记录数 / 总关联记录数)我建议做一致性检查时，先画一张「数据血缘图」，搞清楚哪些字段是同一个业务含义。否则你比对了一堆字段，结果人家本来就不是同一个东西——白费功夫。
2.4 及时性
定义：数据从产生到可用，是否满足时间要求。你想想看，双十一的实时大屏，数据晚到 5 分钟，运营同学就得骂娘。
及时性分两个维度：
- 延迟时间：数据产生到入库的时间差
- 时效窗口：业务允许的最大延迟
度量公式：
及时性 = 在时效窗口内到达的记录数 / 总记录数我记得有个金融客户，要求交易数据必须在 30 秒内入仓。结果我们一测，平均延迟 25 秒，看起来达标了。但仔细一看，有 5% 的记录延迟超过 2 分钟——因为网络抖动。所以度量及时性，不能只看平均值，要看 P95 甚至 P99。
我的习惯：及时性指标我会设三个阈值——警告线、报警线、SLA 违约线。比如延迟超过 30 秒告警，超过 1 分钟触发 SLA 赔付。
2.5 唯一性
定义：数据实体是否被重复记录。说白了，就是「一个人/一件事，在系统里不能出现两次」。
唯一性问题通常出在：
- 主键重复：两张表合并时 ID 冲突
- 业务主键重复：同一个身份证号出现两次
- 近似重复：两个记录看起来不同，但其实是同一个人（比如「张三」和「张 三」）
度量公式：
唯一性 = 1 - (重复记录数 / 总记录数)这里有个坑——近似重复很难用 SQL 直接查。我曾经用 Levenshtein 距离算法做模糊匹配，结果误杀率很高。后来我学到的经验是：唯一性检查先做精确去重，再做模糊去重，而且模糊去重一定要有人工复核环节。
避坑指南：我曾经见过一个项目，把「唯一性」和「完整性」搞混了。主键不能为空是完整性，主键不能重复才是唯一性。这两个维度经常一起检查，但度量方式完全不同。
2.6 有效性
定义：数据值是否符合业务定义的格式、范围、编码规则。你想想看，性别字段填「男/女」是有效的，填「1/2」可能也是有效的，但填「A/B」就是无效的。
有效性检查常见规则：
- 格式校验：邮箱必须包含 @，手机号必须是 11 位数字
- 范围校验：年龄 0-150，温度 -40 到 60
- 枚举校验：状态字段必须在定义的枚举值列表里
- 编码校验：身份证号必须符合校验位规则
度量公式：
有效性 = 通过规则校验的记录数 / 总记录数我建议把有效性规则维护在「数据字典」或「元数据管理平台」里，不要写在代码里。否则每次改规则都要改代码，太痛苦了。
2.7 六大维度对比总览
下面这张表是我做项目时常用的速查表，方便你快速对比各维度的定义和度量方式：
| 维度 | 核心问题 | 度量方式 | 常见检查对象 |
|---|---|---|---|
| 完整性 | 数据有没有缺失 | 非空率 | 必填字段、主键 |
| 准确性 | 数据对不对 | 与真相源比对通过率 | 金额、日期、名称 |
| 一致性 | 数据在不同地方是否一样 | 跨系统/跨表比对通过率 | 客户 ID、订单状态 |
| 及时性 | 数据是否按时到达 | 时效窗口内到达率 | 实时数据、T+1 报表 |
| 唯一性 | 数据是否重复 | 重复率 | 主键、业务唯一标识 |
| 有效性 | 数据是否符合规则 | 规则校验通过率 | 格式、范围、枚举值 |
2.8 六大维度关系图
下面这张 SVG 图展示了六大维度之间的逻辑关系。我习惯把它分成三层：
从这张图你能看出来，六大维度不是平级的。完整性、有效性、唯一性是「基础三件套」——数据如果都不完整、不符合规则、还有重复，那后面的准确性、一致性、及时性根本无从谈起。
我习惯在项目里先做基础维度的检查，再往上做质量维度和时效维度。这样出了问题，排查起来也快——先看是不是基础没打好，再看是不是上层逻辑有问题。
2.9 维度选择建议
不是所有场景都需要六个维度全上。我建议根据数据用途来选：
- 财务数据：准确性 > 完整性 > 一致性，钱不能算错
- 客户数据：唯一性 > 完整性 > 有效性，一个人不能出现两次
- 实时数据：及时性 > 准确性 > 完整性，晚到比错更致命
- 监管报送：完整性 > 准确性 > 一致性，少报一条可能被罚
我的习惯：每个数据资产我会配一个「维度权重表」，比如订单表：完整性 0.3、准确性 0.3、一致性 0.2、及时性 0.1、唯一性 0.05、有效性 0.05。这样算综合评分时，重点维度权重高，结果更贴合业务。