1. 数据质量概论：定义、维度与业务影响
数据质量这事儿，说起来简单，做起来全是坑。
我做了十几年数据架构，见过太多项目在数据质量上栽跟头。有的公司花几千万建数据平台，结果因为质量太差，业务部门根本不敢用。说白了，数据质量不是锦上添花，而是地基。地基不稳，楼盖得再高也得塌。
1.1 数据质量到底是什么？
先给个定义。数据质量，就是数据满足使用要求的程度。
注意这个「使用要求」。同样的数据，在不同场景下，质量标准完全不同。举个例子：
- 用户注册时的手机号——必须11位，不能为空，格式要校验
- 用户画像里的手机号——允许为空，格式可以宽松些
你看，同一个字段，在不同环节，要求就不一样。所以数据质量没有标准，只有相对标准——够用就行。
1.2 五大质量维度
业内公认的数据质量维度，主要有五个。我一个个说。
1.2.1 准确性
数据要真实反映客观事实。说白了，就是数据对不对。
我在项目中遇到过最典型的例子：某电商平台的订单金额，因为汇率换算精度问题，差了0.01元。单看一笔没问题，但每天几十万笔订单，月底对账差了十几万。财务部门炸了锅。
1.2.2 完整性
数据不能缺胳膊少腿。该有的字段要有，该填的值不能空。
完整性分两个层面：
- 记录完整性——有没有丢数据？比如每天应该同步100万条，实际只到了80万
- 字段完整性——某个字段的空值率是不是太高？比如「邮箱」字段80%为空
你想想看，如果用户画像里「年龄」字段一半是空的，那基于年龄的精准营销还怎么做？
1.2.3 一致性
同一份数据，在不同系统、不同时间点，要保持一致。
这是个大坑。很多公司都有「数据孤岛」问题：CRM系统里客户叫「张三」，ERP系统里叫「张先生」，数据仓库里叫「Zhang San」。你说哪个是对的？
| 系统 | 客户名称 | 状态 |
|---|---|---|
| CRM | 张三 | 活跃 |
| ERP | 张先生 | 已停用 |
| 数据仓库 | Zhang San | 未知 |
这种不一致，根源在于缺乏统一的主数据管理。我建议，核心业务实体（客户、产品、组织）必须建立统一的编码和命名规范。
1.2.4 及时性
数据要在需要的时候到达。晚了就没用了。
举个例子：实时风控系统，要求交易数据延迟不超过1秒。如果延迟到5分钟，骗子早就把钱转走了。但如果是月度经营分析报表，延迟半天也能接受。
1.2.5 唯一性
同一实体在数据集中不能重复出现。
这个维度经常被忽略。我见过最夸张的案例：某公司的客户表里，同一个客户因为录入时姓名多了个空格，出现了3条记录。结果营销活动给同一个人发了3份礼品，成本翻了三倍。
唯一性的核心是去重。常用的手段包括：
- 建立唯一索引（数据库层面）
- 使用业务主键（如身份证号、手机号）
- 模糊匹配去重（如姓名+地址相似度计算）
1.3 数据质量的重要性
说了这么多维度，到底数据质量有多重要？我直接说结论：数据质量决定数据价值的上限。
你想想看：
- BI报表不准，管理层做决策就是拍脑袋
- 推荐算法喂了脏数据，用户看到的全是垃圾推荐
- 风控模型用了错误标签，该拦的没拦，不该拦的拦了
我参与过一个金融项目，因为历史数据质量太差，模型上线后坏账率反而比人工审核高了30%。最后复盘发现，训练数据里20%的标签是错的。你说这模型能好吗？
1.4 业务影响：数据质量差到底有多痛？
数据质量差的代价，往往是隐性的，但一旦爆发就是大问题。
| 影响类型 | 具体表现 | 严重程度 |
|---|---|---|
| 决策失误 | 报表数据不准，管理层做出错误判断 | 高 |
| 成本浪费 | 重复营销、错误发货、人工返工 | 中高 |
| 合规风险 | 监管报送数据不达标，面临罚款 | 极高 |
| 客户流失 | 推荐不准、服务体验差 | 高 |
| 技术债务 | 数据清洗占用大量开发资源 | 中 |
嗯，这里要注意：很多公司只看到「建数据平台」的成本，却忽略了「数据质量差」的隐性成本。后者往往比前者高得多。
1.5 本章知识体系总览
最后，我用一张图把本章的核心内容串起来。这张图也是后续课程的整体框架。
这张图展示了数据质量的完整闭环：从定义维度出发，评估业务影响，然后通过治理手段和评估方法持续改进。后续章节，我们会逐一深入每个环节。
记住一句话：数据质量不是一次性工程，而是持续运营的过程。别指望建个平台、写个脚本就能一劳永逸。真正的数据质量保障，需要体系化的方法和持之以恒的执行。