一、数据质量概述:从“能用”到“可信”

做数据治理这些年,我经常被问到同一个问题:“数据质量到底是个啥?”

有人觉得数据没报错就是高质量,有人觉得数据能跑出报表就行。说实话,这些理解都太浅了。数据质量不是非黑即白的事,它更像一把尺子,衡量你的数据到底“有多靠谱”。

我刚开始带数据团队时,接过一个电商客户的项目。他们的订单表每天几百万条记录,系统跑得挺欢。结果一查,用户ID重复率超过15%,地址字段三分之一是空的。老板看着报表说“数据没问题啊”,但营销活动发出去,退货率直接飙到40%。

你看,数据质量差,后果是实打实的。

一句话总结:数据质量不是技术问题,是业务信任问题。数据不可信,再牛的算法也是空中楼阁。

1.1 什么是数据质量?

数据质量,说白了就是数据满足使用要求的程度。它不是一个概念——同一份数据,在A场景下是高质量的,换到B场景可能就完全不能用。

举个例子:

  • 用户注册时间精确到年,做年度统计没问题;但你要分析用户活跃时段,这数据就是垃圾。
  • 商品价格保留两位小数,财务对账够用;但做价格弹性模型,精度就不够了。

我个人习惯把数据质量分成两个层面:

  1. 内在质量:数据本身是否准确、完整、一致。这是基础。
  2. 使用质量:数据在具体业务场景下是否“够用”。这是目的。

很多团队只盯着内在质量,把数据清洗得干干净净,结果业务部门还是说“不好用”。为什么?因为没搞清楚人家到底要什么。

我的经验:定义数据质量之前,先问三个问题——谁在用?用来干什么?用到什么程度?答案清楚了,质量标准自然就出来了。

1.2 数据质量为什么重要?

这个问题,我一般用三个层次来回答:

层次 影响 真实案例
决策层 错误数据导致错误判断 某零售企业因库存数据不准,多采购了30%的货,积压资金上千万
运营层 流程中断、效率低下 银行对账系统因字段格式不一致,每天人工处理2小时异常数据
技术层 模型失效、系统崩溃 推荐模型因用户画像数据缺失,点击率从8%掉到1.5%

我记得有一次帮一家物流公司做数据诊断。他们的配送时效数据,系统里显示平均2.3天,但客户投诉说经常要等5天以上。一查才发现,系统只记录了“揽收”到“到达网点”的时间,最后三公里的配送时间根本没算进去。

你看,数据质量差,连基本的管理决策都会跑偏。

避坑提醒:我曾经见过一个团队,花三个月把数据质量做到99.9%,结果业务部门根本不买账。为什么?因为他们做的质量指标跟业务KPI完全脱节。数据质量一定要跟业务价值挂钩,否则就是自嗨。

1.3 数据质量的五个核心维度

聊数据质量,绕不开这五个维度。我习惯把它们叫做“五把尺子”,每把尺子量一个方面。

先看一张图,把这五个维度的关系理清楚:

数据质量五维度框架图 数据质量 准确性 完整性 一致性 及时性 唯一性 五个维度相互独立又彼此影响,缺一不可

下面我一个个拆开讲,每个维度都带上我踩过的坑。

1.3.1 准确性

准确性是最直观的维度——数据记录的值跟真实世界是否一致。

比如用户年龄字段,真实年龄28岁,数据库里写的是82岁。这就是不准确。

我在项目中遇到过最离谱的一次:某系统的“订单金额”字段,因为精度设置问题,所有金额自动除以了100。财务对账对了一个月没对上,最后发现是开发把“分”当“元”存了。

检查方法:准确性没有银弹。我常用的手段是交叉验证——用不同来源的数据互相核对,或者抽样人工核查。自动化规则只能发现明显异常,真正的准确性要靠业务逻辑来验证。

1.3.2 完整性

完整性衡量的是数据有没有缺失。缺失可能是字段为空,也可能是整条记录丢失。

举个例子:用户注册表有100万条记录,但“手机号”字段有20万条是空的。这就是完整性有问题。

我曾经帮一家医疗公司做数据治理。他们的患者病历表,关键字段“诊断结果”缺失率高达40%。这意味着近一半的病历无法用于后续分析。后来一查,是前端表单设计不合理,医生嫌麻烦直接跳过了。

注意:完整性不是越高越好。有些字段允许为空是业务需要。比如“配偶姓名”,单身用户就是没有。关键是要区分“业务允许为空”和“数据丢失”。

1.3.3 一致性

一致性指的是同一数据在不同系统、不同时间点是否保持一致。

这是数据治理里最头疼的问题之一。同一个客户,CRM系统里叫“张三”,订单系统里叫“张先生”,财务系统里叫“Zhang San”。你说这是同一个人吗?

我记得有个项目,两个系统对“订单状态”的定义完全不同:A系统用“已支付/未支付”,B系统用“待发货/已发货/已完成”。数据一打通,状态映射全乱套了。

场景 不一致表现 常见原因
跨系统 同一客户在不同系统信息不同 数据标准不统一
跨时间 同一指标历史数据与当前数据口径不同 业务规则变更未同步
跨格式 日期格式、编码规则不一致 缺乏统一规范

1.3.4 及时性

及时性衡量数据从产生到可用的时间差。数据再准再全,如果来得太晚,就是废纸。

举个例子:风控系统需要实时判断交易是否欺诈。如果数据延迟30分钟,骗子早就把钱转走了。

我见过一个极端案例:某电商的库存数据每天凌晨同步一次。白天卖出去的商品,系统里库存还是昨天的数。结果超卖了几千单,用户投诉炸了。

关键判断:及时性的标准取决于业务场景。实时交易需要秒级延迟,月度报表可以接受小时级延迟。别盲目追求“实时”,够用就行。

1.3.5 唯一性

唯一性要求每条数据实体在系统中只出现一次,没有重复。

这个维度看起来简单,做起来最难。为什么?因为“唯一”的定义往往不清晰。

比如“用户”这个实体,是用身份证号唯一标识,还是用手机号?如果一个人有两个手机号注册了两个账号,算不算重复?

我曾经处理过一个案例:某平台的用户表,用邮箱作为唯一标识。结果同一个用户换了邮箱重新注册,系统里就有了两条记录。后续的推荐、营销全乱套了。

我的建议:定义唯一性之前,先搞清楚业务上“一个实体”到底长什么样。然后建立主数据管理(MDM)体系,用全局ID来打通。

1.4 五个维度的关系

这五个维度不是孤立的。它们之间经常互相影响:

  • 准确性 & 一致性:数据不准确,跨系统对比时必然不一致。
  • 完整性 & 准确性:缺失值太多,剩下的数据也容易失真。
  • 及时性 & 准确性:为了追求及时,可能牺牲数据校验的准确性。
  • 唯一性 & 完整性:重复数据往往伴随着信息不完整。

所以做数据质量诊断时,别只盯着一个维度。我习惯先做全局扫描,找出最薄弱的环节,再针对性修复。

核心原则:数据质量不是“一次性工程”,而是持续改进的过程。先诊断,再修复,然后监控,最后优化——循环往复。