1. 数据质量概述：什么是数据质量、数据质量为什么重要、数据质量问题的常见场景
大家好，我是老张。做数据这行十几年了，踩过的坑比吃过的盐还多。今天咱们聊聊数据质量——这个听起来基础、但真正做好的人不多的领域。
说实话，我见过太多团队把精力花在炫酷的数据架构上，结果数据一跑出来全是错的。你想想看，数据不准，再牛的算法也是白搭。
1.1 什么是数据质量
数据质量，说白了就是数据满足使用要求的程度。不是数据本身有多完美，而是它能不能帮你做决策。
我习惯从六个维度来定义数据质量：
| 维度 | 定义 | 举个栗子 |
|---|---|---|
| 完整性 | 数据是否缺失 | 用户表里手机号字段有30%是空的 |
| 准确性 | 数据是否真实反映客观事实 | 订单金额多了一个零 |
| 一致性 | 不同系统间的数据是否对得上 | CRM和ERP里同一个客户的名称不一样 |
| 及时性 | 数据是否在需要的时候可用 | 日报数据第二天下午才跑出来 |
| 唯一性 | 数据是否有重复 | 同一个用户被录入了三次 |
| 有效性 | 数据是否符合业务规则 | 年龄字段出现了200岁 |
核心观点：数据质量不是的，而是相对的。同一份数据，对财务部门可能是灾难，对市场部门可能勉强能用。关键看业务场景。
1.2 数据质量为什么重要
这个问题我问过很多刚入行的同事。有人说是为了报表好看，有人说是为了应付审计。其实都不对。
数据质量的重要性，我总结为三个层面：
- 决策层面：数据不准，决策就是拍脑袋。我在一家电商公司见过，因为库存数据不准，双十一当天超卖了3000单，赔了上百万。
- 成本层面：数据问题越早发现，修复成本越低。数据源出问题，可能只要改个接口；到了报表层才发现，得回溯整个链路。
- 信任层面：这是最要命的。业务部门一旦不相信数据，就会回到凭经验做决策的老路。数据团队的价值就没了。
血的教训：我曾经负责过一个金融项目，因为风控模型用的数据质量不过关，导致坏账率飙升了40%。老板拍桌子问：你们的数据到底能不能信？从那以后，我把数据质量监控提到了最高优先级。
1.3 数据质量问题的常见场景
这些年我见过的数据质量问题，五花八门。但归纳起来，无非就这几类：
场景一：数据采集阶段
- 埋点漏报：用户点击了，但前端没上报
- 字段截断：手机号只存了前7位
- 编码混乱：同一个省份，有的用"北京"，有的用"BJ"
场景二：数据传输阶段
- 网络抖动导致数据丢失
- 消息队列积压，数据延迟
- 序列化/反序列化出错，字段错位
场景三：数据存储阶段
- 主键冲突，数据被覆盖
- 分区策略不当，数据写错目录
- 存储格式不兼容，精度丢失
场景四：数据处理阶段
- ETL脚本bug，数据计算错误
- 维度表更新不及时，关联不上
- 数据倾斜导致部分数据没处理完
我的经验：80%的数据质量问题都出在数据采集和传输阶段。很多团队只盯着ETL代码，却忽略了源头。记住一句话：垃圾进，垃圾出。源头把控比事后清洗重要得多。
下面这张图，是我这些年总结的数据质量问题全景图。它把问题来源、影响范围和应对策略串在了一起：
你看，数据质量问题不是孤立的技术问题，它贯穿数据全生命周期。从采集到消费，每个环节都可能出幺蛾子。
我见过最典型的案例：某公司做用户画像，数据源来自三个部门。结果同一个用户，在A部门叫"张三"，在B部门叫"zhangsan"，在C部门叫"张先生"。你说这画像怎么做？
所以，数据质量监控不是可有可无的锦上添花，而是数据体系的基石。没有这块基石，上面盖的楼再漂亮，也是危楼。
一句话总结：数据质量是数据工作的生命线。你可以在架构上偷懒，可以在性能上妥协，但数据质量，必须死磕到底。