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未來展望
加入血緣的監控和報警
吳邪，小三爺，混跡于后臺，大資料，人工智能領域的小菜鳥，
更多請關注
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/230925.html
標籤：其他
下一篇：演算法-雙指標問題解決思路