資料清洗經驗

hello小工發表於2016-03-17

平時習慣了在某些特定的資料集合上做實驗,簡單的tokenization、預處理等步驟就足夠了。但是在資料越來越大的年代,資料清洗越來越重要,也越來越複雜。看到Philip J.Guo 的這篇英文文章《Parsing Raw Data》覺得不錯,學習並譯成中文,難免謬誤,僅供參考。

  前言

  科研工作者、工程師、業務分析者這些和資料打交道的職業,資料分析在他們工作中是一項核心任務。這麼不僅僅針對“大資料”的從業者,即使你筆記本硬碟上的資料也值得分析。資料分析的第一步是洗資料,原始資料可能有各種不同的來源,包括:

  1. Web伺服器的日誌
  2. 某種科學儀器的輸出結果
  3. 線上調查問卷的匯出結果
  4. 1970s的政府資料
  5. 企業顧問準備的報告

  這些來源的共同點是:你絕對料想不到他們的各種怪異的格式。資料給你了,那就要處理,但這些資料可能經常是:

  1. 不完整的(某些記錄的某些欄位缺失)
  2. 前後不一致(欄位名和結構前後不一)
  3. 資料損壞(有些記錄可能會因為種種原因被破壞)

  因此,你必須經常維護你的清洗程式來清洗這些原始資料,把他們轉化成易於分析的格式,通常稱為data wrangling。接下來會介紹一些關於如何有效清洗資料,所有介紹的內容都可以由任意程式語言實現。

  使用斷言

  這是最重要的一點經驗:使用斷言(Assertions)揪出程式碼中的bug。用斷言的形式寫下你對程式碼格式的假設,如果一旦發現有資料跟你的斷言相悖,就修改這些斷言。

  記錄是有序的?如果是,斷言之!每一條記錄都是有7個欄位麼?如果是,斷言之。每一個欄位都是0-26之間的奇數麼?如果是,斷言之!總之,能斷言的都斷言!

  在理想世界中,所有記錄都應該是整整齊齊的格式,並且遵循某種簡潔的內在結構。但是實際當中可不是這樣。  寫斷言寫到你眼出血,即便是出血還得再寫。

  洗資料的程式肯定會經常崩潰。這很好,因為每一次崩潰都意味著你這些糟糕的資料又跟你最初的假設相悖了。反覆的改進你的斷言直到能成功的走通。但一定要儘可能讓他們保持嚴格,不要太寬鬆,要不然可能達不到你要的效果。最壞的情況不是程式走不通,而是走出來不是你要的結果。

  不要默默的跳過記錄

  原始資料中有些記錄是不完整或者損壞的,所以洗資料的程式只能跳過。默默的跳過這些記錄不是最好的辦法,因為你不知道什麼資料遺漏了。因此,這樣做更好:

  1. 列印出warning提示資訊,這樣你就能夠過後再去尋找什麼地方出錯了
  2. 記錄總共跳過了多少記錄,成功清洗了多少記錄。這樣做能夠讓你對原始資料的質量有個大致的感覺,比如,如果只跳過了0.5%,這還說的過去。但是如果跳過了35%,那就該看看這些資料或者程式碼存在什麼問題了。

  使用Set或者Counter把變數的類別以及類別出現的頻次儲存起來

  資料中經常有些欄位是列舉型別的。例如,血型只能是A、B、AB或者O。用斷言來限定血型只能是這4種之一雖然挺好,但是如果某個類別包含多種可能的值,尤其是當有的值你可能始料未及的話,就不能用斷言了。這時候,採用counter這種資料結構來儲存就會比較好用。這樣做你就可以:

  1. 對於某個類別,假如碰到了始料未及的新取值時,就能夠列印一條訊息提醒你一下。
  2. 洗完資料之後供你反過頭來檢查。例如,假如有人把血型誤填成C,那回過頭來就能輕鬆發現了。

  斷點清洗

  如果你有大量的原始資料需要清洗,要一次清洗完可能需要很久,有可能是5分鐘,10分鐘,一小時,甚至是幾天。實際當中,經常在洗到一半的時候突然崩潰了。

  假設你有100萬條記錄,你的清洗程式在第325392條因為某些異常崩潰了,你修改了這個bug,然後重新清洗,這樣的話,程式就得重新從1清洗到325391,這是在做無用功。其實可以這麼做:1. 讓你的清洗程式列印出來當前在清洗第幾條,這樣,如果崩潰了,你就能知道處理到哪條時崩潰了。2. 讓你的程式支援在斷點處開始清洗,這樣當重新清洗時,你就能從325392直接開始。重洗的程式碼有可能會再次崩潰,你只要再次修正bug然後從再次崩潰的記錄開始就行了。

  當所有記錄都清洗結束之後,再重新清洗一遍,因為後來修改bug後的程式碼可能會對之前的記錄的清洗帶來一些變化,兩次清洗保證萬無一失。但總的來說,設定斷點能夠節省很多時間,尤其是當你在debug的時候。

  在一部分資料上進行測試

  不要嘗試一次性清洗所有資料。當你剛開始寫清洗程式碼和debug的時候,在一個規模較小的子集上進行測試,然後擴大測試的這個子集再測試。這樣做的目的是能夠讓你的清洗程式很快的完成測試集上的清洗,例如幾秒,這樣會節省你反覆測試的時間。

  但是要注意,這樣做的話,用於測試的子集往往不能涵蓋到一些奇葩記錄,因為奇葩總是比較少見的嘛。

  把清洗日誌列印到檔案中

  當執行清洗程式時,把清洗日誌和錯誤提示都列印到檔案當中,這樣就能輕鬆的使用文字編輯器來檢視他們了。

  可選:把原始資料一併儲存下來

  當你不用擔心儲存空間的時候這一條經驗還是很有用的。這樣做能夠讓原始資料作為一個欄位儲存在清洗後的資料當中,在清洗完之後,如果你發現哪條記錄不對勁了,就能夠直接看到原始資料長什麼樣子,方便你debug。

  不過,這樣做的壞處就是需要消耗雙倍的儲存空間,並且讓某些清洗操作變得更慢。所以這一條只適用於效率允許的情況下。

  最後一點,驗證清洗後的資料

  記得寫一個驗證程式來驗證你清洗後得到的乾淨資料是否跟你預期的格式一致。你不能控制原始資料的格式,但是你能夠控制乾淨資料的格式。所以,一定要確保乾淨資料的格式是符合你預期的格式的。

  這一點其實是非常重要的,因為你完成了資料清洗之後,接下來就會直接在這些乾淨資料上進行下一步工作了。如非萬不得已,你甚至再也不會碰那些原始資料了。因此,在你開始資料分析之前要確保資料是足夠乾淨的。要不然的話,你可能會得到錯誤的分析結果,到那時候,就很難再發現很久之前的資料清洗過程中犯的錯了。

相關文章