一、数据清洗概述：数据质量问题的来源、数据清洗的定义与目标、数据清洗在数据治理中的位置
大家好，我是老蓝。今天咱们聊聊数据清洗这个事儿。
说实话，我干了十几年数据工程，最怕的不是数据量大，而是数据脏。你想想看，辛辛苦苦搭好了数仓，写好了ETL，结果跑出来的报表没人敢信——这种尴尬，我经历过不止一次。
数据清洗，说白了就是给数据“洗澡”。但怎么洗、洗到什么程度、洗完了怎么保证不再脏，这里面的门道可不少。
1.1 数据质量问题的来源
数据为什么会脏？我总结下来，无非三个源头：
- 源头脏：业务系统录入不规范。比如用户填手机号，有人写“138-0000-1111”，有人写“13800001111”，还有人写“手机号：13800001111”。
- 传输脏：数据在搬运过程中丢失、乱码。我记得有一次，一个日志文件因为编码问题，中文全变成了乱码，排查了整整两天。
- 加工脏：ETL脚本写错了，或者业务逻辑变更后没同步更新清洗规则。嗯，这个坑我踩过不止一次。
具体来说，常见的数据质量问题包括：
| 问题类型 | 典型表现 | 我遇到过的案例 |
|---|---|---|
| 缺失值 | 字段为空、NULL、占位符（如“-”、“未知”） | 用户年龄字段大量为0，其实是前端没传 |
| 重复数据 | 完全重复、部分关键字段重复 | 同一个订单被录入了3次，导致GMV虚高 |
| 格式不一致 | 日期格式、电话号码、身份证号格式混乱 | 日期有“2024-01-01”、“2024/01/01”、“2024年1月1日”三种 |
| 逻辑错误 | 年龄200岁、下单时间早于注册时间 | 某用户“注册时间”比“出生日期”还早，明显是数据录入错误 |
| 异常值 | 超出正常范围、统计分布异常 | 某商品价格标了999999，其实是测试数据没清理 |
⚠️ 避坑指南
我曾经接手过一个项目，业务方说“数据没问题，直接跑就行”。结果一检查，30%的订单ID是重复的。所以我的习惯是：不管谁说的，先做一轮数据质量探查再说。
我曾经接手过一个项目，业务方说“数据没问题，直接跑就行”。结果一检查，30%的订单ID是重复的。所以我的习惯是：不管谁说的，先做一轮数据质量探查再说。
1.2 数据清洗的定义与目标
数据清洗，官方定义是“检测和纠正数据集中错误、不一致、不完整等问题的过程”。但我觉得，更接地气的说法是：让数据变得可信、可用、可分析。
我个人习惯把数据清洗的目标拆成三层：
- 第一层：去脏——把明显错误的数据处理掉。比如空值填充、重复删除、格式统一。
- 第二层：对齐——让不同来源的数据能对上。比如A系统叫“客户ID”，B系统叫“用户编号”，你得知道它们是一个东西。
- 第三层：增强——在清洗过程中补充信息。比如根据身份证号推算出生日期、性别。
说白了，清洗不是目的，让数据能干活才是。
💡 我的经验
数据清洗不是一次性工作。我见过太多团队，上线前猛洗一通，上线后就不管了。结果三个月后，数据又脏回去了。清洗规则需要持续维护，就像你家的扫地机器人，得定期清理尘盒。
数据清洗不是一次性工作。我见过太多团队，上线前猛洗一通，上线后就不管了。结果三个月后，数据又脏回去了。清洗规则需要持续维护，就像你家的扫地机器人，得定期清理尘盒。
1.3 数据清洗在数据治理中的位置
数据治理是个大概念，包括数据标准、数据质量、数据安全、数据生命周期管理等等。数据清洗，其实是数据质量管理这个子领域里的核心执行环节。
我画了一张图，帮你理解数据清洗在整个数据治理体系中的位置：
从这张图你能看出来，数据清洗不是孤立存在的。它前面有数据质量评估（告诉你哪些数据有问题），后面有数据质量监控（确保清洗后的数据不再变脏）。
我个人习惯把数据清洗比作“数据治理的最后一公里”。前面定标准、建规范、做架构，最终都要落到数据清洗这个执行环节上。如果清洗做不好，前面的一切都是纸上谈兵。
💡 小贴士
很多团队把数据清洗当成一个“一次性项目”来做，这是不对的。数据清洗应该嵌入到数据流水线中，成为ETL的一部分。我建议你在设计数据管道时，就把清洗规则作为可配置的模块，而不是写死在脚本里。
很多团队把数据清洗当成一个“一次性项目”来做，这是不对的。数据清洗应该嵌入到数据流水线中，成为ETL的一部分。我建议你在设计数据管道时，就把清洗规则作为可配置的模块，而不是写死在脚本里。
好了，这一章我们聊了数据质量问题的来源、数据清洗的定义和目标，以及它在数据治理体系中的位置。下一章，我会带你看看具体怎么动手做数据清洗——从探查数据质量开始。