客户数据长得不像示例数据

一句话总结

数据清洗中真正的决定不是使用什么工具，而是谁来确定丢弃内容的标准。

为什么需要了解这一点

教程中的 CSV 列数固定、没有空白，数值列中也只包含数字。客户提供的 CSV 并非如此。

实际会遇到的情况包括：少一个字段的行；客户名称为空的行；金额列中包含 N/A 或 - 的行；负数金额；名称前后带空格；同一家公司同时以 MOONSHOP 和 moonshop 两种形式出现；同一个订单号出现两次，其中一条仅日期格式不同；以及 2026-08-20、2026/08/20、08/20/2026 混在同一个文件中。

新手此时常犯的错误，是立刻开始编写清洗脚本。这样必然会发生两件事。第一，脚本悄悄删除数据。第二，客户之后会问：“为什么我们的销售额只有这么多？”

工作原理

顺序是计数 → 分类 → 达成共识 → 清洗。

首先计数。 总共多少行，其中多少行违反规则。没有这个数字，就无法判断清洗结果是否正确。226 行中有 5 行损坏，与 226 行中有 180 行损坏，是完全不同的情况；如果是后者，应重新进行数据提取本身，而不是做清洗。

接着分类。 按损坏原因划分类别：结构问题（字段数量）、缺失值（空值）、类型问题（数字位置出现文字）、范围问题（负数或不现实的值）、重复。分类之所以重要，是因为不同类别的处理方针不同。字段数量不符的行通常应丢弃，但客户名称为空的行既可以丢弃，也可以用 미상 填充。这个决定应由业务负责人而不是工程师作出。

然后是达成共识。 这正是 FDE 的工作。要提出这样的问题：“金额为负的 4 行看起来像退款，本次统计中是排除，还是单独计数？”如果不提出问题，日后数字不一致时就没有解释依据。

最后才是清洗。 而且清洗脚本必须输出丢弃行的数量。悄悄删除数据的脚本就是一颗定时炸弹。

实际工作中的表现

下面介绍重复数据消除中最常见的一种事故。

有一段代码按照“邮箱相同即为重复，只保留一条”的规则分组整理。大多数情况下运行良好，但如果存在邮箱为空的行，这些行会全部归入同一个组，最终只保留一个客户，其余不同客户都被删除。

名称规范化中也有同样的陷阱。去除首尾空格并转换为小写是好习惯，但这样做后，原本不同的 kimcoffee 与 kimcoffee31 也开始显得相似。规范化是为了比较，不是合并的依据。

因此有一条实务规则：如果重复判定 key 可能包含缺失值，就应把缺失值行完全排除在重复判定之外，另行计数。

如何证明清洗结果

用什么来证明清洗已经完成，是实际工作的一半。只说“运行完了”，任何人都无法放心使用这些数字。因此，清洗脚本除了结果数据，还必须输出一份记录发生了什么的报告。

至少应包含以下五行。

• 输入行数、输出行数及两者之差
• 按原因划分的丢弃行数量
• 修正过值的行数（去除空格、统一大小写、统一日期格式）
• 作为重复项合并的数量，以及当时保留了什么
• 清洗前后，业务实际使用的数字（例如总计）的值

最后一行尤其重要。如果行数减少 2%，销售额总计却减少 30%，那不是清洗，而是事故。 这意味着几笔大额交易被过滤掉了，而此类行往往更可能采用特殊格式。只看行数就会漏掉这一点。

让操作可回退同样重要。不要覆盖原始数据，也不要删除被丢弃的行，而应把它们保存到单独文件。这样以后有人问“这笔订单为什么没有计入统计”时，几秒钟内就能回答。最好在丢弃行文件中一并记录原始行号。客户必须能够在自己的文件中直接打开该行，沟通才会更快。

最后，规则不能只在代码中，而必须用相同的语言同时写在文档和代码中。如果清洗规则只存在于代码里，几个月后就无人知晓，新负责人会按另一套规则重新实现。从此，同一份原始数据会产生两个不同数字，而且失去判断哪个正确的依据。

文档中还应为每条规则记录制定人和日期。将来需要询问规则能否修改时，对应联系人应写在这一行，避免新人独自作出判断后直接跳过沟通。

下个练习将做什么

按照规则过滤一份包含 25 行的订单 CSV 中的损坏行，统计丢弃行数量，并生成清洗结果的总计与按日期汇总。规模虽小，问题类型与现场完全相同。