本文通过navicat、SQL对数据进行清洗，重在梳理与建立个人的数据清洗思路。
个人工作中接触的数据清洗包括两类：单表数据清洗、多表关联的数据清洗
记得高项里面是这么定义数据清洗的:将重复、多余的数据筛除，将缺失的数据补充完整，将错误的数据纠正者删除，最后整理成为我们可以进一步加工、使用的数据。
所以数据清洗的思路是处理 1.重复 2.多余 3.缺失 4.错误的数据
预处理阶段
预处理阶段主要做两件事情：
一是将数据导入处理工具。通常来说，建议使用数据库，单机跑数搭建MySQL环境即可
二是看数据。这里包含两个部分：1）是看元数据，包括字段解释、数据来源、代码表等等一切描述数据的信息；
2）是抽取一部分数据，使用人工查看方式，对数据本身有一个直观的了解，并且初步发现一些问题，为之后的处理做准备。
第一步：缺失值清洗
缺失值是最常见的数据问题，处理缺失值也有很多方法，我建议按照以下四个步骤进行：
1、确定缺失值范围：对每个字段都计算其缺失值比例，然后按照缺失比例和字段重要性，分别制定策略，可用下图表示：
2、去除不需要的字段：这一步很简单，直接删掉即可……记得备份！！！
3、填充缺失内容：某些缺失值可以进行填充，方法有以下三种：
1）以业务知识或经验推测填充缺失值 --比如药品的单次剂量的缺失可以用总剂量比上次数
2) 通过指标的计算结果（均值、中位数、众数等）填充缺失值 --年龄字段缺失，但是有身份证号
4、重新取数：如果某些指标非常重要又缺失率高，那就需要和取数人员或业务人员了解，是否有其他渠道可以取到相关数据。
第二步：格式内容清洗
如果数据是由系统日志而来，那么通常在格式和内容方面，会与元数据的描述一致。而如果数据是由人工收集、用户填写、系统导入而来，则有很大可能性在格式和内容上存在一些问题，格式内容问题有以下几类：
1、时间、日期、数值、全半角等显示格式不一致
这种问题通常与输入端有关，在整合多来源数据时也有可能遇到，将其处理成一致的某种格式即可。
2、内容中有不该存在的字符
某些内容可能只包括一部分字符，比如身份证号是数字+字母，中国人姓名是汉字（赵C这种情况还是少数）。最典型的就是头、尾、中间的空格，也可能出现姓名中存在数字符号、身份证号中出现汉字等问题。这种情况下，需要以半自动校验半人工方式来找出可能存在的问题，并去除不需要的字符。
3、内容与该字段应有内容不符
姓名写了性别，身份证号写了手机号等等，均属这种问题。 但该问题特殊性在于：并不能简单的以删除来处理，因为成因有可能是人工填写错误，也有可能是前端没有校验，还有可能是导入数据时部分或全部存在列没有对齐的问题，因此要详细识别问题类型。
格式内容问题是比较细节的问题，但很多分析失误都是栽在这个坑上，比如跨表关联或VLOOKUP失败（多个空格导致工具认为“陈丹奕”和“陈 丹奕”不是一个人）、统计值不全（数字里掺个字母当然求和时结果有问题）、模型输出失败或效果不好（数据对错列了，把日期和年龄混了，so……）。因此，请各位务必注意这部分清洗工作，尤其是在处理的数据是人工收集而来，或者你确定产品前端校验设计不太好的时候……
第三步：逻辑错误清洗
这部分的工作是去掉一些使用简单逻辑推理就可以直接发现问题的数据，防止分析结果走偏。主要包含以下几个步骤：
1、去重
有的分析师喜欢把去重放在第一步，但我强烈建议把去重放在格式内容清洗之后，原因已经说过了（多个空格导致工具认为“陈丹奕”和“陈 丹奕”不是一个人，去重失败）。而且，并不是所有的重复都能这么简单的去掉……
我曾经做过电话销售相关的数据分析，发现销售们为了抢单简直无所不用其极……举例，一家公司叫做“ABC管家有限公司“，在销售A手里，然后销售B为了抢这个客户，在系统里录入一个”ABC官家有限公司“。你看，不仔细看你都看不出两者的区别，而且就算看出来了，你能保证没有”ABC官家有限公司“这种东西的存在么……这种时候，要么去抱RD大腿要求人家给你写模糊匹配算法，要么肉眼看吧。
2、去除不合理值
一句话就能说清楚：有人填表时候瞎填，年龄200岁，年收入100000万（估计是没看见”万“字），这种的就要么删掉，要么按缺失值处理。这种值如何发现？
3、修正矛盾内容
有些字段是可以互相验证的，举例：身份证号是1101031980XXXXXXXX，然后年龄填18岁，我们虽然理解人家永远18岁的想法，但得知真实年龄可以给用户提供更好的服务啊（又瞎扯……）。在这种时候，需要根据字段的数据来源，来判定哪个字段提供的信息更为可靠，去除或重构不可靠的字段。
第四步：非需求数据清洗
这一步说起来非常简单：把不要的字段删了。
但实际操作起来，有很多问题，例如：
把看上去不需要但实际上对业务很重要的字段删了；
某个字段觉得有用，但又没想好怎么用，不知道是否该删；
一时看走眼，删错字段了。
前两种情况我给的建议是：如果数据量没有大到不删字段就没办法处理的程度，那么能不删的字段尽量不删。第三种情况，请勤备份数据……
第五步：关联性验证
如果你的数据有多个来源，那么有必要进行关联性验证。例如，你有汽车的线下购买信息，也有电话客服问卷信息，两者通过姓名和手机号关联，那么要看一下，同一个人线下登记的车辆信息和线上问卷问出来的车辆信息是不是同一辆，如果不是（别笑，业务流程设计不好是有可能出现这种问题的！），那么需要调整或去除数据。
严格意义上来说，这已经脱离数据清洗的范畴了，而且关联数据变动在数据库模型中就应该涉及。但我还是希望提醒大家，多个来源的数据整合是非常复杂的工作，一定要注意数据之间的关联性，尽量在分析过程中不要出现数据之间互相矛盾，而你却毫无察觉的情况。
以上，就是我对数据清洗过程的一个简单梳理。由于能力所限，难免挂一漏万，请各位不吝赐教，感谢。
————————————————
原文链接：https://blog.csdn.net/wyqwilliam/article/details/84801095
异同点：
同：1.都是对表数据进行清洗，最终的清洗维度还是某个表的某字段，即最小单元是相同的
2.用到的逻辑判断与函数或者其他工具是相同的
不同点：待清洗数据的内容不仅仅是空值后者格式错误这种简单的物理维度的问题，同时还包含因为表数据关联，业务场景等导致的“化学”维度的问题
一、异常值问题
1.空值或者null问题
SELECT *
FROM userbehavior
WHERE user_id is null OR user_id ='';
2.去重
1）先查找是否有重复数据：用count函数统计数据数量
有以下两种情况查找：
a. 某一列重复：distinct --暂时想不起来这种场景
b. 多列可能重复时用 group by 分组，再用count函数统计重复行
比如住院病人信息中，病人根据身份证号码入院，多次入院使用同一个住院号码（ZYHM）,不同的住院号（ZYH）
按照上面的逻辑，需要过滤有问题的数据的sql为
select zyhm，idcardnum ，count(*) from patient_info group by zyhm，idcardnum having count(*) >1
2.数据格式问题
1).尤其要注意时间格式，业务数据有可能是通过系统模板导入的，时间格式的数据到入后会出现乱码有可能是一串数字，然后有可能年月日的格式导入后变成了年月日 时分秒，
2).涉及到Unix时间戳会用到FROM_UNIXTIME（）以及UNIX_TIMESTAMP（）函数
3.数据范围问题
1）.先统计是否有超出分析范围的数据，过滤的维度一般包括时间范围、字段的取值范围等
4.枚举值或者字典的范围问题
比如:职业代码中90代表农民，各个职业有固定的字典
5.建立映射关系
二、多表的数据治理
=============================================
下面是根据美团的技术文章总结的几点具体治理方式：
1. 规范治理
规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况，统一按照最详细、可落地的方法进行规范建设。
(1) 词根
词根是维度和指标管理的基础，划分为普通词根与专有词根，提高词根的易用性和关联性。
- 普通词根：描述事物的最小单元体，如：交易-trade。
- 专有词根：具备约定成俗或行业专属的描述体，如：美元-USD。
(2) 表命名规范
通用规范
- 表名、字段名采用一个下划线分隔词根（示例：clienttype->client_type）。
- 每部分使用小写英文单词，属于通用字段的必须满足通用字段信息的定义。
- 表名、字段名需以字母为开头。
- 表名、字段名最长不超过64个英文字符。
- 优先使用词根中已有关键字（数仓标准配置中的词根管理），定期Review新增命名的不合理性。
- 在表名自定义部分禁止采用非标准的缩写。
表命名规则
- 表名称 = 类型 + 业务主题 + 子主题 + 表含义 + 存储格式 + 更新频率 +结尾，如下图所示：
统一的表命名规范
(3) 指标命名规范
结合指标的特性以及词根管理规范，将指标进行结构化处理。
1.基础指标词根，即所有指标必须包含以下基础词根：
2.业务修饰词，用于描述业务场景的词汇，例如trade-交易。
3.日期修饰词，用于修饰业务发生的时间区间。
4.聚合修饰词，对结果进行聚集操作
5.基础指标，单一的业务修饰词+基础指标词根构建基础指标 ，例如：交易金额-trade_amt。
6.派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：安装门店数量-install_poi_cnt。
7.普通指标命名规范，与字段命名规范一致，由词汇转换即可以
数据治理的注意店摘抄自：https://zhuanlan.zhihu.com/p/423275737