​一文看懂数据清洗：缺失值、异常值和重复值的处理

作者：宋天龙

数据缺失分为两种：一种是行记录的缺失，这种情况又称数据记录丢失；另一种是数据列值的缺失，即由于各种原因导致的数据记录中某些列的值空缺。

不同的数据存储和环境中对于缺失值的表示结果也不同，例如，数据库中是Null，Python返回对象是None，Pandas或Numpy中是NaN。

在极少数情况下，部分缺失值也会使用空字符串来代替，但空字符串绝对不同于缺失值。从对象的实体来看，空字符串是有实体的，实体为字符串类型；而缺失值其实是没有实体的，即没有数据类型。

丢失的数据记录通常无法找回，这里重点讨论数据列类型缺失值的处理思路。通常有4种思路。

1. 丢弃

这种方法简单明了，直接删除带有缺失值的行记录（整行删除）或者列字段（整列删除），减少缺失数据记录对总体数据的影响。但丢弃意味着会消减数据特征，以下任何一种场景都不宜采用该方法。

• 数据集总体中存在大量的数据记录不完整情况且比例较大，例如超过10%，删除这些带有缺失值的记录意味着会损失过多有用信息。
• 带有缺失值的数据记录大量存在着明显的数据分布规律或特征，例如带有缺失值的数据记录的目标标签（即分类中的Label变量）主要集中于某一类或几类，如果删除这些数据记录将使对应分类的数据样本丢失大量特征信息，导致模型过拟合或分类不准确。

2. 补全

相对丢弃而言，补全是更加常用的缺失值处理方式。通过一定的方法将缺失的数据补上，从而形成完整的数据记录，对于后续的数据处理、分析和建模至关重要。常用的补全方法如下。

• 统计法：对于数值型的数据，使用均值、加权均值、中位数等方法补足；对于分类型数据，使用类别众数最多的值补足。
• 模型法：更多时候我们会基于已有的其他字段，将缺失字段作为目标变量进行预测，从而得到最为可能的补全值。如果带有缺失值的列是数值变量，采用回归模型补全；如果是分类变量，则采用分类模型补全。
• 专家补全：对于少量且具有重要意义的数据记录，专家补足也是非常重要的一种途径。
• 其他方法：例如随机法、特殊值法、多重填补等。

在某些情况下，我们可能无法得知缺失值的分布规律，并且无法对于缺失值采用上述任何一种补全方法做处理；或者我们认为数据缺失也是一种规律，不应该轻易对缺失值随意处理，那么还有一种缺失值处理思路—真值转换。

该思路的根本观点是，我们承认缺失值的存在，并且把数据缺失也作为数据分布规律的一部分，将变量的实际值和缺失值都作为输入维度参与后续数据处理和模型计算中。但是变量的实际值可以作为变量值参与模型计算，而缺失值通常无法参与运算，因此需要对缺失值进行真值转换。

以用户性别字段为例，很多数据库集都无法对会员的性别进行补足，但又舍不得将其丢弃掉，那么我们将选择将其中的值，包括男、女、未知从一个变量的多个值分布状态转换为多个变量的真值分布状态。

• 转换前：性别（值域：男、女、未知）。
• 转换后：性别_男（值域1或0）、性别_女（值域1或0）、性别_未知（值域1或0）。

然后将这3列新的字段作为输入维度替换原来的1个字段参与后续模型计算。

4. 不处理

在数据预处理阶段，对于具有缺失值的数据记录不做任何处理，也是一种思路。这种思路主要看后期的数据分析和建模应用，很多模型对于缺失值有容忍度或灵活的处理方法，因此在预处理阶段可以不做处理。

常见的能够自动处理缺失值的模型包括：KNN、决策树和随机森林、神经网络和朴素贝叶斯、DBSCAN（基于密度的带有噪声的空间聚类）等。这些模型对于缺失值的处理思路是：

• 忽略，缺失值不参与距离计算，例如KNN。
• 将缺失值作为分布的一种状态，并参与到建模过程，例如各种决策树及其变体。
• 不基于距离做计算，因此基于值的距离做计算本身的影响就消除了，例如DBSCAN。

在数据建模前的数据归约阶段，有一种归约的思路是降维，降维中有一种直接选择特征的方法。假如我们通过一定方法确定带有缺失值（无论缺少字段的值缺失数量有多少）的字段对于模型的影响非常小，那么我们根本就不需要对缺失值进行处理。

因此，后期建模时的字段或特征的重要性判断也是决定是否处理字段缺失值的重要参考因素之一。

对于缺失值的处理思路是先通过一定方法找到缺失值，接着分析缺失值在整体样本中的分布占比，以及缺失值是否具有显著的无规律分布特征，然后考虑后续要使用的模型中是否能满足缺失值的自动处理，最后决定采用哪种缺失值处理方法。

在选择处理方法时，注意投入的时间、精力和产出价值，毕竟，处理缺失值只是整个数据工作的冰山一角而已。

在数据采集时，可在采集端针对各个字段设置一个默认值。以MySQL为例，在设计数据库表时，可通过default指定每个字段的默认值，该值必须是常数。

在这种情况下，假如原本数据采集时没有采集到数据，字段的值应该为Null，虽然由于在建立库表时设置了默认值会导致“缺失值”看起来非常正常，但本质上还是缺失的。对于这类数据需要尤其注意。

异常数据是数据分布的常态，处于特定分布区域或范围之外的数据通常会被定义为异常或“噪音”。产生数据“噪音”的原因很多，例如业务运营操作、数据采集问题、数据同步问题等。

对异常数据进行处理前，需要先辨别出到底哪些是真正的数据异常。从数据异常的状态看分为两种：

• 一种是“伪异常”，这些异常是由于业务特定运营动作产生的，其实是正常反映业务状态，而不是数据本身的异常规律。
• 一种是“真异常”，这些异常并不是由于特定的业务动作引起的，而是客观地反映了数据本身分布异常的分布个案。

大多数数据挖掘或数据工作中，异常值都会在数据的预处理过程中被认为是噪音而剔除，以避免其对总体数据评估和分析挖掘的影响。但在以下几种情况下，我们无须对异常值做抛弃处理。

1. 异常值正常反映了业务运营结果

该场景是由业务部门的特定动作导致的数据分布异常，如果抛弃异常值将导致无法正确反馈业务结果。

例如：公司的A商品正常情况下日销量为1000台左右。由于昨日举行优惠促销活动导致总销量达到10000台，由于后端库存备货不足导致今日销量又下降到100台。在这种情况下，10000台和100台都正确地反映了业务运营的结果，而非数据异常案例。

2. 异常检测模型

异常检测模型是针对整体样本中的异常数据进行分析和挖掘，以便找到其中的异常个案和规律，这种数据应用围绕异常值展开，因此异常值不能做抛弃处理。

异常检测模型常用于客户异常识别、信用卡欺诈、贷款审批识别、药物变异识别、恶劣气象预测、网络入侵检测、流量作弊检测等。在这种情况下，异常数据本身是目标数据，如果被处理掉将损失关键信息。

3. 包容异常值的数据建模

如果数据算法和模型对异常值不敏感，那么即使不处理异常值也不会对模型本身造成负面影响。例如在决策树中，异常值本身就可以作为一种分裂节点。

提示：除了抛弃和保留，还有一种思路可对异常值进行处理，例如使用其他统计量、预测量进行替换。但这种方法不推荐使用，原因是这会将其中的关键分布特征消除，从而改变原始数据集的分布规律。

数据集中的重复值包括以下两种情况：

• 数据值完全相同的多条数据记录。这是最常见的数据重复情况。
• 数据主体相同但匹配到的唯一属性值不同。这种情况多见于数据仓库中的变化维度表，同一个事实表的主体会匹配同一个属性的多个值。

去重是重复值处理的主要方法，主要目的是保留能显示特征的唯一数据记录。但当遇到以下几种情况时，请慎重（不建议）执行数据去重。

1. 重复的记录用于分析演变规律

以变化维度表为例。例如在商品类别的维度表中，每个商品对应的同1个类别的值应该是唯一的，例如苹果iPhone7属于个人电子消费品，这样才能将所有商品分配到唯一类别属性值中。但当所有商品类别的值重构或升级时（大多数情况下随着公司的发展都会这么做），原有的商品可能被分配了类别中的不同值。如下表所示展示了这种变化。

此时，我们在数据中使用Full join做跨重构时间点的类别匹配时，会发现苹果iPhone7会同时匹配到个人电子消费品和手机数码2条记录。对于这种情况，需要根据具体业务需求处理。

• 如果跟业务沟通，两条数据需要做整合，那么需要确定一个整合字段用来涵盖2条记录。其实就是将2条数据再次映射到一个类别主体中。
• 如果跟业务沟通，需要同时保存两条数据，那么此时不能做任何处理。后续的具体处理根据建模需求而定。
• 相关知识点：变化维度表

变化维度表是数据仓库中的概念。维度表类似于匹配表，用来存储静态的维度、属性等数据，而这些数据一般都不会改变。但是变与不变是一个相对的概念，随着企业的不断发展，很多时候维度也会随着发生变化。因此在某个时间内的维度是不变的，而从整体来看维度也是变化的。

对于维度的变化，有3种方式进行处理：

• 直接覆盖原有值。这种情况下每个唯一ID就只对应一个属性值，这样做虽然简单粗暴也容易实现，但是无法保留历史信息。
• 添加新的维度行。此时同一个ID会得到两条匹配记录。
• 增加新的属性列。此时不会新增数据行记录，只是在原有的记录中新增一列用于标记不同时期的值。

具体到企业内使用哪种方式，通常由数据库管理员根据实际情况来决定。

注意：真正的变化维度表或维度表不会以中文做主键，通常都会使用数字或字符串类作为唯一关联ID，本节的示例仅做说明之用。

2. 重复的记录用于样本不均衡处理

在开展分类数据建模工作时，样本不均衡是影响分类模型效果的关键因素之一。解决分类方法的一种方法是对少数样本类别做简单过采样，通过随机过采样，采取简单复制样本的策略来增加少数类样本。

经过这种处理方式后，也会在数据记录中产生相同记录的多条数据。此时，我们不能对其中的重复值执行去重操作。

3. 重复的记录用于检测业务规则问题

对于以分析应用为主的数据集而言，存在重复记录不会直接影响实际运营，毕竟数据集主要是用来做分析的。

但对于事务型的数据而言，重复数据可能意味着重大运营规则问题，尤其当这些重复值出现在与企业经营中与金钱相关的业务场景时，例如：重复的订单、重复的充值、重复的预约项、重复的出库申请等。

这些重复的数据记录通常是由于数据采集、存储、验证和审核机制的不完善等问题导致的，会直接反映到前台生产和运营系统。以重复订单为例：

• 假如前台的提交订单功能不做唯一性约束，那么在一次订单中重复点击提交订单按钮，就会触发多次重复提交订单的申请记录，如果该操作审批通过后，会联动带动运营后端的商品分拣、出库、送货，如果用户接收重复商品则会导致重大损失；
• 如果用户退货则会增加反向订单，并影响物流、配送和仓储相关的各个运营环节，导致运营资源无端消耗、商品损耗增加、仓储物流成本增加等问题。

因此，这些问题必须在前期数据采集和存储时就通过一定机制解决和避免。如果确实产生了此类问题，那么数据工作者或运营工作者可以基于这些重复值来发现规则漏洞，并配合相关部门，最大限度地降低由此而带来的运营风险。

关于作者：宋天龙，大数据技术专家，触脉咨询合伙人兼副总裁，前Webtrekk中国区技术和咨询负责人（Webtrekk，德国的在线数据分析服务提供商）。擅长数据挖掘、建模、分析与运营，精通端到端数据价值场景设计、业务需求转换、数据结构梳理、数据建模与学习以及数据工程交付。

本文摘编自《Python数据分析与数据化运营》（第2版），经出版方授权发布。