數倉 資料倉儲的資料質量任務監控（四）

我想在本文說說資料質量，etl任務管理和監控

數倉系列：

【數倉】資料倉儲的思考（一）：

【數倉】資料倉儲的建設（二）：

【數倉】資料倉儲的元資料管理（三）：

分為4個性質：

當然我看了不同的公司對於資料質量的性質和定義都不太一樣，大家還是要按照自己的業務來啊！

-2.不同的元件傳遞資料時，記錄丟失/重複/僅此一次，kafka中有三種語義，有些資料必須要確保exactly_once，特別是跟錢相關的資料（支付，訂單，計費）

-1.資料的維度/內容是否夠多夠豐富

-2.字段值缺失，又叫字段填充率，某個字段缺失的厲害，是否需要優化？

資料是否能夠按時生成，按時推送，資料的延遲時長是h+1，t+1或者其他/4、合理性

資料是否符合規律，是否應該唯一，有否存在巨大波動，可以比較週期，舉例：今日每個小時的流量和7天前對應小時的流量是否符合趨勢？表不同分割槽下的資料量是否合理，表資料的膨脹是否合理？最好是能做到支援一些自定義指標

基於以上說的幾種性質，我們對於的監控指標是這樣的

資料還在數倉層面的時候，其實能夠監控的維度不多

基本上就是總條數，pv，uv，環比，資料匹配率（join的場景下，會不會丟資料），或者聚合後的頭部資料的對比

統計count或者表實際占用的磁碟空間，pv（加group條件），uv（加group條件去重）可以提供幾種預設報警規則根據平均值，上一次的值，或者7天前的值，與本次的值做比較，來設定是否報警，然後再提供自定義sql報警功能

預設提供重複值校驗，字段缺失率（為null或者空字串的比例）打分，也可以自定義，如果是數值型別可以計算平均值，最大/最小，中位數，四分位數等指標

不同產品對資料分析就會有不同的要求，而且都不太一樣

比如留存，獲客啊，使用者行為喜歡啊，這個就非常的繁多了，還是根據產品或者分析的經驗來做自定義吧

有些公司會統計冷熱資料，就是一張表，或者表中某段分割槽的資料，被使用的次數，這就需要判斷當前所使用的資料庫是否支援獲得所有歷史sql，並且對sql進行解析，不過也會有儲存過程，檢視被呼叫（但是實際並不知道使用了哪些表），這部分資訊，我暫時只想到在儲存過程中多做一步將相關資訊插入自定義的etl_log表中，再對這張表做解析

1、etl任務執行的情況

如果是自研框架的話，可以在每個步驟加個aop做一些日誌的列印，如果是純hive的話，可以看yarn頁面

甚至自己呼叫api看：

sql執行狀態監控（hivesqlmonitor））

3、etl的重要級別（是否涉及資產相關，是否是上游任務）

4、etl成功失敗的分析（這個一般排程框架都會知道，只是要考慮如何把訊息整合到一起，寫入同乙個地方）

5、單獨對某些型別的etl做實時記錄（比如spark任務，可以在跑完某乙個步驟，往kafka推送一條跑資料的訊息，這樣就可以相對實時的監控到一些**寫成的etl的日誌情況，當長時間沒有收到該任務的訊息的時候，就可以做一些報警）

有些大公司對於資料質量有疑問，還會有提供單的流程，讓對應的人解決，類似租阿里雲伺服器，遇到需要人來解決的問題，提個工單，但是小公司基本上找人還是簡單的，可能就不需要這樣的功能了

好累啊。。。。很疲憊，心累！

資料倉儲 資料質量監控

為什麼要做資料質量管理？提前發現問題，然後去解決，讓資料更好的服務於業務。什麼時候開始做呢？搭建數倉過程中，就要開始做 資料質量管理。要先行 不能後做。資料質量是資料驅動決策的前提 資料質量需要關注的四個點 即完整性 準確性 一致性和及時性 完整性是指資料的記錄和資訊是否完整。一般會在資料接入的時候...

資料倉儲 數倉分層 01

資料倉儲，資料倉儲是面向主題的 subject oriented 整合的 integrated 非易失的 non volatile 和時變的 time variant 資料集合，用以支援管理決策。每個資料倉儲面向分析的主題都是一樣的 資料倉儲需要分析某乙個主題的資料結果，需要整合各個其他方面的資料 ...

資料倉儲與數倉建模

資料倉儲，英文名為data warehouse，簡寫為dw或dwh。資料倉儲，是乙個面向主題的 整合的 隨時間變化的 但資訊本身相對穩定的資料集合，用於對管理決策過程的支援1。它是單個資料儲存，出於分析性報告和決策支援目的而建立。為需要業務智慧型的企業，提供指導業務流程改進 監視時間 成本 質量以及...