📚 课程目录第2章数据质量维度

数据质量维度：完整性、准确性、一致性、及时性、唯一性

聊数据治理，绕不开一个核心问题：什么样的数据才算「好数据」？

我入行头两年，一直觉得数据质量就是个玄学。直到有一次，业务方拿着报表来找我，说同一个客户的成交金额，在三个系统里对不上。一个显示 100 万，一个显示 80 万，还有一个干脆是空的。嗯，那场面，挺尴尬的。

后来我慢慢总结出，衡量数据质量其实有五个硬指标。业内管它叫「数据质量五维度」——完整性、准确性、一致性、及时性、唯一性。说白了，就是给数据做体检的五个项目。

核心观点： 数据质量不是「好不好」的主观判断，而是五个可量化、可监控的客观维度。缺了任何一个，数据治理都会漏风。

完整性，说白了就是数据该有的字段有没有。比如客户表里，姓名、手机号、邮箱这些必填项，是不是都填了？

我在项目中遇到过一件事：一个电商平台的订单表，有 30% 的订单「收货地址」字段是空的。结果大促期间，物流公司直接罢工——地址都没有，往哪儿送？

我的经验： 完整性检查不能只看「字段是否为空」。还要看「业务语义上的完整」。比如身份证号，填了 15 位算不算完整？严格来说，18 位才算。所以完整性规则要跟业务对齐。

完整性监控的常见手段：

完整性只解决了「有没有」，准确性解决的是「对不对」。

举个例子：用户年龄字段填了「-5 岁」，完整性没问题——字段非空。但准确性呢？显然不对。我见过最离谱的一次，某个系统的「成交金额」字段，单位是「分」，但下游系统按「元」来读，结果报表上凭空多了 100 倍。

注意： 准确性问题的根源，往往是上游系统的数据录入不规范，或者字段定义不统一。我曾经排查过一个案例，发现是前端页面把「手机号」和「固话」混在一个字段里存，导致格式校验全乱套了。

准确性检查的常用方法：

一致性，是我个人觉得最头疼的一个维度。

你想想看，一个客户在 CRM 里叫「张三」，在 ERP 里叫「Zhang San」，在数据仓库里叫「ZS」。这三个系统说的到底是不是同一个人？

我在项目中遇到过更夸张的：同一个「订单状态」，A 系统用「0-已创建、1-已支付、2-已发货」，B 系统用「1-待支付、2-已支付、3-已完成」。两个系统数据一合并，状态直接乱套了。

我的建议： 一致性问题的根因，90% 是「主数据管理」没做好。如果你发现不同系统对同一个业务实体的描述总是打架，先别急着修数据，回头看看主数据模型是不是统一的。

及时性，衡量的是数据从产生到可用，花了多长时间。

举个例子：风控系统需要实时判断一笔交易是不是欺诈。如果数据延迟了 5 分钟，骗子早就把钱转走了。但如果是月度经营分析报表，延迟一天可能也能接受。

所以，及时性没有标准，关键看业务容忍度。

我习惯把及时性分成三个等级：

避坑指南： 我曾经遇到一个项目，业务方要求「实时数据」，结果一查，他们所谓的实时其实是 T+1 就能满足。所以，定义及时性指标时，一定要跟业务方确认清楚：「晚多久算不可接受？」

唯一性，就是同一个业务实体，在数据集中只出现一次。

听起来简单，做起来难。我见过一个客户主数据表，同一个「张三」出现了 7 次——因为每次录入时手机号写错了一位，系统就当成新客户了。

唯一性问题最直接的后果：统计口径混乱。比如「我们有多少客户？」——如果重复记录没去重，这个数字就永远不准。

唯一性检查的核心手段：

注意： 唯一性检查不能只依赖数据库主键。业务上的「唯一」往往比数据库的「唯一」复杂得多。比如，一个用户可能有多个手机号，但业务上只认一个「主手机号」。这时候，唯一性规则就要跟业务语义对齐。

讲完理论，说说实操。我个人习惯把这五个维度做成一张数据质量监控矩阵，每个维度对应一套检查规则和告警阈值。

维度	检查规则示例	告警阈值	修复策略
完整性	必填字段空值率	> 5% 告警	补录 / 默认值填充
准确性	格式校验 / 值域校验	错误率 > 1% 告警	回退上游 / 人工修正
一致性	跨系统字段对比	不一致率 > 0% 告警	主数据对齐 / 映射表
及时性	数据延迟时间	超过 SLA 阈值告警	优化 ETL / 链路排查
唯一性	重复记录率	> 0.5% 告警	去重合并 / 主键约束