|0x00 問題描述

上周收到一位讀者的詢問：怎么保證數(shù)據(jù)的正確性?

以下是原文：

上游，會遇到根源性問題，比如客戶端在數(shù)據(jù)上報時就傳錯的情況，比如手抖把下單時間不小心上報成了用戶點擊商品詳情的時間.

中游，指標的計算正確與否完全依賴于開發(fā)人員對于指標含義的理解以及業(yè)務方對于數(shù)據(jù)結果的敏感程度，一旦有一方出現(xiàn)問題即使指標統(tǒng)計錯誤也無人可以發(fā)現(xiàn)，甚至開發(fā)人員寫錯統(tǒng)計代碼，或者由于字段的值異常, 代碼沒有處理好異常等等導致計算腳本異常中斷，都會導致計算結果的偏差.

下游，業(yè)務方看到指標時，可能也對指標的統(tǒng)計口徑理解上有偏差，經(jīng)常需要問技術人員為啥這兩個指標是跟他預期不一致的，技術人員就總是要反復排查統(tǒng)計邏輯和解答業(yè)務人員的疑惑，很耗時.

關于這三個典型問題，我們分開來看。

|0x01 上游數(shù)據(jù)的保障

針對上游數(shù)據(jù)的保障，我的看法是，錯誤的發(fā)生是不可避免的，甚至一些隱藏的問題始終無法被發(fā)現(xiàn)，但我們要做的不是100%杜絕問題，而是及時發(fā)現(xiàn)95%的可疑問題。

因此，，針對ODS層，不論是數(shù)據(jù)同步任務、視圖還是其他形式，保障數(shù)據(jù)的準確性的核心有兩點：一是及時監(jiān)控問題的發(fā)生；二是保障一個流暢的上下游溝通方法。

但是，在防范問題發(fā)生之前，工程端也是要參與到數(shù)據(jù)準確性保障的工作中來，也就是盡可能在埋點平臺上做好保障，這個需要有比較好的功能測試。

其次，我們得有一套合理的埋點規(guī)范，不論是SPM，還是其他一些自定義的方法，合理的規(guī)范不僅能夠減少上下游的信息誤差，同時也會避免因為扯皮導致的一些數(shù)據(jù)問題，問題中的上報錯誤也會少很多，至少我們能夠加一層規(guī)范校驗來檢查出部分的問題，這還是比較關鍵的。

最后，要有可靠的數(shù)據(jù)同步工具，前一階段Sqoop下線了，但其他的工具，比如DataX，都可以來嘗試使用。當然，我們可以對一些具有典型特征的字段格式，做基本的校驗規(guī)則，比如日期、正數(shù)、手機號等。

其實數(shù)據(jù)出現(xiàn)錯誤是難免的，世界本就是概率的、而非永恒不變的，網(wǎng)絡波動、編碼錯誤、人工處理，都有很多可能導致問題。因此，在ODS接入階段，我們的建議是以發(fā)現(xiàn)問題為主。

但發(fā)現(xiàn)問題的方式，是有技巧的。比如，波動性監(jiān)控就是一種非常不錯的方法，通過檢測總條數(shù)、金額總數(shù)等具備統(tǒng)計學特征的指標，我們可以發(fā)現(xiàn)一些問題的端倪。如果波動在5%左右，需要確認原因；如果是10%，就可能是某些系統(tǒng)節(jié)點問題；如果是30%，就可能是面上的問題了。

發(fā)現(xiàn)問題后，及時跟上游反饋，一起看原因。解析失敗的數(shù)據(jù)不要丟，記錄下來，方便后續(xù)分析原因。

如果這個階段發(fā)現(xiàn)問題，建議直接阻斷，因為如果下游很多的話，刷新和解釋的成本還是很高，比如晚一點產出，確保沒問題。

|0x02 中游指標的計算

中游的保障思路，是通過強規(guī)范來約束行為，同時通過一些工具來保障強規(guī)范的落地。按照維度建模和一些數(shù)據(jù)治理的理論，當這一層嚴格執(zhí)行規(guī)范時，發(fā)生問題的概率，其實是非常小的。

中游，即CDM層，包括了DWD、DWS、DIM，是我們經(jīng)常強調的公共層，需要強規(guī)范和一些工具的保障來落地。強規(guī)范，代表分層、命名、編碼、CodeReview等規(guī)范，很多文章有詳細介紹，這里不再贅述。工具保障，是利用技術的力量，包括規(guī)則檢查、數(shù)據(jù)質量、數(shù)據(jù)對比、數(shù)據(jù)驗證等工具?？梢哉f，僅僅依靠規(guī)范是不夠的，我們需要工具來檢查規(guī)范的落地。

最典型的工具有這么幾種，一種是規(guī)則檢查，在Dataphin等開發(fā)工具上有內置，在命名上就加以規(guī)范；一種是報警設置，常規(guī)的開發(fā)工具也都會集成，比如編碼正確性校驗、權限檢測、冒煙測試、循環(huán)依賴檢查等，工具可以幫助避免大多數(shù)的低級錯誤；還有一種是數(shù)據(jù)對比工具，一些重構任務不確定會不會影響結果，通過對比工具則能快速實現(xiàn)這一目的。對于任務本身，需要檢查調度參數(shù)、依賴關系、定時設置等屬性。

重點介紹下DQC，也就是質量保障工具。比如檢查主鍵唯一、數(shù)據(jù)是否為空、波動性監(jiān)控等，從各個角度可以衡量今天產出的數(shù)據(jù)是否大體正常，一旦出現(xiàn)明顯不符合邏輯的數(shù)據(jù)，則證明今天的數(shù)據(jù)可能有臟數(shù)據(jù)，同樣會及時通知相關責任人進行排查修復，從某個方面確保數(shù)據(jù)準確性。從這個角度看，所有的核心任務節(jié)點，都需要配置DQC。當然，某些節(jié)點不需要了，需要及時下線，省去很多維護的成本。

除去工具檢查規(guī)范外，任務本身也需要一些保障工具。

當任務開發(fā)完成后，在提交和發(fā)布前，建議進行冒煙測試。比如校驗SQL規(guī)范、檢查權限、校驗調度方式，等等。節(jié)點發(fā)布之后，需要在運維中心，查看節(jié)點每個周期的運行情況，是否出錯、運行時間、所耗費的資源、上下游節(jié)點的運行情況，然后根據(jù)業(yè)務需求優(yōu)化調整代碼或者配置。UDF函數(shù)需要有統(tǒng)一管理，不能一個功能有多個節(jié)點。

除此之外，定期進行慢任務治理，也是必不可少的。慢任務治理不僅僅是數(shù)據(jù)質量要關心的事情，對于數(shù)據(jù)準確性而言，時效性也是一個考核因素，這一點比較關鍵。

凡此種種，其實會非常拖累開發(fā)的節(jié)奏，但往往是做的越快，錯的越多，一些繁瑣的規(guī)定，還是很有必要的。

|0x03 下游指標的使用

下游保障思路有兩點，一個是做好測試，另一個是寫好文檔和注釋，當然，如果有系統(tǒng)性介紹指標的說明，就更好了。

下游使用數(shù)據(jù)前，需要有數(shù)據(jù)測試的接入。數(shù)據(jù)測試，包括三種：自測、測試同學驗證、線上任務驗證。因為任務的細節(jié)只有自己知道，因此自測是必須且有必要的。很多時候，我們還需要相信數(shù)據(jù)測試的同學，大一點的需求需要有專業(yè)人的介入。最后是任務驗證，跑一次真實的數(shù)據(jù)，保證整個環(huán)節(jié)是通常的。至于線上任務，在上線前、修改后，都需要手動來觸發(fā)一次，確保修改是正確的，不會對第二天值班的同學造成影響。

做好測試，特指針對ADS層，即數(shù)據(jù)組合和輸出的規(guī)范。因為ADS通常開發(fā)比較迅速、邏輯比較復雜、變化比價快速，因為很多邏輯只有開發(fā)自己清楚，這種情況下，自測顯得非常重要。當然，打好與測試同學的配合，也很重要。

另外，指標體系也是必須要有的，這是一個老生常談的問題。指標體系，大體要有如下的內容：

指標定義；
度量目的；
度量方法；
度量維度；
統(tǒng)計周期；
數(shù)據(jù)來源；
數(shù)據(jù)范圍。
如果有可能的話，需要針對某個場景的分析思路，寫系統(tǒng)的介紹文檔，包括流程圖、漏斗圖、分析目的、分析指標、牽引意義等各種角度的說明。麻煩嗎？非常麻煩，但這就是看你愿意把成本花在解釋上，還是花在文檔上。

最后，要有數(shù)據(jù)可視化工具，一些很常見的問題，通過可視化工具，可以輕松發(fā)現(xiàn)，比如金額是負數(shù)，比如波動非常大，這些都有助于發(fā)現(xiàn)問題。

|0xFF 六西格瑪

出一個題目：假設一個工作需要100道工序完成，如果每一道工序的合格率都達到99%，經(jīng)過100道工序后，產品的總合格率是?

答案是，36.6%。

其實，數(shù)據(jù)開發(fā)有些時候與工廠類似，加工的工序很多，我們又無法保障每個環(huán)節(jié)100%準確。

這時候，我們用六西格瑪?shù)乃枷?，來武裝自己，就最合適不過了。企業(yè)可以用西格瑪?shù)牟煌燃壸鳛閷Ρ?，來衡量自身的流程管理水平?/p>

比如，六西格瑪背后的原理，是如果你檢測到你的項目中有多少缺陷，你就可以找出如何系統(tǒng)地減少缺陷，使你的項目盡量完美的方法。一個企業(yè)要想達到六西格瑪標準，那么它的出錯率不能超過百萬分之3.4。

如果我們利用數(shù)據(jù)規(guī)范 + 保障工具，確保每個環(huán)節(jié)出錯率，在一個相當?shù)偷乃缴?，與六西格瑪標準相當，那么我們就可以拍著胸脯說，我們的數(shù)據(jù)，是準確的。

完美通常不存在，盡可能低，已經(jīng)是一種極限了。