數據預處理——從Raw Data到符合模型所需的過程
經歷費時的數據採集階段後，我們已經收集到所需的數據，但目前為止它們只是原始數據(Raw Data)，接下來需進入「數據預處理」的階段。數據預處理的目標即是將Raw Data處理到符合模型所需，其可分為資料整合、數據清洗、降維、標準化四個步驟，也有人習慣以不同的名詞來稱呼，或是分得更精細，但其實目標都是一樣的，知道為什麼要做這些，自然就能融會貫通地來處理Raw Data，不拘泥於形式。
本系列文章將不著重於代碼分享（代碼會放成單篇的），而會專注在實務的整體思路，因為我相信在AI專案的漫漫長路上，關鍵是對於整體的掌握（每個階段的階段性目標是什麼？目前還缺失的是哪一塊？），以及對於數據理解的高度（透徹執行每個環節的原因，以及看到數據現狀即能連結可能的解法），最後要將思路轉換成代碼，則是一種手段而已；此外，也不妨將此系列文章視為待辦清單，我希望達到的目標是實際、完整、概念透徹，這大概也是我身為Product Manager的堅持了，我也會盡可能將此系列用最精簡的方式陸續完善。
因為預處理有四個步驟，內容可能稍多，故將分為四篇文章，以下先各自用一段話來說明每個步驟的目標。
資料整合：數據的來源通常不止一個，可能來自不同部門、系統、業務……，最終彙整在一起時，便有結構、格式、單位、命名方式等等的整合問題，此階段就是處理將不同數據源的數據放入同一數據庫的所有問題。
數據清洗：數據中有許多雜質，此階段便是對於離散值、缺失值、噪聲等做處理，目標是提高數據質量。
降維：目標是通過技術手段降低數據維度，用一個相對低維的向量來表示原始的特徵，以避免高維空間的數據稀疏導致的維度災難，即產生過擬合的問題，並提高建模效率。
數據變換：數據中不同特徵的量級範圍可能不一致，自然缺乏了可比性，因此本階段目標是將數據按一定比例進行縮放，以利後續的分析與建模。常見的規範化處理，是將數據映射到[0,1]區間內。
3.1 資料整合
雖然AI數據的處理較少提及資料整合的部分，畢竟這是大數據的根本概念，與AI沒有特定關係，但為求完整，同時也想紀錄一些實務上的細節，還是決定加入本篇的內容。
從資料治理(Data Governance)開始
欲實現資料整合，第一步便是要貫徹Data Governance，一般翻作「數據治理」或「資料治理」。資料治理是資料管理學科裡的一部份，主軸是在討論資料所有權、資料權責與資料標準化的問題，簡單說就是先釐清權利與義務，以及統一格式，由此再出發，才能發展資料管理中的其他部分，例如資料架構、資料品質、資料安全等。
值得一提的是，目前提到資料治理，大多是要解決資料斷點的問題，這也是管理大數據初期最容易遇到的問題，因此許多人將資料治理直接連結到「建立大數據平台」的行動上。數據斷點發生的原因通常是因為數據散佈在組織各個部門，沒有進行彙整、各自為政，甚至在取用上還不一定能獲得別的部門的同意，例如零售部門可能不願意把數據交付給電商部門，畢竟這關係到業務績效。
實務上，在大型組織架構中，光是要將所有數據透明化地儲存到統一的資料庫，就不免開啟一場革命，尤其數據的所屬權、管理權與仲裁權，都必須在此過程中被完整規範。經由以上說明，應該可以清楚看到為何談論資料整合就必須落實資料治理。
資料治理本身是一個較大的課題，屬於組織長期性策略，更是其要實現數據驅動(Data-Driven)的第一步，我覺得這篇文章「What is data governance? A best practices framework for managing data assets」的完整性對於目前已經足夠，有興趣可以參考。
實務上資料整合面臨的問題及其解決方式
因「不一致」而須整合的問題，容易理解，但種類繁多，以下直接舉實例來了解各部細節。
1. 名詞定義不一致（欄位名稱/ 表名/ 數據源名）
語意問題：兩個不同的數據源都記錄著pants，但一個指的是內褲，另一個指的是一般的褲子；各自使用了salary和wage，但指的都是薪水。
計算方式：兩個不同的數據源都記錄了支出給表演者的cost，但一個是稅前的費用，另一個則是稅後。
>> 解決方式：創建「命名規則表」，令欄位名稱、表名、甚至數據源名，都有統一的規範，未來都必須依表命名，或直接由系統依表中規範自動生成。
2. 結構定義不一致（收集到的數據結構）
單位不一致：公斤(kg)轉換為磅(lb)、幣別的不同等等，類似前者的差異可能很容易察覺，後者這類差異如果處理不當，則可能會造成極大的問題。
格式不一致：最常見的大概就是日期格式的不同了，細微差異可能為YYYYMMDD、DDMMYYYY或是YYYY/ MM/ DD等等。
數據類型不一致：以python來說，就有字符串(str)、整數(int)、浮點數(float)三種數據類型。
是否允許空值(null)：null不是0，更不是數據缺失，而是代表「未知」的概念。比如，用戶下訂了商品，因此訂單確立，與之相關的商品名稱、商品數量、訂單日期等數據將一併寫入後台數據庫，此時寄送日期尚屬未知，於後台寫入的就是null（前台則可能顯示”等待出貨中”這類的文案），待賣方寄件後，後台才會再次寫入寄送日期。反之，商品名稱、商品數量、訂單日期這些數據則不能允許空值。
>> 解決方式：收集數據前一定要妥善規範「結構定義表」，確保與之前其他數據源的定義一致，以減少之後整理上的麻煩。
總之，以上大多可經由統一定義而避免掉，即便會有陣痛期，但實務上不是太大問題，通常經過幾次整合即可解決，之後遇到相似的問題也只需依循邏輯拓展，或是補充定義即可。較麻煩的反而是以下「數據衝突」、「數據重複」和「數據冗餘」的問題。
3. 因數據衝突而產生的
雖看似一種不一致的問題，但它們本質上是不一樣的，由數據衝突產生的問題無法經由統一定義後直接轉換，需要更專業的判斷。舉例來說，HR系統中有兩種性向評分機制，一種是60分及格（取值範圍為0~100），另外一種是5分及格（取值範圍為1~10），而這兩種數據源都擁有”qualify or not”的數據。則當一位候選人前者得分是58（不合格），後者得分是5（合格），此時兩個表格合併時，同一位候選人的”qualify or not”就會有所衝突，對待這種問題，可以選擇取捨、兩者皆保留，甚至依比例再處理為新的合格分數，而如何處理皆有賴於HR的專業判斷。
>> 解決方式：由數據中心提交專業單位定義後發回。解決方式雖看似單純，但在真實情境中，這對於專業單位可能是一個十分重要的抉擇，通常需要花較多的時間討論與擬定。
固然「重複」和「冗餘」都是指「多餘的、需刪除的」數據，但兩者在數據處理中，有著截然不同的意義，為防僅用文字解釋難以釐清兩者差異，以下會搭配編碼或表格的方式來說明。
4. 因數據重複而產生的
表中能確定唯一性的值，就稱為主鍵(Primary Key)，例如「身分證字號」就是唯一值。每張表都應該習慣定義出主鍵，對於移除重複的數據有極大的幫助。以下情況就是通過「身分證字號」來排查是否有重複的會員。
>>> ID = ['123', '333', '435', '573', '333', '435']
>>> new_set = set(ID)
>>> new_list = list(new_set)
>>> new_list
['123', '333', '435', '573']
利用python刪去相同身分證ID的會員，從六位會員中找到兩條重複的數據，留下四位會員。
這裡還可以看出數據重複下的兩個insights：
因數據重複，我們必須進行數據刪除，這會導致數據源的更新，同時關聯此數據源的其他數據源必須一同更新，否則會造成數據源的不一致。在上述情境下就可能會造成不同數據源中的會員人數竟然不一致。
數據重複的情況下，如果兩條或多條數據一致，那麼此時去重很單純，利用函數直接刪掉重複數據即可；最麻煩的是兩條或多條數據不一致的狀況，得先比對是否是因資料定義不一致產生的（也就是第一大項的問題，因為可能數據是正確的，只是單位、格式等不同，此時只要統一即可），如果不是的話，則可能是數據錯誤，此時就需要人力調研，檢查到底何者是有問題的數據源，直接看以下例子會比較清楚。
( 圖A )
假設圖A是上述情境的實際數據集，可以看到333和435是完全重複的數據，這通常來自資料的重複送出，或是重複註冊會員等情況，只要直接去重即可。
( 圖B )
圖B則是重複數據不一致的情況，我們推斷ID333不是同一個人，ID435則有可能是同一個人，只是其中一條數據的生日欄位因某種因素處於預設狀態。在這樣的狀況下，便要對如何處理這些數據進行決策（暴力刪除？有條件保留？是否有人力階段性逐一審核？）。
>> 解決方式：透過主鍵進行檢查，沒有主鍵的表可以嘗試定義主鍵。發現重複的數據是一致時，可以直接刪除；發現重複的數據不一致時，則要檢查可能的原因並考慮處理方式。
5. 因數據冗餘而產生的
數據冗餘，即是在一個關係數據庫中，重複儲存了同樣的數據，這通常源於關係數據庫本身設計的問題。不良的數據庫設計、不良的操作習慣等等，都會造成非必要的數據冗餘，須從根本上調整；但許多時候，數據冗餘是必要的存在，譬如為了方便查詢、防止數據丟失等原因。因此，它並非一個負面的概念——即便在數據庫設計良好的情況下，我們依舊必須處理數據冗餘的問題。
這裡舉個常見的例子。例如，我們在數據源A中需要查詢數據源B的數據，但在兩個大表間做關聯查詢時常會造成系統負荷量過大，跑一跑可能就crash了，因此，在設計表時，假設表A是紀錄圖片的，為了方便，也會放入產品名稱和網址；表B是紀錄產品的，同樣也會放上圖片名稱和網址。如果將兩表合併，自然就會產生數據冗餘，但此時它是數據庫設計下正常的產物。
檢查數據冗餘的方式，通常可藉由檢測字段的相關性來查找，其又大致分為兩種情況：
數值型數據：可使用Pearson相關係數進行相關性分析，觀察X和Y變量之間的線性相關（其值介於1到-1之間）。假設該Pearson係數越靠近+1或-1，即是相關性越大，+1為完全正相關，-1為完全負相關。若Pearson係數為0，則兩個字段之間不相關。
分類型數據：可使用卡方檢驗，又稱為獨立性檢定，適用於分析兩組分類型數據的關聯性。其思想就是在比較觀察值和理論值之間的偏離程度。操作思路如下：
H0：字段A與字段B之間相互獨立
H1：字段A與字段B之間存有相關性
首先假設H0成立，利用Pearsonχ2的公式計算出χ2（觀察值和理論值之間的偏離程度），此乃假設是否成立的度量指標。χ2越小，就越傾向H0是成立的；χ2越大，H0就越可能不成立。
提到數據冗餘還必須要知道的知識點：
非必要的數據冗餘，可透過資料庫正規化(database normalization)的設計來避免——所謂的「範式設計」。正規式越高，對於數據的規範越多，目前建表時大多考慮到第三正規式。
數據冗餘看似是相同的數據儲存在不同的位置或表中，似乎在資料整合後，直接去重即可，但實際狀況卻時常是在資料維護時，並沒有把這些不同位置但同樣的資料進行同步更新，導致資料不一致，因此無法直接刪除，需要進行數據重複時的處理（暴力刪除？有條件保留？等等）。
>> 解決方式：可藉由檢測字段的相關性來查找。
小結
資料整合的精神就是將不同數據源的數據納入同一數據庫，因此遇到的大多是原則性的問題，檢查上也許特別耗時，但一旦將原則建立地愈加完備，處理效率也會大幅提升，本階段會遇到的技術問題通常也只要熟稔自家數據庫的操作即可處理。
最後，資料整合階段是掌握自家數據全貌的最佳時刻，更是建構數據治理策略以獲得良好數據體質的時刻，應該更慎重地看待它。
本文劃重點
了解數據預處理的階段性目標。
資料治理(Data Governance)的主軸是討論資料所有權、資料權責與資料標準化，目前多藉由建立大數據平台的過程來落實資料治理，同時解決資料斷點的問題。
資料整合上會遇到的問題及處理方式：
名詞定義不一致：創建「命名規則表」
結構定義不一致：規範「結構定義表」
數據衝突：由數據中心提交專業單位定義後發回
數據重複：透過主鍵刪除
數據冗餘：透過檢測字段相關性來查找，再進行刪除