企業大數據質量管理的一些經驗 - 知乎專欄 https://zhuanlan.zhihu.com/p/25309728
將各產品線的用戶標識統一，然后統一對用戶行為log進行統一定義，所有的log在錄入DT平臺時，均需要按照統一的schema來錄入。
除了客戶端的統一定義之外，數據平臺方對數據表的schema設計也很重要，這直接決定了數據錄入之后的數據質量。
//
因為百度內部有很好的wiki系統，這套系統設計完成之后，所有log的定義、User Data Warehouse中的fact tables和dimension tables都在wiki上有明確的記錄，方便后來者對知識的繼承。
后來系統上線之后，我們通過對數據的diff工作，將數據處理環節中可能導致數據異常的問題全部排查了一遍（這些大部分都是一次性工作），最終保證了最后分析平臺上線時數據的質量。
//
總結起來就只有幾點：
– 定義明確
– 策略清晰
– 規范統一
– 知識繼承
– 誤差可解釋
當然，不論前期做得多么好，數據diff的工作要認真做，這將是最佳的全盤檢查的機會。
這幾年一直在互聯網公司從事數據分析數據產品相關的工作，因此主要從過去工作中碰到的數據質量的問題中引申出來的一些想法和執行情況。
Google最早建立了網站的數據質量標準
最早入門做數據分析的時候，我主要依賴google analytics來做網站的流量分析。這個時期是沒有數據質量問題的——因為全部是用的google的標準和定義，我要做的就是學習它的規則。
移動產品的數據質量須從客戶端開始，且越早越好
我第一次遇到數據質量問題，是在百度做一個行業分析數據產品的時候。這個時期的數據質量的問題主要來自于移動設備數據上傳的不穩定性。當時的產品需要應用調用系統的某些接口來獲取數據來進行統計，數據在采集和上傳的時候會有一部分數據丟失，導致部分數據記錄不全或者紀錄丟失的情況。
從這里我得到的經驗就是在做移動端相關產品的數據分析和產品時，第一要務就是保證客戶端采集和上傳數據的穩定性和一致性——確保不同版本客戶端發布的時候原始數據采集的口徑一致，以及在復雜網絡狀況以及用戶行為情況下數據上傳策略合理。
當然有些時候我們不可能保證數據完全的正確。畢竟數據上傳的時候用戶的移動網絡斷掉，以及跨天行為統計所產生的誤差是不可避免的。移動客戶端的數據總會有那么百分之零點幾的差異，但是只要在可控的范圍內，就可以保證后續生產數據的質量。
多產品線最重要的是用戶標識的一致
2012年的時候有幸參與到百度公司級別的一次大數據平臺建設浪潮中。當時基礎架構部與移動云事業部聯合開展了一個針對移動云所有產品線的大數據平臺落地計劃。
因為歷史原因，當時移動云的數據治理以及數據應用的狀況不太理想。各個產品線各自為戰，自己打自己的產品log，然后自己從log中取出自己想要的計算字段算出結果來分析產品。這種方式不僅效率低下，而且同一個事業部的不同產品數據不能打通分析，更妄談同其他事業部甚至PC端的搜索數據打通了。
解鈴還需系鈴人
當時最需要做的事是將各產品線的用戶標識統一，然后統一對用戶行為log進行統一定義，所有的log在錄入DT平臺時，均需要按照統一的schema來錄入。這樣做會導致很多的歷史數據丟失，但是讓后續所有的產品線依賴公司統一大平臺資源（比如后來做推廣時，整體可以用同一套推廣系統和質量管控系統等）。
這個過程中，以什么為規范來做統一的定義是一個比較麻煩的事情，如果重新定義一套，會導致數據沒有延續性，對自身內傷嚴重。所以當時產品部門內部商定了以搜索產品為核心來制定整體標準，簡單來說就是所有的產品采用搜索產品歷史沿襲的log定義規則來進行修改。最終達成客戶端日志的統一性。
除了客戶端的統一定義之外，數據平臺方對數據表的schema設計也很重要，這直接決定了數據錄入之后的數據質量。
因為百度內部有很好的wiki系統，這套系統設計完成之后，所有log的定義、User Data Warehouse中的fact tables和dimension tables都在wiki上有明確的記錄，方便后來者對知識的繼承。
后來系統上線之后，我們通過對數據的diff工作，將數據處理環節中可能導致數據異常的問題全部排查了一遍（這些大部分都是一次性工作），最終保證了最后分析平臺上線時數據的質量。
更多的問題來自對數據的定義
繼續下去的經歷中，基本上客戶端的數據質量問題都比較容易的解決掉了。反而是業務需求端定義不明確的問題一而再的發生——特別是業務流程比較復雜的時候。比如當時在滴滴打車有這么一個指標：訂單完成數。這里有個問題，訂單是結束計算完成還是支付算完成？然后你就發現：
– 如果按照訂單結束，不論支付來看，那么一個跨越12點的訂單會在第一天計算成一個未完成訂單，第二天多一個完成訂單。數據回溯可以解決這個問題，但是你會發現當你回頭看歷史數據時，數字總是在變的。
– 如果按照訂單支付結束來計算——數據回溯都解決不了跨天的問題了，因為好幾天之后再支付的用戶比比皆是。
這種情況在周五以及節假日前出現的情況尤其多，導致那時候的數據基本不可用，而且很多策略出現問題——當時有個政策是對一天拉滿N單的司機進行獎勵，那么到了凌晨的時候，有些忙著完成任務的司機會拒絕接受長途訂單，然后用戶就不開心了。
之后我們就將這一個指標拆解成訂單完成數和訂單支付支付完成數，這兩個數據不進行數據回溯，只是按照訂單最終狀態發生的時候來計算。但是在計算訂單完成率和訂單支付成功率時，我就比較煩惱了，然后這個問題直到我最終離職也沒有比較好的解決辦法（求高手支招）。
絮絮叨叨說了這么多，其實總結起來就只有幾點：
– 定義明確
– 策略清晰
– 規范統一
– 知識繼承
– 誤差可解釋
當然，不論前期做得多么好，數據diff的工作要認真做，這將是最佳的全盤檢查的機會。
歡迎大家掃碼關注數據產品經理公眾號，如想加入《數據產品經理會》群，請加 劉洋 微信：liuyangfjnu 。
