關於數據質量監控的那些事

0x00 前言

往往那些不起眼的功能，最能毀掉你的工作成果。

本篇分享一些和數據質量監控相關的內容。數據質量監控是一個在快速發展的業務中最容易被犧牲和忽略的功能，但是它確實至關重要的。

假設你做了100個業務，一旦有其中一個業務在某個時間段出現了數據異常，這個異常還是由業務方發現的而不是你，根據我的經驗是，它帶來的負面影響會超過你之前做的100個業務帶來的正面影響。

文章結構

數據質量監控的意義和價值就不再談了，本文主要討論下面兩個主題：

數據質量監控要做哪些監控內容

該怎麼做

文中會涉及到數據倉庫其它的一些知識點，請參考：http://dantezhao.com/

0x01 什麼值得你監控

我把數據質量分成三部分來理解：

監控

告警

多數據源

重點在監控，這點會展開來講，多數據源這一塊是因為在大數據場景下，我們有太多的開源組件來選擇，很多組件的數據都需要監控，而且每個都不一樣，如果統一地來監控是個重要的話題。

如下圖，我先列一個大致的思維導圖，然後詳細講每一部分。

一、 監控

監控這一塊比較大。整體來講，我會把它分為這幾塊：日常監控、數據對賬、性能監控。下面分開來講。

1.日常監控

日常監控中最重要的一個就是數據落地檢查，這應該是所有監控的一個基礎，不然沒數據你玩個毛啊。

下面是我認為一些比較常用的監控內容：

數據落地監控

數據掉0監控：實際擴展一下就是數據量閾值監控，少於某個量就告警

重複數據監控：很多表一定要監控重複數據的，這點至關重要。

關鍵指標監控

數據同比環比監控

這是一些常用的監控，在後面會提到，我們可以做一個規則引擎，上面提到的都坐到規則裡面，哪個表需要了就陪一下就行了。

2. 數據對賬

這點主要會體現到實時數據上，特別是Kafka數據落地，必須要有一個監控機制來知道我們的數據落地情況。

當然離線數據同樣需要數據對賬，對賬方法有很多，比如可以和業務庫來對比。

3. 性能監控

我把這點理解為數據可用性監控，我認為這是一個很重要的點。 如果你做的數據別人用起來十分不爽，或者慢得要死根本沒法用，那做了和沒做有什麼區別?

感覺在性能監控上就是有幾個點要注意：

查詢性能，比如es的某個索引，在不同時間段的查詢響應速度，同理presto、hive、kylin這些的查詢都需要注意一下，這點可以通過任務監控來觀察。

數據讀寫影響，機器故障影響，這點平常不太關注，不過像es這種，在寫入數據的時候其實會影響讀數據的，需要監控一下，並做相應調整。

二、告警

告警就不用說了，微信、簡訊和電話都很有必要。

定期的郵件匯總告警也很有必要。

然後有很多的告警可以考慮一個告警報表系統來展示，特別像是數據量趨勢這種監控內容，可視化的對比比較有效。

三、 多數據源

在目前的大數據場景下，各種開源組件引入的十分多，而且會有新的組件不停地引入，因此要考慮到對不同組件的數據監控。

目前筆者接觸比較多的會有Hive(presto、spark sql)、Mysql、ES、Redis、Kylin(主要是構建的cube)這些常用的，但是不能排除圖資料庫(neo4j、orientdb)和druid這些組件引入的可能性。

0x02 怎樣監控

數據監控相對來講是屬於後台系統，不能算是對外的業務系統，一般重要性可能會被挑戰，雖說如此，它還是值得一做的。 不過可能要換一些思路來做，如何快速地實現、並抓住核心的功能點是值得深思的一件事。

這裡不會有實現，只會有一些設計思路，歡迎來討論。

如圖是一個整體的構思，我先分析幾個個人認識比較重要的點。後面會詳細地來分析。

規則引擎：來定義各種告警規則，可能是一條sql模板，也可能是一些具體的演算法。

執行引擎：要來執行各種規則，同時要考慮各種數據源的差異。

元數據系統：數據質量監控本來也算是元數據系統的一部分，我們這分開來講，但是無論如何，在配置表的告警信息時，還是要和元數據系統結合的。

下面會分開來分析一下這幾個組件。

一、 規則引擎

舉幾個典型例子：數據延遲到達、數據同比環比、數據趨勢、一些定製化演算法。

這塊的設計可以很靈活，也可以臨時開發一個簡單的。這裡提幾個點。

1.Sql模板

在大多數存儲引擎中，通過Sql使用的數據(比如Hive、Mysql)會是比較重要的一種數據，這種數據我們可以考慮用Sql模板。

我們會有一張表或者一些配置文件來定義我們的規則。簡單來講，比如說數據同比環比，我們可以寫一個presto的sql模板，來和歷史數據進行對比，這種sql很簡單，自己寫好模板就行。

這種模板最簡單，也最快，我相信能解決大部分問題。

2. 元數據

很多資料庫都是有元數據管理的，比如Hive，它的表的行數都是在元資料庫中有存放的，我們可以直接通過Hive的元數據來抓取表的每天的數據量的。

注意： 這點十分重要，它能節省我們大部分的工作，而且比較穩定，但是能滿足的功能比較少。需要結合其它來使用。

3. 自定義模板

有很多演算法不是簡單的sql就能搞定的，而且很多存儲系統也不是所有都支持sql。比如es這種。因此就需要一些定製化的演算法來實現。

這方面的主要工作量應該是在執行引擎上，但是在規則引擎應該有設計到。

二、執行引擎

這塊應該是比較重要的。 實現起來可以很簡單，也可以很複雜。下面大概聊一下。

1.Sql執行

很多規則都可以通過sql來執行的，這點在規則引擎裡面提到了。

其實我很推薦，剛開始的比較粗糙的監控都可以這樣來做。 我們提前配置好大部分的sql模板，然後需要監控哪張表了就在這張表配置一下就行。

具體的執行引擎的話可以考慮presto或者spark sql，特別大的任務可以考慮hive。

優點：

簡單，方便實現

能滿足大部分的需求

缺點：

靈活度不夠，比如es，對sql支持太差

速度慢：很多sql執行起來會比較慢，特別是使用hive引擎的時候，會巨慢。

不穩定：一些監控會不太穩定，比如重複數據監控，對一些大的表來講，用presto這種，是很難出結果的，經常會掛掉，但是換成hive的話又會很慢。

那麼如何解決?

嗯，解決的話，我只有下面幾個思路：

合理的任務調度，一般集群都是能容納很多任務的，合適地調度監控任務比較重要。

合理地替換執行引擎，這個下一節會提供一種方案。

合理的任務依賴，比如說是重複數據監控，這點必然會依賴於數據是否到達，如果數據沒達到就沒必要執行重複數據監控的程序。

2. 直接獲取數據量

前面提到了Sql執行的一個執行效率問題，我們這節提供一個優化的方法。因為Hive目前來講是十分重要的一種引擎了，所以單說Hive。

Hive是有元數據管理的，它的元資料庫中是記錄Hive的所有表的記錄數的，這些記錄數可以直接用作數據量相關的監控，比如數據掉零、數據量環比同比、數據量趨勢等。

3. 演算法執行引擎

很多演算法可以通過自定義地方式實現，這一點實現起來就會比較複雜一些。

因為定製化比較強，在設計這一塊的話需要一個比較靈活的架構，這裡不再展開來講，因為在常見的數據領域裡面，前兩點已經能滿足很多需求了。

4. 多數據源

多數據源這一塊，在規則引擎裡面需要加一些區分，因為這畢竟和元數據系統關聯，區分還是比較簡單。

在執行的時候，可能要稍微分開來實現。不過相對來講不是很複雜。

0xFF 總結

本篇主要分享了一些和數據質量監控相關的內容，有一些泛泛而談的感覺，但是理清思路後很多實現起來也是很簡單的， 想做個簡單能用的出來，用python半天就能搞定。

這裡主要是思路，具體的實現就不再寫了。畢竟根據業務需求，實現的程度也會不一樣。

End

你投稿，我送書

閱讀排行榜/精華推薦

1

入門學習

2

進階修鍊

3

數據源爬取/收集

4

乾貨教程

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！