数据清洗的三个基本步骤：从脏数据到可用资产

作为一名从业近十年的数据工程师，我清晰地记得刚入行时接手的那批电商订单数据。原始数据表里，用户ID有汉字、有乱码，金额字段混着“元”字和逗号，时间戳格式五花八门。那时我才真正理解，数据清洗不是“洗洗更健康”的修饰，而是数据挖掘的生死线。结合多年实战，我将数据清洗归纳为三个不可逾越的核心步骤。

第一步：缺失值与异常值处理，这是数据质量的“安检门”。我通常先执行describe()或profile报告，定位空值率超过5%的字段。对于数值型字段，如用户活跃天数，我倾向用中位数而非均值填充，以避免极端值干扰。但若空值率超过30%，我会直接舍弃该字段或重建特征，因为强行插补只会引入噪声。同时，利用IQR（四分位距）或Z-Score识别异常值，比如订单金额为负数或超出99百分位的离群点，必须逐条核查业务逻辑，而非简单删除。

第二步：格式统一与去重，这是数据标准化的“整形手术”。最头疼的是时间格式，比如“2023-01-15”与“01/15/2023”共存。我坚持用ISO 8601标准（如YYYY-MM-DD）强制转换，并编写正则表达式清洗文本字段中的空格、全角字符和特殊符号。去重时，我摒弃简单的drop_duplicates()，而是基于业务键（如用户ID+时间戳）做复合去重，并保留最近一条记录——比如用户同一天下多次单，仅保留最终支付的那笔，避免重复计算GMV。

第三步：数据一致性校验与逻辑验证，这是清洗的“终审法庭”。例如，订单金额必须等于商品单价乘以数量，误差超过0.01元即标记为脏数据。我常用断言（assert）或SQL的check约束批量检查交叉字段的依赖关系，比如“用户注册时间必须早于首次下单时间”。这一步能暴露底层数据源的系统性缺陷，我曾通过一致性校验发现CRM系统的用户ID生成规则有漏洞，直接推动了上游改造。

回顾这十年的数据清洗工作，我最大的感悟是：清洗不是一次性的体力活，而是贯穿数据生命周期的战略投资。只有将这三个步骤内化为工程规范，才能让数据从“脏乱差”蜕变为“可信可用”，为后续的建模与分析打下坚实基础。