問(wèn)題描述

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

以下是原文：

上游，會(huì)遇到根源性問(wèn)題，比如客戶端在數(shù)據(jù)上報(bào)時(shí)就傳錯(cuò)的情況，比如手抖把下單時(shí)間不小心上報(bào)成了用戶點(diǎn)擊商品詳情的時(shí)間。

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

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

關(guān)于這三個(gè)典型問(wèn)題，我們分開來(lái)看。

01 上游數(shù)據(jù)的保障

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

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

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

其次，我們得有一套合理的埋點(diǎn)規(guī)范，不論是SPM，還是其他一些自定義的方法，合理的規(guī)范不僅能夠減少上下游的信息誤差，同時(shí)也會(huì)避免因?yàn)槌镀?dǎo)致的一些數(shù)據(jù)問(wèn)題，問(wèn)題中的上報(bào)錯(cuò)誤也會(huì)少很多，至少我們能夠加一層規(guī)范校驗(yàn)來(lái)檢查出部分的問(wèn)題，這還是比較關(guān)鍵的。

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

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

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

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

如果這個(gè)階段發(fā)現(xiàn)問(wèn)題，建議直接阻斷，因?yàn)槿绻掠魏芏嗟脑挘⑿潞徒忉尩某杀具€是很高，比如晚一點(diǎn)產(chǎn)出，確保沒問(wèn)題。

02 中游指標(biāo)的計(jì)算

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

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

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

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

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

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

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

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

03 下游指標(biāo)的使用

下游保障思路有兩點(diǎn)，一個(gè)是做好測(cè)試，另一個(gè)是寫好文檔和注釋，當(dāng)然，如果有系統(tǒng)性介紹指標(biāo)的說(shuō)明，就更好了。

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

做好測(cè)試，特指針對(duì)ADS層，即數(shù)據(jù)組合和輸出的規(guī)范。因?yàn)锳DS通常開發(fā)比較迅速、邏輯比較復(fù)雜、變化比價(jià)快速，因?yàn)楹芏噙壿嬛挥虚_發(fā)自己清楚，這種情況下，自測(cè)顯得非常重要。當(dāng)然，打好與測(cè)試同學(xué)的配合，也很重要。

另外，指標(biāo)體系也是必須要有的，這是一個(gè)老生常談的問(wèn)題。指標(biāo)體系，大體要有如下的內(nèi)容：

指標(biāo)定義；

度量目的；

度量方法；

度量維度；

統(tǒng)計(jì)周期；

數(shù)據(jù)來(lái)源；

數(shù)據(jù)范圍。

如果有可能的話，需要針對(duì)某個(gè)場(chǎng)景的分析思路，寫系統(tǒng)的介紹文檔，包括流程圖、漏斗圖、分析目的、分析指標(biāo)、牽引意義等各種角度的說(shuō)明。麻煩嗎？非常麻煩，但這就是看你愿意把成本花在解釋上，還是花在文檔上。

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

 六西格瑪

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

答案是，36.6%。

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

這時(shí)候，我們用六西格瑪?shù)乃枷?，?lái)武裝自己，就最合適不過(guò)了。企業(yè)可以用西格瑪?shù)牟煌燃?jí)作為對(duì)比，來(lái)衡量自身的流程管理水平。

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

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

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