本文通過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