我想在本文說說數據質量，ETL任務管理和監控
數倉系列：
【數倉】數據倉庫的思考（一）：https://blog.csdn.net/lsr40/article/details/105576047
【數倉】數據倉庫的建設（二）：https://blog.csdn.net/lsr40/article/details/105639190
【數倉】數據倉庫的元數據管理（三）：https://blog.csdn.net/lsr40/article/details/105654112
一、數據質量
分爲4個性質：
當然我看了不同的公司對於數據質量的性質和定義都不太一樣，大家還是要按照自己的業務來啊！
1、一致性：
-1.一個數據值與設定的值之間的誤差（是否可以接受誤差，誤差在百分之多少），舉例：B表的上游表A有1000W條數據，做了百分之20的過濾，B表中的數據有800W，那麼是合理的，又或者我只是同步數據，那麼兩張表的條數是否一樣
-2.不同的組件傳遞數據時，記錄丟失/重複/僅此一次，kafka中有三種語義，有些數據必須要確保Exactly_Once，特別是跟錢相關的數據（支付，訂單，計費）
2、完整性
-1.數據的維度/內容是否夠多夠豐富
-2.字段值缺失，又叫字段填充率，某個字段缺失的厲害，是否需要優化？
3、時效性
數據是否能夠按時生成，按時推送，數據的延遲時長是H+1，T+1或者其他/4、合理性
數據是否符合規律，是否應該唯一，有否存在巨大波動，可以比較週期，舉例：今日每個小時的流量和7天前對應小時的流量是否符合趨勢？表不同分區下的數據量是否合理，表數據的膨脹是否合理？最好是能做到支持一些自定義指標
二、數據監控
基於以上說的幾種性質，我們對於的監控指標是這樣的
數據還在數倉層面的時候，其實能夠監控的維度不多
基本上就是總條數，PV，UV，環比，數據匹配率（join的場景下，會不會丟數據），或者聚合後的頭部數據的對比
1、基於表
統計Count或者表實際佔用的磁盤空間，PV（加group條件），UV（加group條件去重）可以提供幾種默認報警規則根據平均值，上一次的值，或者7天前的值，與本次的值做比較，來設定是否報警，然後再提供自定義sql報警功能
2、基於字段
默認提供重複值校驗，字段缺失率（爲null或者空字符串的比例）打分，也可以自定義，如果是數值類型可以計算平均值，最大/最小，中位數，四分位數等指標
3、偏向產品
不同產品對數據分析就會有不同的要求，而且都不太一樣
比如留存，獲客啊，用戶行爲喜歡啊，這個就非常的繁多了，還是根據產品或者分析的經驗來做自定義吧
有些公司會統計冷熱數據，就是一張表，或者表中某段分區的數據，被使用的次數，這就需要判斷當前所使用的數據庫是否支持獲得所有歷史sql，並且對sql進行解析，不過也會有存儲過程，視圖被調用（但是實際並不知道使用了哪些表），這部分信息，我暫時只想到在存儲過程中多做一步將相關信息插入自定義的etl_log表中，再對這張表做解析
三、ETL管理和監控
ETL基本上就是幾個維度
1、ETL任務運行的情況
如果是自研框架的話，可以在每個步驟加個AOP做一些日誌的打印，如果是純hive的話，可以看yarn頁面
甚至自己調用api看：
https://www.cnblogs.com/yurunmiao/p/4224137.html（Hive SQL運行狀態監控（HiveSQLMonitor））
2、ETL任務開始，結束和消耗時間（輕量，適中，重量）
3、ETL的重要級別（是否涉及資產相關，是否是上游任務）
4、ETL成功失敗的分析（這個一般調度框架都會知道，只是要考慮如何把消息整合到一起，寫入同一個地方）
5、單獨對某些類型的ETL做實時記錄（比如spark任務，可以在跑完某一個步驟，往kafka推送一條跑數據的消息，這樣就可以相對實時的監控到一些代碼寫成的ETL的日誌情況，當長時間沒有收到該任務的消息的時候，就可以做一些報警）
有些大公司對於數據質量有疑問，還會有提供單的流程，讓對應的人解決，類似租阿里雲服務器，遇到需要人來解決的問題，提個工單，但是小公司基本上找人還是簡單的，可能就不需要這樣的功能了
最後，記得不管是表還是ETL，一定一定要存有開發人員或者開發組，這樣出了問題纔好發郵件，打電話，發短信，找對應的人解決問題！
暫時就想到這麼多吧，後續如果有其他的我會再補充！~
如果有什麼還需要補充的或者各位有疑惑的，可以給我留言，相互探討下
好累啊。。。。很疲憊，心累！