文章大綱
我們目前進入了一個大數據的時代。以我目前經常處理的醫療保健數據爲例。
隨着時間的推移醫療保健數據的生成速度越來越快，預計到2020年將達到35 ZB（1ZB大約是10的9次方TB）。無論是出於患者護理、研究還是法律原因，能夠經濟高效、安全地管理這些數據對醫療保健提供者來說都越來越重要。
醫療保健提供商必須能夠攝取、存儲和保護大量數據，包括臨牀、基因組、設備、財務、供應鏈和保險理賠等。
本文嘗試從數據 挖掘、分析的一般步驟入手，基於理論化的描述結合具體例子詳細介紹挖掘分析建模之前數據處理的目的及方法論。
數據分析的一般流程：
- 確定目標
- 獲取數據源
- 數據探索
- 數據預處理
- 挖掘分析建模
- 模型效果評價
借用一張同事繪製的圖片
統一數據接入
數據接入，尤其是針對目前多元異構數據的(批處理數據、實時數據流式數據)接入，我們稱之爲統一數據接入。
文章鏈接：統一數據接入實踐分享
數據清洗的目的
數據清洗， 是整個數據分析過程中不可缺少的一個環節，其結果質量直接關係到模型效果和最終結論。在實際操作中，數據清洗通常會佔據分析過程的50%—80%的時間。
數據清洗的目的從兩個角度來講：
一、是爲了解決數據質量問題
二、是讓數據更適合做挖掘、展示、分析
解決數據質量問題
解決數據質量問題，其實就是爲了確保以下幾點：
針對每一點我們分別來看
- 數據的完整性
例如人的屬性中缺少性別、年齡等
- 數據的唯一性
例如不同來源的數據出現重複的情況，比如本次數據中我們基本信息中的序號，有部分重複的數據。這個可能是由於數據錄入兩次造成的。
- 數據的權威性
例如同一個指標出現多個來源的數據，且數值不一樣
- 數據的合法性
例如獲取的數據與常識不符，年齡大於150歲
- 數據的一致性
例如不同來源的不同指標，實際內涵是一樣的，或是同一指標內涵不一致
讓數據更適合做挖掘、展示、分析
從這個角度講，數據清洗的工作更偏向工程，不是我們這次關注的重點.（有時間、有興趣的話會後詳細討論，就不佔用大家時間了。）
讓數據更適合做挖掘、展示、分析，有以下一些手段對數據進行清洗。
- 高維度----不適合挖掘
思路：降維，方法包括但不限於：
主成分分析PCA
隨機森林
- 維度太低----不適合挖掘
思路：抽象，方法包括但不限於：
各種彙總，平均、加總、最大、最小等
各種離散化，聚類、自定義分組等
- 無關信息----減少存儲
解決方法：剔除字段
- 字段冗餘
一個字段是其他字段計算出來的，會造成相關係數爲1或者主成因分析異常
解決方法：剔除字段
- 多指標數值、單位不同
如GDP與城鎮居民人均收入數值相差過大
解決方法：歸一化，方法包括但不限於：
最小-最大
零-均值
小數定標
數據清洗的步驟
第0步：數據導入及元數據處理
數據導入及元數據處理階段主要主要關注兩件事情：
1.瞭解數據量
通過了解數據量（批處理，還是流式數據），將數據導入處理工具或者平臺。通常來說，數據量不大的情況建議使用數據庫。
如果數據量大（千萬級以上），可以使用hadoop文本文件存儲+Python操作的方式。
這個步驟對於批處理，文件交換的方式通常比較會引起問題是文件編碼，推薦統一使用UTF-8編碼。
2.瞭解元數據
這裏包含兩個部分：
一是看元數據，包括字段解釋、數據來源、代碼表等等一切描述數據的信息；如果數據是多維度的我們要弄清楚數據之間的關聯關係。
二是抽取一部分數據，使用人工查看方式，對數據本身有一個直觀的瞭解，並且初步發現一些問題，爲之後的處理做準備。
第一步：缺失值清洗
缺失值是最常見的數據問題，處理缺失值也有很多方法，我建議按照以下四個步驟進行：
1、確定缺失值比例和範圍
對每個字段都計算其缺失值比例，然後按照缺失比例和字段重要性，分別制定策略，可用下圖表示：
2、去除不需要的字段
這一步很簡單，直接刪掉即可……但強烈建議清洗每做一步都備份一下，或者在小規模數據上試驗成功再處理全量數據，不然刪錯了會追悔莫及（多說一句，寫SQL的時候delete一定要配where！）。
3、填充缺失內容
某些缺失值可以進行填充，方法有以下三種：
以業務知識或經驗推測填充缺失值
以同一指標的計算結果（均值、中位數、衆數等）填充缺失值
以不同指標的計算結果填充缺失值
前兩種方法比較好理解。關於第三種方法，舉個最簡單的例子：年齡字段缺失，但是有部分脫敏可以計算年齡的身份證號
4、重新獲取數據
如果某些指標非常重要又缺失率高，那就需要和取數人員或業務人員瞭解，是否有其他渠道可以取到相關數據。
以上，簡單的梳理了缺失值清洗的步驟，但其中有一些內容在實際工程應用中會更加複雜。
比如填充缺失值。很多講統計方法或統計工具的書籍會提到相關方法。
第二步：格式內容清洗
如果數據是由系統日誌而來，那麼通常在格式和內容方面，會與元數據的描述一致。
而如果數據是由人工收集或用戶填寫而來，則有很大可能性在格式和內容上存在一些問題，簡單來說，格式內容問題有以下幾類：
1、修正格式的統一
時間、日期、數值、全半角等顯示格式不一致
這種問題通常與輸入端有關，在整合多來源數據時也有可能遇到，將其處理成一致的某種格式即可。
2、修正內容類型的統一
內容中有不該存在的字符
某些內容可能只包括一部分字符，比如身份證號是數字+字母，中國人姓名是漢字（趙C這種情況還是少數）。最典型的就是頭、尾、中間的空格，也可能出現姓名中存在數字符號、身份證號中出現漢字等問題。
這種情況下，需要以半自動校驗（正則表達式）半人工方式來找出可能存在的問題，並去除不需要的字符。
3、內容與該字段應有內容不符
姓名寫了性別，身份證號寫了手機號等等，均屬這種問題。 但該問題特殊性在於：如果數據很重要那麼不能簡單的以刪除來處理，因爲成因有可能是人工填寫錯誤，也有可能是前端沒有校驗，還有可能是導入數據時部分或全部存在列沒有對齊的問題，因此要詳細識別問題類型。
格式內容問題是比較細節的問題，但很多分析失誤都是栽在這個坑上，比如跨表關聯或VLOOKUP失敗（多個空格導致工具認爲“陳丹奕”和“陳 丹奕”不是一個人）、統計值不全（數字裏摻個字母當然求和時結果有問題）、模型輸出失敗或效果不好（數據對錯列了，把日期和年齡混了，so……）。
因此，請各位務必注意這部分清洗工作，尤其是在處理的數據是人工收集而來，或者你確定產品前端校驗設計不太好的時候……
第三步：邏輯錯誤清洗
這部分的工作是去掉一些使用簡單邏輯推理就可以直接發現問題的數據，防止分析結果走偏。主要包含以下幾個步驟：
1、去重
有的分析師喜歡把去重放在第一步，但我強烈建議把去重放在格式內容清洗之後，原因已經說過了（多個空格導致工具認爲“陳丹奕”和“陳 丹奕”不是一個人，去重失敗）。而且，並不是所有的重複都能這麼簡單的去掉……
當然，如果數據不是人工錄入的，那麼簡單去重即可。
2、去除異常值 outliar
一句話就能說清楚：
有人填表時候手抖，年齡200歲，這種的就要麼刪掉，要麼按缺失值處理。這種值如何發現？
一般有兩種手段：
- 基於統計與數據分佈
最大值，最小值，分箱，分類統計，Pandas Value count
峯值偏度，是不是正態分佈。
- 箱形圖分析
3、修正矛盾內容
有些字段是可以互相驗證的，舉例：身份證號是1101031980XXXXXXXX，然後年齡填18歲。在這種時候，需要根據字段的數據來源，來判定哪個字段提供的信息更爲可靠，去除或重構不可靠的字段。
邏輯錯誤除了以上列舉的情況，還有很多未列舉的情況，在實際操作中要酌情處理。另外，這一步驟在之後的數據分析建模過程中有可能重複，因爲即使問題很簡單，也並非所有問題都能夠一次找出，我們能做的是使用工具和方法，儘量減少問題出現的可能性，使分析過程更爲高效。
第四步：非需求數據清洗
這一步說起來非常簡單：把不要的字段刪了。
但實際操作起來，有很多問題，例如：
把看上去不需要但實際上對業務很重要的字段刪了；
某個字段覺得有用，但又沒想好怎麼用，不知道是否該刪；
一時看走眼，刪錯字段了。
前兩種情況我給的建議是：如果數據量沒有大到不刪字段就沒辦法處理的程度，那麼能不刪的字段儘量不刪。第三種情況，請勤備份數據……
第五步：關聯性驗證
如果你的數據有多個來源，那麼有必要進行關聯性驗證。
例如，你有汽車的線下購買信息，也有電話客服問卷信息，兩者通過姓名和手機號關聯，那麼要看一下，同一個人線下登記的車輛信息和線上問卷問出來的車輛信息是不是同一輛，如果不是（別笑，業務流程設計不好是有可能出現這種問題的！），那麼需要調整或去除數據。
嚴格意義上來說，這已經脫離數據清洗的範疇了，而且關聯數據變動在數據庫模型中就應該涉及。但我還是希望提醒大家，多個來源的數據整合是非常複雜的工作，一定要注意數據之間的關聯性，儘量在分析過程中不要出現數據之間互相矛盾，而你卻毫無察覺的情況。
數據採集建議
一行代碼探索性數據分析
python Pandas Profiling 一行代碼EDA 探索性數據分析
數據預處理
近年來，隨着相關算法的日趨成熟，決定一個項目是否成功的關鍵因素逐漸從算法本身變成了“數據探索+數據預處理”這個部分。
有句話說的好：
數據和特徵工程決定了學習的上限
模型和調參等只不過是竭盡所能去逼近這個上限
數據預處理的主要步驟：數據清理、數據集成、數據規約和數據變換。
參考文獻
參考1：https://www.zhihu.com/question/22077960
參考3：https://zhuanlan.zhihu.com/p/20571505
參考4：https://zhuanlan.zhihu.com/p/54172870
https://blog.csdn.net/jiazericky/article/details/80322225
https://blog.csdn.net/walterudoing/article/details/51782704