2. 数据质量维度详解:完整性、准确性、一致性、及时性、唯一性、有效性

聊数据质量,绕不开这六个维度。我做了这么多年数据治理,见过太多团队一上来就搞复杂规则,结果连最基本的完整性都没守住。说白了,这六个维度就是数据质量的「体检指标」——你得先知道查什么,才能谈怎么治。

我个人习惯把这六个维度分成两组:基础三要素(完整性、准确性、一致性)和保障三要素(及时性、唯一性、有效性)。基础三要素决定数据「能不能用」,保障三要素决定数据「好不好用」。

数据质量六大维度关系图 数据质量 六大维度 完整性 Completeness 准确性 Accuracy 一致性 Consistency 及时性 Timeliness 唯一性 Uniqueness 有效性 Validity 基础三要素 保障三要素

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 六个维度怎么选?

你可能会问:是不是每个数据表都要监控全部六个维度?当然不是。我一般按这个优先级来:

  1. 核心业务表(订单、用户、支付):完整性 + 准确性 + 唯一性,必须全量监控
  2. 中间层表(汇总表、宽表):一致性 + 及时性,重点监控
  3. 日志/流水表:完整性 + 及时性,抽样监控即可

说白了,监控维度不是越多越好,而是越精准越好。你想想看,一个日志表你非要监控唯一性,那不是给自己找事吗?

总结一下:

  • 完整性:数据有没有缺失
  • 准确性:数据是不是对的
  • 一致性:数据之间是否矛盾
  • 及时性:数据有没有过期
  • 唯一性:数据有没有重复
  • 有效性:数据是否合规

这六个维度不是孤立的,它们互相影响。比如完整性差,准确性肯定受影响;一致性差,有效性也会出问题。所以,搭建监控体系时,一定要从全局视角出发。