數據太髒了！3個步驟做好數據質量(資料品質)管理

『Garbage In, Garbage Out』相信大家一定都聽過。

在做數據分析、數據應用的過程中如果我們用的數據是髒數據，很容易產生沒用、甚至錯誤的結果。因此好的數據很重要，但”好”是個形容詞，用比較科學的角度給出定義，就是數據質量/資料品質(Data quality) 的議題。

Data quality refers to the development and implementation of activities that apply quality management techniques to data in order to ensure the data is fit to serve the specific needs of an organization in a particular context.

資料品質管理-是可以有效減少髒數據的管理方式

寫文章3年多了，以往以數據分析為主，但數據的領域很廣，今年我的方向會著墨在數據中台、數據治理、數據應用、還有團隊、管理等思考議題，有些是新學習的方向、有些是想整理自己在實踐過程中的思考，也希望你們有興趣。感謝支持，新年快樂！

---

一、髒數據導致什麼的問題

先看兩個因為數據量差而產生問題的案例：

• 分析訂單金額時，發現大幅上漲，透過維度拆解層層分析後，後定位到了可能的問題訂單，拉出該筆訂單詳情一看發現該筆訂單的下單人有點奇怪，詢問後才知道原來那人是公司的後端工程師，昨天在做系統測試時所產生的訂單
• 分析訂單金額時，發現部分商家金額大幅下滑，但成交數沒什麼變，這結果很矛盾，經過一陣查詢，原來是商家修改了幣別，改為美金計價

數據倉庫乘載了各種數據，包含由不同部門、不同系統的生產數據、手工錄入數據、第三方外部數據，因此現實中遇到的問題相當多樣。有時候一個數據問題的排查就可以花費兩三天，相當耗費分析師的精力跟時間，錯誤的數據更可能導致模型不可用、全部重頭來的情況。

• 影響了數據分析的價值
• 重複返工、大量溝通
• 做出了錯誤的商業判斷

二、髒數據產生的原因

從數據生產、採集到清洗的各個環節都可能出現數據質量的問題，自己曾經遇過的情況大致歸納如下：

• 為了提高或降低考核指標，對數據進行人為造假，例如銷售撥打客戶電話，不論是否有溝通，就紀錄了已跟進（當初是對通話時長＆跟進紀錄交叉比對後發現）
• 在數據錄入時，漏填或填錯信息，造成數據的質量問題（例如收集用戶所在行業時，在沒有特別誘因下，用戶通常選第一個選項）；另外企業都有多套的業務系統，這些業務在不同時期由不同的團隊開發完成。即便各自業務系統都參考著自己的標準，但彙整到數倉後就是不同的標準，也會有像是奇怪的縮寫詞，數據輸入錯誤，重複記錄，數據丟失值，不同拼寫等。
• 後端數據庫表結構、約束條件等系統原因，造成數據錄入無法校驗或校驗不當，這邊過於技術不太了解具體原因，印象比較深的有訂單號重複生成多筆，行為日誌數據上報丟失等
• ETL過程的bug，例如hive表跟業務表的數據映射錯誤，重複拉取數據。只要在數據轉換、數據存儲過程中，任一環節有技術問題，都有可能造成數據質量問題。

三、資料品質的評價維度

這麼多大大小小、千奇百怪的問題，被收斂成六個維度來衡量，分別是：唯一性、完整性、一致性、準確性、合理性(有效性)、即時性

唯一性 Uniqueness

Uniqueness ensures there are no duplications or overlapping of values across all data sets.

完整性 Completeness

Completeness is a measure of the data’s ability to effectively deliver all the required values that are available.

一致性 Consistency

Data consistency refers to the uniformity of data as it moves across networks and applications. The same data values stored in difference locations should not conflict with one another.

準確性 Accuracy

The data should reflect actual, real-world scenarios; the measure of accuracy can be confirmed with a verifiable source.

合理性（有效性） Validity

Data should be collected according to defined business rules and parameters, and should conform to the right format and fall within the right range.

即時性 Timeliness

Timely data is data that is available when it is required. Data may be updated in real time to ensure that it is readily available and accessible.

其中，“準確”這個概念比較抽象，因為我們很難通過一個強邏輯性的判斷，來說明數據有多準，大部分都存在於感性或業務sense的認知，所以準確性也是比較難做好的方向，在校驗過程中也常會跟合理性(有效性)有一定重疊。

四、如何提昇資料品質？

加強數據質量，我自己經驗會從事前、事中、事後這三個階段下手

STEP1. 資料品質管理-事前規範

對於業務錄入的問題，我們可以透過權限或是制度來盡可能避免，例如重要字段為必填、經理才有權限對部分數據修改、虛假數據的懲罰制度等

對於重要數據且橫跨多個產品/開發團隊的數據，數據人員也要盡可能的統一規範，例如web/App端的日誌能用統一的SDK、統一的數據上報機制。

P.S 埋點相關內容可參閱文章：透過埋點，讓數據說話：埋點基本知識

ETL過程中，我們可以進行像是數倉開發規範等內部共識，減少開發過程的問題。

最後是文化建設，透過像是培訓、分享、路演、考試、宣導等教育用戶的手段，培養前後端工程師跟業務重視數據質量、了解對下游應用所產生的影響。

STEP2. 資料品質管理-事中清洗

老系統或歷史遺留問題，一般很難推動業務系統的改造，此時需要根據以上準則做數據清洗、並根據資料倉庫管理理論，對業務方頻蔽處理環節與數據權限，消除跨層引用和模型冗餘等問題，將乾淨、可用的數據存放至DWS層，作為統一的數據出口。

對於數倉工程內部團隊，加入測試、評審環節，數據質量過關才可發布。若要進行數據更新操作，需要提前通知使用方數據變更原因、變更邏輯、變更時間等信息，沒有異議後再按照約定時間執行發布操作。

STEP3. 資料品質管理-事後監控

數據是動態的，因此數據質量問題不是一次性的處理就可以結束的。我們必須有即時發現問題的能力，減少對業務的影響。負責團隊也該例行對常見問題整理，看能否優化成step1 或 step2中解決。

根據數據質量的準則，監控方向大致有：

• 規範類：如表結構、表命名、字段命名、表註釋、文件路徑
• 業務類：責任人、歸屬的業務、血緣關係、分母是否為0、NUll值是否參與計算等
• 性能類：數據波動情況(增量數據行數、表全量總行數)、計算運行時長、資源消耗情況、大表提醒、重複計算監測、大小表join操作等

另外，在數倉中有成千上萬的表，所以如果是用共享文檔這種靠人工維護的方式很容易力不從心，更好的話是能有一個管理工具來實現。

五、最後

好的數據可以節省試錯的成本，對於質量很差的數據集，我們沒有必要花費太多的精力、或是我們可以對開發時間與工作階段做更準確的預估。可以縮短數據反饋流程，更及時的將過程中存在的問題反饋給上下游，提高協作效率。最後，可以避免錯誤的分析結論，如果我們能夠及時發現數據中存在的錯誤和失真，就能夠避免因為數據本身的問題而讓我們得出錯誤的結論。這些都是資料品質管理-在數據應用上的好處。

如果有過分析經驗，相信分析過程都或多或少遇到數據質量問題，所以數據質量評估我覺得和EDA（探索性數據分析）過程是有部分重疊，但兩者的關注重點還是有一些區別。

EDA關注的是數據背後隱藏的規律或模式；質量評估關注的重點是觀察數據集和業務需求之間的關聯程度。數據質量問題不單單是數據分析師自己的工作，和需要和數據開發、產品、測試等多個部門共同合作完成，是一個非常繁瑣的工作。

是否需要進行數據質量的管理也要根據公司所屬階段來思考。在業務發展初期，很多商業模式都還處於快速驗證市場需求階段，數據質量問題還沒有那麼明顯。

但我們還是要有數據質量管理的意識，這不該是一個階段性的項目，而是一個貫徹數據建設各階段的長期工作，只是在不同階段，其覆蓋的範圍和關注的目標有所差異。

---

ref: 

• 美团配送数据治理实践
• 数据资产，赞之治理
• datawork
• Data Quality