ETL中常見數(shù)據(jù)質(zhì)量監(jiān)控方法總結(jié)(建議收藏)
數(shù)據(jù)質(zhì)量監(jiān)控背景
當我們把數(shù)據(jù)導入數(shù)據(jù)倉庫時，ETL中的每個步驟中都可能會遇到數(shù)據(jù)質(zhì)量錯誤。比如與源系統(tǒng)的連接錯誤，抽取數(shù)據(jù)可能會失敗。由于記錄類型沖突，數(shù)據(jù)轉(zhuǎn)換可能會失敗。即使的ETL任務成功，提取的記錄中也會出現(xiàn)異常值，導致后續(xù)過程報錯。
那么如何主動捕獲這些錯誤，并確保數(shù)據(jù)倉庫中的數(shù)據(jù)質(zhì)量？
接下來，我們來總結(jié)5條規(guī)則，在做ETL的過程中，使用這些規(guī)則來確保數(shù)據(jù)倉庫中的數(shù)據(jù)質(zhì)量。
數(shù)據(jù)質(zhì)量監(jiān)控方法
1、校驗每天的記錄數(shù)
分析師遇到的最常見數(shù)據(jù)異常是其報告的輸出突然降至0。
我們通常會發(fā)現(xiàn)最后的罪魁禍首是當天沒有將新記錄添加到相應的表中。
一種簡單的檢查方法是確保每天一個表中的新記錄數(shù)>0。
2、NULL和0值校驗
分析師常遇到的第二個問題是NULL或0值。我們要保證每天增量數(shù)據(jù)中的NULL或0值不能超過新增數(shù)據(jù)的99%。要檢查這一點，只需將一個循環(huán)腳本設(shè)置為每天用NULL或0計數(shù)一個表中的新記錄數(shù)。如果看到記錄數(shù)急劇增加，則可能存在轉(zhuǎn)換錯誤或源業(yè)務系統(tǒng)就存在異常。
3、每天新增的記錄數(shù)波動范圍
某一天你發(fā)現(xiàn)數(shù)據(jù)量出現(xiàn)大幅增長或下降，而規(guī)則1和2都已校驗通過。這種波動可能是正常的，比如電商行業(yè)某天的大促活動，或者社交軟件的營銷活動。但是也可能這就是異常的，是因為從源系統(tǒng)抽取了重復的記錄。所以針對此種情況，我們也要制定數(shù)據(jù)質(zhì)量規(guī)則，檢查這些波動何時發(fā)生，并主動進行診斷。比如自動執(zhí)行的一個簡單的SQL過程，每天檢查COUNT個新記錄是否在7天跟蹤平均值的誤差范圍內(nèi)。閾值和誤差范圍可能因公司和產(chǎn)品而異，經(jīng)驗值一般是加減25％。當然，你可也可以直接和前一天的數(shù)據(jù)對比，增量不超過前一天的1倍。
4、重復記錄數(shù)據(jù)校驗
不管是電商系統(tǒng)或者是社交系統(tǒng)或者是物聯(lián)網(wǎng)設(shè)備上報的數(shù)據(jù)，正常情況下都不會出現(xiàn)兩條完全一樣的記錄（包括ID，時間，值都一樣）。筆者曾遇到一個終端上報的兩條數(shù)據(jù)完全一樣的場景，導致我在做時間分段時候，劃分不正確。所以，對數(shù)據(jù)值唯一性校驗是有必要的。
5、數(shù)據(jù)時間校驗
一般我們業(yè)務系統(tǒng)的數(shù)據(jù)都是帶有時間戳的，這個時間戳肯定比當前的時間要小。但是由于采集數(shù)據(jù)設(shè)備異常（業(yè)務系統(tǒng)異常），我們會碰到“未來時間”的數(shù)據(jù)，那如果我們以時間作為分區(qū)，后期可能就會出現(xiàn)異常的分析結(jié)果。當然，如果你的公司業(yè)務是跨國的，你需要考慮時差因素。
總結(jié)
這些只是我們維護數(shù)據(jù)倉庫時遇到的最常見的5個錯誤。可以將上述規(guī)則作一個checklist，做成任務每天例行檢查。出現(xiàn)以上問題是對ETL任務進行告警，并人工干預。每周或者沒有匯總質(zhì)量報告，和團隊小伙伴或者業(yè)務側(cè)一起制定解決方案，不斷完善監(jiān)控體系，只有這樣才能保證我們的業(yè)務分析結(jié)果是準確的，才能指導公司做出正確的決策。
當然，對于企業(yè)級數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)，這些事遠遠不夠的，不同公司面臨的困難不一樣，方法也不一樣，可以參考業(yè)務的一些建議，制定自己的一套數(shù)據(jù)質(zhì)量監(jiān)控方案，這樣才能更好的落地實施。
--end--
添加好友，備注【交流群】拉你到學習路線和資源豐富的交流群