基於done文件的數據監控-理論

1 問題

除了像Alibaba 的 Dataworks 外，很難有另外的公司可以把數據調度，數據監控，數據血緣，元數據管理等做爲一體化的平臺了，包括我司在內的一些廠，每每把這些建設獨立開來，由不一樣的團隊負責，其中數據平臺調度功能是絕大多數公司都有的基礎平臺，可是調度的功能程度就各不一樣了，下面的問題看成拋磚引玉，指出在生產環境中常遇到的問題，若是後續有產出，後面儘可能開源一些代碼出來，貼到本博客最後面。

監控從大的層面來講有兩種，一種是監控用來攔截的，即有依賴的，一種只是用來報警和分析的。

因爲依賴接入源較多，如下問題常有發生：

1.1數據延時產出，數據產出空分區，數據質量可能有問題（條數，時間戳不對）

通常處理過程：花費時間30m+ 處理-延時問題→ 去易創上找依賴圖，確認是哪一個上游產出表沒有產出->複製表名->去數據地圖裏面找負責人->通常會拉羣跟進-->等處理完-->同步或者不一樣步/關注方→同步產出好了

1.2使用方無心識使用到錯誤數據，花費時間60m + 處理-空分區問題

處理過程： 須要對最終的產出標籤的分佈等進行質量監控，暫時沒有->若是發現之後->複製表名->去數據地圖裏面找負責人->通常會拉羣跟進-->等處理完-->同步或者不一樣步/關注方→回溯數據->通知使用方數據問題

1.3使用方先意識使用到錯誤數據

花費時間60m +數據質量問題 (條數，時間戳)→ 通常只有等標籤使用方發現才能意識到->問題復現->複製表名->去數據地圖裏面找負責人->通常會拉羣跟進-->等處理完→同步或者不一樣步/關注方→同步產出好了

1.4 數據延時產出問題

有一些例行的，必須在天天xx點產出的數據，若是沒有生成好，就要人爲去挨個找上游負責人去找問題，與1.1.3中的問題相似，都是要手動找上游。

2解決思路

基於以上問題，咱們發現這些問題，都是監控不完善，完善的監控應該是怎麼樣的呢？

在已知問題內，只要給表或者數據的標籤分佈加了監控，那麼當出現問題時候，能夠自動通知到數據使用方，數據發佈方，當問題拋出來給某人之後，他能夠選擇，將這次報警置爲處理中，後續在xx時間內處理好，若是處理很差繼續報警，可是報警範圍可能更大，好比給負責人經理電話，郵件，短信，拉羣艾特等。這樣有另一個好處是數據的sla在必定程度上保證了，能夠事後來查問題，或者在將來的「某些特殊場合」使用到。

需求如上，那麼設計

監控獨立於調度系統，與調度系統惟一的交互是done文件，調度在done文件產出後才繼續執行。

1.2.0 爲何基於done文件呢？

任務依賴，對於任務依賴來講，爲了對數據源的質量檢測，就要對每一個任務進行配置任務檢測依賴，會有兩個問題，其一是任務檢測腳本會更分散，其二，檢測邏輯不少是相似的，也會形成腳本冗餘

表依賴，檢測位置是表的分區，那麼當數據質量檢測經過後，生成一個表的分區，最終就是相似 dt=xxxx/rule=check_t1_count.done 相似這樣 經過add partition 來添加

文件依賴，跟表依賴相似之處就是生成一個done文件，區別之處在於能夠直接經過服務來調用生成done，較方便因此選文件依賴

1.2.1 done文件由一個惟一的表名+任務id.done組成

1.2.2 單點報警 + 多層處理報警，若是A表怎麼樣，B表怎麼樣，就報警給誰，具體有產出延時，失敗報警

3設計開發

1.任務信息

2.報警信息

3.表信息

4.監控邏輯表

5.監控與報警關聯表

6.監控與表信息與任務信息的關聯表

基於SpringBoot的後臺系統

主要開發，等後續再分享，😄😄😄😄😄😄😄😄😄😄😄😄😄

4將來展望

加入血緣的監控和報警

吳邪，小三爺，混跡於後臺，大數據，人工智能領域的小菜鳥。
更多請關注