往往那些不起眼的功能，最能毀掉你的工作成果。本篇分享一些和資料質量監控相關的內容。資料質量監控是乙個在快速發展的業務中最容易被犧牲和忽略的功能，但是它確實至關重要的。
假設你做了100個業務，一旦有其中乙個業務在某個時間段出現了資料異常，這個異常還是由業務方發現的而不是你，根據我的經驗是，它帶來的負面影響會超過你之前做的100個業務帶來的正面影響。
資料質量監控要做哪些監控內容
該怎麼做
文中會涉及到資料倉儲其它的一些知識點，請參考：
我把資料質量分成三部分來理解：
監控告警
多資料來源
重點在監控，這點會展開來講，多資料來源這一塊是因為在大資料場景下，我們有太多的開源元件來選擇，很多元件的資料都需要監控，而且每個都不一樣，如果統一地來監控是個重要的話題。
如下圖，我先列乙個大致的思維導圖，然後詳細講每一部分。
監控這一塊比較大。整體來講，我會把它分為這幾塊：日常監控、資料對賬、效能監控。下面分開來講。
日常監控中最重要的乙個就是資料落地檢查，這應該是所有監控的乙個基礎，不然沒資料你玩個毛啊。
下面是我認為一些比較常用的監控內容：
資料落地監控
資料掉0監控：實際擴充套件一下就是資料量閾值監控，少於某個量就告警
重複資料監控：很多表一定要監控重複資料的，這點至關重要。
關鍵指標監控
資料同比環比監控
這是一些常用的監控，在後面會提到，我們可以做乙個規則引擎，上面提到的都坐到規則裡面，哪個表需要了就陪一下就行了。
這點主要會體現到實時資料上，特別是kafka資料落地，必須要有乙個監控機制來知道我們的資料落地情況。
當然離線資料同樣需要資料對賬，對賬方法有很多，比如可以和業務庫來對比。
我把這點理解為資料可用性監控，我認為這是乙個很重要的點。 如果你做的資料別人用起來十分不爽，或者慢得要死根本沒法用，那做了和沒做有什麼區別？
感覺在效能監控上就是有幾個點要注意：
查詢效能，比如es的某個索引，在不同時間段的查詢響應速度，同理presto、hive、kylin這些的查詢都需要注意一下，這點可以通過任務監控來觀察。
資料讀寫影響，機器故障影響，這點平常不太關注，不過像es這種，在寫入資料的時候其實會影響讀資料的，需要監控一下，並做相應調整。
定期的郵件彙總告警也很有必要。
然後有很多的告警可以考慮乙個告警報表系統來展示，特別像是資料量趨勢這種監控內容，視覺化的對比比較有效。
在目前的大資料場景下，各種開源元件引入的十分多，而且會有新的元件不停地引入，因此要考慮到對不同元件的資料監控。
目前筆者接觸比較多的會有hive（presto、spark sql）、mysql、es、redis、kylin（主要是構建的cube）這些常用的，但是不能排除圖資料庫（neo4j、orientdb）和druid這些元件引入的可能性。
資料監控相對來講是屬於後台系統，不能算是對外的業務系統，一般重要性可能會被挑戰，雖說如此，它還是值得一做的。 不過可能要換一些思路來做，如何快速地實現、並抓住核心的功能點是值得深思的一件事。
這裡不會有實現，只會有一些設計思路，歡迎來討論。如圖是乙個整體的構思，我先分析幾個個人認識比較重要的點。後面會詳細地來分析。
規則引擎：來定義各種告警規則，可能是一條sql模板，也可能是一些具體的演算法。
執行引擎：要來執行各種規則，同時要考慮各種資料來源的差異。
元資料系統：資料質量監控本來也算是元資料系統的一部分，我們這分開來講，但是無論如何，在配置表的告警資訊時，還是要和元資料系統結合的。
下面會分開來分析一下這幾個元件。
舉幾個典型例子：資料延遲到達、資料同比環比、資料趨勢、一些定製化演算法。
這塊的設計可以很靈活，也可以臨時開發乙個簡單的。這裡提幾個點。
在大多數儲存引擎中，通過sql使用的資料（比如hive、mysql）會是比較重要的一種資料，這種資料我們可以考慮用sql模板。
我們會有一張表或者一些配置檔案來定義我們的規則。簡單來講，比如說資料同比環比，我們可以寫乙個presto的sql模板，來和歷史資料進行對比，這種sql很簡單，自己寫好模板就行。
這種模板最簡單，也最快，我相信能解決大部分問題。
很多資料庫都是有元資料管理的，比如hive，它的表的行數都是在元資料庫中有存放的，我們可以直接通過hive的元資料來抓取表的每天的資料量的。
**注意：**這點十分重要，它能節省我們大部分的工作，而且比較穩定，但是能滿足的功能比較少。需要結合其它來使用。
有很多演算法不是簡單的sql就能搞定的，而且很多儲存系統也不是所有都支援sql。比如es這種。因此就需要一些定製化的演算法來實現。
這方面的主要工作量應該是在執行引擎上，但是在規則引擎應該有設計到。
這塊應該是比較重要的。 實現起來可以很簡單，也可以很複雜。下面大概聊一下。
很多規則都可以通過sql來執行的，這點在規則引擎裡面提到了。
其實我很推薦，剛開始的比較粗糙的監控都可以這樣來做。我們提前配置好大部分的sql模板，然後需要監控哪張表了就在這張表配置一下就行。
具體的執行引擎的話可以考慮presto或者spark sql，特別大的任務可以考慮hive。
優點：簡單，方便實現
能滿足大部分的需求
缺點：靈活度不夠，比如es，對sql支援太差
速度慢：很多sql執行起來會比較慢，特別是使用hive引擎的時候，會巨慢。
不穩定：一些監控會不太穩定，比如重複資料監控，對一些大的表來講，用presto這種，是很難出結果的，經常會掛掉，但是換成hive的話又會很慢。
那麼如何解決？
嗯，解決的話，我只有下面幾個思路：
合理的任務排程，一般集群都是能容納很多任務的，合適地排程監控任務比較重要。
合理地替換執行引擎，這個下一節會提供一種方案。
合理的任務依賴，比如說是重複資料監控，這點必然會依賴於資料是否到達，如果資料沒達到就沒必要執行重複資料監控的程式。前面提到了sql執行的乙個執行效率問題，我們這節提供乙個優化的方法。因為hive目前來講是十分重要的一種引擎了，所以單說hive。
hive是有元資料管理的，它的元資料庫中是記錄hive的所有表的記錄數的，這些記錄數可以直接用作資料量相關的監控，比如資料掉零、資料量環比同比、資料量趨勢等。
很多演算法可以通過自定義地方式實現，這一點實現起來就會比較複雜一些。
因為定製化比較強，在設計這一塊的話需要乙個比較靈活的架構，這裡不再展開來講，因為在常見的資料領域裡面，前兩點已經能滿足很多需求了。
多資料來源這一塊，在規則引擎裡面需要加一些區分，因為這畢竟和元資料系統關聯，區分還是比較簡單。
在執行的時候，可能要稍微分開來實現。不過相對來講不是很複雜。
本篇主要分享了一些和資料質量監控相關的內容，有一些泛泛而談的感覺，但是理清思路後很多實現起來也是很簡單的， 想做個簡單能用的出來，用python半天就能搞定。
這裡主要是思路，具體的實現就不再寫了。畢竟根據業務需求，實現的程度也會不一樣。
資料質量監控
資料質量監控 原創 木東居士 木東居士 4天前 0x00 概述 隨著大資料時代的帶來，資料的應用也日趨繁茂，越來越多的應用和服務都基於資料而建立，資料的重要性不言而喻。而且，資料質量是資料分析和資料探勘結論有效性和準確性的基礎，也是這一切的資料驅動決策的前提！如何保障資料質量，確保資料可用性是每一位...
資料質量監控筆記
二 資料質量影響因素 三 資料質量問題型別 前言影響資料質量的因素是什麼，資料質量問題型別有哪些，如何設計資料質量監控流程目標解決常見資料質量監控需求一 資料質量相關概念 1 什麼是資料質量 1 資料質量顧名思義就是資料的質量 2 資料質量是資料分析結論有效性和準確性的基礎，也是最重要的前提和保障 ...
資料倉儲 資料質量監控
為什麼要做資料質量管理？提前發現問題，然後去解決，讓資料更好的服務於業務。什麼時候開始做呢？搭建數倉過程中，就要開始做 資料質量管理。要先行 不能後做。資料質量是資料驅動決策的前提 資料質量需要關注的四個點 即完整性 準確性 一致性和及時性 完整性是指資料的記錄和資訊是否完整。一般會在資料接入的時候...