1、数据质量概述：从“脏数据”到“可信数据”的第一课
说实话，我做了十几年数据架构，最怕听到的一句话就是：“数据不是都有吗？直接跑一下不就行了？”
每次听到这种话，我心里就咯噔一下。数据确实有，但质量怎么样，没人知道。今天咱们就来聊聊这个最基础、也最容易被忽视的问题——数据质量。
1.1 什么是数据质量？
数据质量，说白了就是数据“靠谱不靠谱”。
我习惯用一个简单的定义：数据质量是数据满足使用要求的程度。你拿数据去做报表、做模型、做决策，数据能不能撑住，这就是质量。
业内一般从六个维度来衡量数据质量：
| 维度 | 含义 | 我见过的问题 |
|---|---|---|
| 完整性 | 数据有没有缺失 | 用户手机号字段 30% 为空 |
| 准确性 | 数据是否真实反映客观事实 | 订单金额多了一个零 |
| 一致性 | 不同系统间的数据是否对得上 | CRM 和 ERP 的客户名称不一样 |
| 及时性 | 数据更新是否满足时效要求 | 昨天的报表今天下午才出 |
| 唯一性 | 数据有没有重复 | 同一个客户建了三个账号 |
| 有效性 | 数据是否符合业务规则 | 年龄字段填了 200 岁 |
我的经验：别一上来就六个维度全抓。先挑两个最痛的维度下手，比如完整性和准确性。等团队跑起来了，再慢慢加。
1.2 数据质量为什么重要？
这个问题我问过很多刚入行的同事。有人说是为了“数据好看”，有人说是“领导要求的”。
其实没那么复杂。你想想看，数据质量差，最直接的后果是什么？决策出错。
我举个例子。之前有个电商客户，运营团队根据“用户复购率”做促销策略。结果数据质量有问题——重复下单被算成了多次复购。团队按这个数据投了几百万的营销费用，实际效果惨不忍睹。后来一查，问题出在数据去重逻辑上。
数据质量的重要性，我总结成三点：
- 决策可信度——烂数据出烂决策，这是铁律
- 系统稳定性——脏数据会导致下游系统报错、跑飞
- 合规与风控——金融、医疗行业，数据质量不达标就是违规
注意：数据质量不是“锦上添花”，而是“雪中送炭”。没有质量的数据，还不如没有数据——至少你不会被误导。
1.3 数据质量差的代价
代价这东西，不落到自己头上，永远觉得无所谓。我曾经帮一家公司做过数据治理的复盘，他们一年的数据质量问题，直接经济损失超过 500 万。
具体来说，代价集中在几个方面：
- 直接经济损失——发错优惠券、算错佣金、重复付款
- 人力浪费——数据工程师 30% 的时间在“洗数据”
- 信任崩塌——业务部门不再相信数据团队，回归“拍脑袋”
- 合规罚款——数据不准确导致监管处罚
我记得有个项目，业务方每次开会都带着自己的 Excel 小本本，根本不看数据平台。为什么？因为被坑怕了。数据团队花了半年重建信任，才把业务拉回来。这个代价，比修几个 bug 大多了。
1.4 数据质量监控的目标与范围
好，前面说了这么多“为什么”，现在聊聊“做什么”。
数据质量监控的目标，我一句话概括：在数据出问题之前发现它，或者在出问题之后第一时间定位它。
具体目标包括：
- 自动化检测数据异常，减少人工巡检
- 量化数据质量水平，用指标说话
- 建立问题追溯机制，快速定位根因
- 形成质量改进闭环，持续提升
至于范围，我建议从三个层面来划定：
| 层面 | 监控内容 | 典型场景 |
|---|---|---|
| 数据源层 | 源系统数据是否正常产出 | 业务库延迟、接口超时 |
| 数据加工层 | ETL 过程是否准确 | 字段丢失、类型转换错误 |
| 数据应用层 | 最终数据是否可用 | 报表数据对不上、指标异常波动 |
我的建议：刚开始做监控，别贪多。先覆盖数据应用层，因为业务方看的就是这层。等监控跑稳了，再往上游推。
下面这张图，是我自己梳理的数据质量监控的核心逻辑，你可以参考一下：
嗯，这张图其实就说明了一个道理：数据质量监控不是一次性的事，而是一个持续运转的闭环。从数据源到加工再到应用，每一层都要有监控，发现问题要能回溯、能修复、能优化。
好了，第一章的内容就到这儿。数据质量这个概念，说大不大，说小不小。但如果你能把这一章的内容吃透，后面的课程你会越听越顺。