有時細節(jié)決定成敗漫談數(shù)據(jù)質量監(jiān)控

細節(jié) 數(shù)據(jù) 質量監(jiān)控

dantezhao | 2017-06-21 14:32

【數(shù)據(jù)猿導讀】往往那些不起眼的功能，最能毀掉你的工作成果。數(shù)據(jù)質量監(jiān)控是一個在快速發(fā)展的業(yè)務中最容易被犧牲和忽略的功能，但是它確實至關重要的。

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

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

文章結構

數(shù)據(jù)質量監(jiān)控的意義和價值就不再談了，本文主要討論下面兩個主題：

數(shù)據(jù)質量監(jiān)控要做哪些監(jiān)控內容

該怎么做

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

0x01 什么值得你監(jiān)控

我把數(shù)據(jù)質量分成三部分來理解：

監(jiān)控

告警

多數(shù)據(jù)源

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

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

細節(jié)_數(shù)據(jù)_質量監(jiān)控-1

一、監(jiān)控

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

1. 日常監(jiān)控

日常監(jiān)控中最重要的一個就是數(shù)據(jù)落地檢查，這應該是所有監(jiān)控的一個基礎，不然沒數(shù)據(jù)你玩?zhèn)€毛啊。

下面是我認為一些比較常用的監(jiān)控內容：

數(shù)據(jù)落地監(jiān)控

數(shù)據(jù)掉0監(jiān)控：實際擴展一下就是數(shù)據(jù)量閾值監(jiān)控，少于某個量就告警

重復數(shù)據(jù)監(jiān)控：很多表一定要監(jiān)控重復數(shù)據(jù)的，這點至關重要。

關鍵指標監(jiān)控

數(shù)據(jù)同比環(huán)比監(jiān)控

這是一些常用的監(jiān)控，在后面會提到，我們可以做一個規(guī)則引擎，上面提到的都坐到規(guī)則里面，哪個表需要了就陪一下就行了。

2. 數(shù)據(jù)對賬

這點主要會體現(xiàn)到實時數(shù)據(jù)上，特別是Kafka數(shù)據(jù)落地，必須要有一個監(jiān)控機制來知道我們的數(shù)據(jù)落地情況。

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

3. 性能監(jiān)控

我把這點理解為數(shù)據(jù)可用性監(jiān)控，我認為這是一個很重要的點。如果你做的數(shù)據(jù)別人用起來十分不爽，或者慢得要死根本沒法用，那做了和沒做有什么區(qū)別

感覺在性能監(jiān)控上就是有幾個點要注意：

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

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

二、告警

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

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

然后有很多的告警可以考慮一個告警報表系統(tǒng)來展示，特別像是數(shù)據(jù)量趨勢這種監(jiān)控內容，可視化的對比比較有效。

三、多數(shù)據(jù)源

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

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

0x02 怎樣監(jiān)控

數(shù)據(jù)監(jiān)控相對來講是屬于后臺系統(tǒng)，不能算是對外的業(yè)務系統(tǒng)，一般重要性可能會被挑戰(zhàn)，雖說如此，它還是值得一做的。不過可能要換一些思路來做，如何快速地實現(xiàn)、并抓住核心的功能點是值得深思的一件事。

這里不會有實現(xiàn)，只會有一些設計思路，歡迎來討論。

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

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

執(zhí)行引擎：要來執(zhí)行各種規(guī)則，同時要考慮各種數(shù)據(jù)源的差異。

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

細節(jié)_數(shù)據(jù)_質量監(jiān)控-2

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

一、規(guī)則引擎

舉幾個典型例子：數(shù)據(jù)延遲到達、數(shù)據(jù)同比環(huán)比、數(shù)據(jù)趨勢、一些定制化算法。

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

1. Sql模板

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

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

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

2. 元數(shù)據(jù)

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

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

3. 自定義模板

有很多算法不是簡單的sql就能搞定的，而且很多存儲系統(tǒng)也不是所有都支持sql。比如es這種。因此就需要一些定制化的算法來實現(xiàn)。

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

二、執(zhí)行引擎

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

1. Sql執(zhí)行

很多規(guī)則都可以通過sql來執(zhí)行的，這點在規(guī)則引擎里面提到了。

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

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

優(yōu)點：

簡單，方便實現(xiàn)

能滿足大部分的需求

缺點：

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

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

不穩(wěn)定：一些監(jiān)控會不太穩(wěn)定，比如重復數(shù)據(jù)監(jiān)控，對一些大的表來講，用presto這種，是很難出結果的，經常會掛掉，但是換成hive的話又會很慢。

那么如何解決

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

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

合理地替換執(zhí)行引擎，這個下一節(jié)會提供一種方案。

合理的任務依賴，比如說是重復數(shù)據(jù)監(jiān)控，這點必然會依賴于數(shù)據(jù)是否到達，如果數(shù)據(jù)沒達到就沒必要執(zhí)行重復數(shù)據(jù)監(jiān)控的程序。

2. 直接獲取數(shù)據(jù)量

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

Hive是有元數(shù)據(jù)管理的，它的元數(shù)據(jù)庫中是記錄Hive的所有表的記錄數(shù)的，這些記錄數(shù)可以直接用作數(shù)據(jù)量相關的監(jiān)控，比如數(shù)據(jù)掉零、數(shù)據(jù)量環(huán)比同比、數(shù)據(jù)量趨勢等。

3. 算法執(zhí)行引擎

很多算法可以通過自定義地方式實現(xiàn)，這一點實現(xiàn)起來就會比較復雜一些。

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

4. 多數(shù)據(jù)源

多數(shù)據(jù)源這一塊，在規(guī)則引擎里面需要加一些區(qū)分，因為這畢竟和元數(shù)據(jù)系統(tǒng)關聯(lián)，區(qū)分還是比較簡單。

在執(zhí)行的時候，可能要稍微分開來實現(xiàn)。不過相對來講不是很復雜。

0xFF 總結

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

這里主要是思路，具體的實現(xiàn)就不再寫了。畢竟根據(jù)業(yè)務需求，實現(xiàn)的程度也會不一樣。

來源：簡書

收藏分享

聲明：數(shù)據(jù)猿尊重媒體行業(yè)規(guī)范，相關內容都會注明來源與作者；轉載我們原創(chuàng)內容時，也請務必注明“來源：數(shù)據(jù)猿”與作者名稱，否則將會受到數(shù)據(jù)猿追責。