数据质量基础：定义、六维与问题根源

聊数据治理，绕不开一个核心问题——数据质量。我见过太多项目，治理框架搭得漂漂亮亮，最后却栽在「数据不准」这个坎上。说白了，数据质量就是数据的「健康度」。你想想看，如果连基础数据都不可靠，上层分析、决策、AI模型，全成了空中楼阁。

这一章，我们先把地基打牢。我会结合自己踩过的坑，把数据质量的定义、六个核心维度，以及问题从哪来，掰开揉碎了讲清楚。

2.1 数据质量的定义

数据质量，不是一句「数据对不对」就能概括的。它更准确的描述是：数据满足特定业务场景使用要求的程度。

举个例子。我早年做过一个零售项目，库存表里的「商品数量」字段，从技术角度看，格式规范、没有空值，质量似乎不错。但业务部门一用就炸了——他们需要的是「可售库存」，而系统记录的是「物理库存」，中间差了被预订、被锁定、有瑕疵的货品。你看，数据本身没坏，但用起来就是不对。

所以，我建议团队在定义数据质量时，先问三个问题：

• 谁在用？——业务用户、数据分析师、还是机器学习模型？
• 用来干什么？——日常报表、风控决策、还是实时推荐？
• 容忍度多高？——允许1%的误差，还是必须99.999%准确？

搞清楚这些，质量评估才有靶子。

2.2 数据质量的六个维度

业界公认的数据质量评估框架，通常包含六个维度。我习惯把它们分成两组：「数据本身好不好」和「数据能不能用」。

下面这张图，是我在项目中常用的知识结构，帮你快速建立全局认知。

2.2.1 准确性

数据记录的值，与真实世界一致。这是最直观的维度。比如客户年龄字段，实际35岁，系统里录成53岁，这就是准确性出问题。

我在项目中遇到过最典型的场景：ERP系统里的物料编码，因为手工录入错误，把「A1001」输成了「A10O1」。这个错误导致后续的采购、库存、财务全部串行。排查了整整两天。

2.2.2 完整性

数据缺失的程度。不是所有字段都必须填，但关键字段不能为空。比如订单表，如果「收货地址」为空，这单就发不出去。

2.2.3 一致性

同一份数据，在不同系统、不同时间点，要保持统一。这是数据治理的硬骨头。

举个例子。CRM系统里客户叫「张三」，到了订单系统变成了「张先生」，再到财务系统又成了「Zhang San」。三个系统，三个名字，你说这是同一个人吗？

2.2.4 及时性

数据从产生到可用，时间差是否在可接受范围内。对于实时风控，延迟5分钟可能就错过了拦截时机；对于月度报表，延迟半天问题不大。

2.2.5 唯一性

实体在数据集中只出现一次。重复记录是数据治理的顽疾。

我曾经处理过一个客户数据合并项目，光「张三」这个姓名，在数据库里就出现了17条记录，有的是手机号不同，有的是地址不同，有的是完全重复。最后花了三周才清洗干净。

2.2.6 有效性

数据是否符合预定义的格式、范围、业务规则。比如年龄字段，值不能是「-5」；邮箱字段，必须包含「@」符号。

六个维度不是孤立的。它们之间会相互影响。比如，为了追求及时性，可能牺牲准确性（实时采集的数据来不及校验）。做治理时，要权衡取舍。

2.3 数据质量问题的来源

问题从哪来？我把它归纳为四个层面。了解根源，才能对症下药。

来源层面	典型场景	影响维度
源系统	业务系统设计缺陷、字段长度不足、缺少校验逻辑	准确性、完整性、有效性
数据录入	人工录入错误、下拉菜单选错、复制粘贴遗漏	准确性、完整性
数据集成	ETL脚本bug、字段映射错误、时区转换遗漏	一致性、完整性
数据维护	缺乏更新机制、历史数据未归档、权限混乱导致误删	及时性、唯一性

还有一个容易被忽略的来源：数据老化。业务规则变了，但历史数据没跟着变。比如，公司把「省份」字段从文本改为编码，但三年前的数据还是文本。这种问题，在数据仓库里尤其常见。