一、数据质量概述

聊数据质量之前，我先问个问题：你手头的数据，真的能用吗？

很多人觉得，数据嘛，存进数据库就完事了。但我在几个数据治理项目里摔过跟头之后，才真正明白——数据质量不是锦上添花，而是地基。地基不稳，上面盖的报表、模型、AI应用，全得塌。

1.1 数据质量的定义

数据质量，说白了就是数据满足使用需求的程度。

别小看这句话。它包含两层意思：

• 满足需求——数据好不好，得看谁来用、怎么用。财务要精确到分，运营看趋势可以容忍±5%的误差。
• 程度高低——质量不是非黑即白，而是个连续谱。我习惯用「数据质量分数」来量化，0到100，低于60就得亮红灯。

举个例子。我在一家电商公司做数据治理时，业务部门抱怨「用户画像不准」。一查，问题出在注册时手机号校验太松，同一个用户用不同号码注册了三次。数据本身没错，但用在用户分群场景里，质量就是不及格。

1.2 数据质量五大维度

评估数据质量，不能凭感觉。业界公认的五大维度，我一个个说。

维度	定义	我踩过的坑
准确性	数据反映真实世界的程度	某系统把「2023-01-01」存成「2023-01-02」，整条订单记录全偏
完整性	数据是否缺失关键字段	用户表中手机号缺失率30%，营销活动根本跑不起来
一致性	不同系统间数据是否矛盾	CRM和ERP里同一个客户的名称不一样，对账对到崩溃
及时性	数据从产生到可用是否延迟	实时风控需要秒级，但数据管道延迟了5分钟，损失惨重
唯一性	是否存在重复记录	同一个用户被创建了3个账号，推送消息发了3遍

准确性

准确性是最直观的维度。数据错了，后面全白搭。

我记得有一次做银行数据迁移，发现某笔交易金额多了两个零。查到最后，是源系统字段类型定义错了，把分当作元存了。这种问题，靠人工检查根本防不住，必须上规则引擎。

完整性

完整性看的是「该有的有没有」。缺失字段，比错误数据更隐蔽。

我之前接手过一个用户画像项目，数据表里「年龄」字段缺失率高达40%。业务方说「凑合用吧」，结果模型上线后，推荐准确率直接腰斩。你想想看，缺失值不处理，模型学到的全是偏见。

完整性校验，我一般分三级：

• 必填字段：主键、业务关键字段（订单号、用户ID），缺失直接拒绝入库
• 推荐字段：辅助分析字段（年龄、性别），缺失可以入库但打标签
• 可选字段：备注、扩展信息，缺失不影响核心流程

一致性

一致性是数据治理里最头疼的问题。为什么？因为数据散落在不同系统里，每个系统都有自己的「方言」。

举个例子。CRM系统里客户名称是「阿里巴巴集团」，ERP系统里是「阿里巴巴(中国)网络技术有限公司」。你说这俩是不是同一个？人眼能判断，机器不行。规则引擎里就得配「相似度匹配」规则，比如编辑距离小于3就认为是同一实体。

及时性

及时性，说白了就是数据「新不新鲜」。

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

• 实时场景：交易风控、实时推荐，延迟超过1秒就不可接受
• 准实时场景：库存同步、物流追踪，容忍分钟级延迟
• 离线场景：月度报表、财务对账，T+1甚至T+7都行

我建议在规则引擎里给每个数据源配一个「SLA时钟」。比如「订单表数据必须在事件发生后5分钟内到达数仓」，超时就告警。别等到业务方投诉了才发现数据没更新。

唯一性

唯一性，就是防止「一个人占多个坑」。

唯一性问题最常见的场景：

• 用户注册：同一个手机号/身份证号注册多个账号
• 订单导入：同一个订单号被重复导入两次
• 设备上报：同一个设备ID上报了多条重复日志

唯一性校验，核心是「业务主键」的确定。技术上的主键（自增ID）不能替代业务主键。我习惯在规则引擎里配置「联合唯一约束」，比如「用户ID + 订单类型 + 订单日期」组合必须唯一。

1.3 数据质量问题产生的原因

问题不会凭空出现。我总结下来，数据质量问题的根因就三类：

1. 源头污染

数据在产生的那一刻就错了。常见原因：

• 人工录入错误：手抖输错、粘贴错行。我见过最离谱的，是把「张三」输成了「张三三」
• 系统接口缺陷：API字段映射错了、编码转换丢了字符
• 设备采集误差：传感器漂移、GPS定位偏差

源头污染，最好的治理策略是「防」而不是「治」。在数据入口加校验规则，比事后清洗成本低得多。

2. 传输与加工损耗

数据在流转过程中「变质」了。典型场景：

• ETL脚本bug：join条件写错，导致数据膨胀或丢失
• 中间件丢消息：Kafka topic配置不合理，部分消息被丢弃
• 字段截断：源字段长度200，目标字段长度50，数据被硬生生截断

我记得有一次排查数据对不上的问题，最后发现是ETL里用了LEFT JOIN，但业务上应该是INNER JOIN。这种逻辑错误，靠人工review很难发现，必须靠规则引擎做「数据对账」。

3. 管理缺失

这是最隐蔽、也最难解决的一类问题。

• 标准不统一：不同部门对「活跃用户」的定义不一样，数据没法对齐
• 权限混乱：谁都能改数据，改完没有审计日志
• 缺乏监控：数据质量出问题了没人知道，等发现时已经积重难返

1.4 数据质量知识体系总览

下面这张图，把本章的核心内容串起来了。你可以把它当作数据质量治理的「地图」。

这张图展示了数据质量治理的完整链路：从定义出发，用五大维度评估现状，再追溯根因，最后用规则引擎落地治理。后面的29章，就是一步步教你把这个链路做实、做细。