0x00 前言

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

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

文章結構

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

1. 資料質量監控要做哪些監控內容

2. 該怎麼做

3. 資料校驗

文中會涉及到資料倉庫其它的一些知識點，請參考之前的文章。

0x01 什麼值得你監控

我把資料質量分成三部分來理解：

1. 監控

2. 告警

3. 多資料來源

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

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

一、 監控

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

1. 日常監控

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

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

1. 資料落地監控

2. 資料掉0監控：實際擴充套件一下就是資料量閾值監控，少於某個量就告警

3. 重複資料監控：很多表一定要監控重複資料的，這點至關重要。

4. 關鍵指標監控

5. 資料同比環比監控

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

2. 資料對賬

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

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

3. 效能監控

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

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

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

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

二、告警

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

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

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

三、 多資料來源

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

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

0x02 怎樣監控

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

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

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

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

2. 執行引擎：要來執行各種規則，同時要考慮各種資料來源的差異。

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

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

一、 規則引擎

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

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

1. Sql模板

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

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

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

2. 元資料

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

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

3. 自定義模板

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

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

二、執行引擎

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

1. Sql執行

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

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

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

優點：

1. 簡單，方便實現

2. 能滿足大部分的需求

缺點：

1. 靈活度不夠，比如es，對sql支援太差

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

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

那麼如何解決？

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

1. 合理的任務排程，一般叢集都是能容納很多工的，合適地排程監控任務比較重要。

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

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

2. 直接獲取資料量

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

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

3. 演算法執行引擎

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

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

4. 多資料來源

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

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

0x03 資料校驗

資料校驗之前是沒在意的，現在把這一塊補進來。比較偏個人理解，暫時還沒形成完整的知識體系。主要就是說如何判斷自己的資料是正常的、可以被信任的，這一塊在資料質量中應該是十分重要的。

方法的話可以有交叉驗證、異常波動監控等，暫時先不分享了，後面自己理清楚了再說。在這裡就當提個醒。

0xFF 總結

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

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

轉載

• 作者：木東居士 |簡書 | CSDN