源寶導讀：天際數見平臺是一個數據可視化的BI平臺，定位于為高層決策提供數據可視化賦能。數據準確性是生命線，如何提前發現數據問題，快速定位和修復問題，成為我們必須攻克的難點。本文將介紹數見平臺通過架構優化，提升數據巡檢準確率和效率的技術實踐。

一、項目背景介紹

? ? 天際數見平臺是一個數據可視化的BI平臺，定位于為高層決策提供數據可視化賦能。數見平臺接入多種數據源，屏蔽數據源底層差異，統一將數據呈現給客戶。由于數據來源復雜，偶然會出現數據不一致/延遲/抖動等情況，往往是在客戶發現問題后反饋給一線，再由一線反饋給技術團隊。這種情況不僅給客戶造成平臺不穩定的錯覺，同時溝通過程涉及鏈條較長導致難以快速定位問題源頭。為此數見平臺規劃了數據質量巡檢功能，定時巡檢數據準確性/一致性/實時性，并巡檢問題的源頭，系統第一時間通知相關責任人進行解決。

? ? 由于時間緊任務重，團隊在較短時間內滿足了客戶的基本需求，但在使用過程中仍然發現了一些問題，因此決定對該功能進行系統性分析并進行優化。

二、老版本數據質量巡檢架構

? ? 上圖中ERP數據中心即為數見平臺數據源的一種（也稱之為主題包數據集），可以看出最終接入數見平臺的數據鏈路較長，數據來源較多，與之匹配的數據質量巡檢如下圖：

? ? 說明：DMP為數據可視化平臺，RunDeck 為定時任務調度系統，DMP-Proc為任務執行子系統，DMP-Celery為異步任務系統。通過上圖可以發現當DMP-Proc子系統處理完成后，通過API和DMP-Celery異步任務系統發生通信，通信完成后DMP-Celery又向DMP-Proc子系統回傳消息。

整個巡檢邏輯如下圖：

? ? 通過上圖可以發現，DMP-Proc子系統負責向各個節點分發巡檢任務，然后處于等待狀態，但是由于無法知悉各個節點需要執行的具體時間，因此此處設置了固定等待時間。這種做法實際會造成不必要的時間等待，同時在等待過程中處于協程阻塞狀態，無法接收其他巡檢任務。若此時系統因為各種原因重啟，則該次巡檢消息丟失，將永遠無法完成直至下次巡檢覆蓋本次巡檢結果。

三、為什么需要重構

? ? 通過上面的內容我們可以發現老的數據質量巡檢存在以下問題：

鏈路過長：鏈路過于復雜，涉及多個子系統，代碼業務邏輯難以理解。開發過程十分痛苦，需要在多個系統之間進行切換。涉及鏈路過多故障發生的機率也隨之大幅提升；

子系統之間形成循環通信：子系統之間形成循環通信，使架構變的復雜難以維護，需要精簡為單向通信；

系統性能時效性較低：由于使用了通道超時機制，每次檢查都需要等待固定的時間，實際業務巡檢有長有短，而非花費時間都是統一的；

系統穩定性不足：由于使用了協程常駐內存檢測通道消息，當遇到整個子系統重啟后或者發生故障，通道消息丟失，該次巡檢便無法更新為完成狀態。

四、怎樣進行優化

1. 精簡鏈路，重新設計表結構，實現每個節點只關注自身業務和節點，中間節點不再處理所有業務，每個節點只關心自身節點數據，完成巡檢即更新節點結果，DMP-Proc系統接收到巡檢消息后定時輪詢各個節點狀態，最終更新總狀態和結果。

2.通信方式優化為單向通信，子系統不再向中間節點回傳信息。由于各個節點只更改本節點數據，不會導致多節點并發更新同一份數據的問題，因此無需再向中心節點回傳結果消息。

3.監控超時機制更改為單獨的獨立協程常駐內存進行監控，不依賴于其他通道傳送信息，只依賴于數據庫中最終數據。

4.系統啟動便開始檢測所有巡檢節點，及時重啟或者異常宕機也不影響。系統每次啟動時自動檢查狀態未結束的巡檢節點，重新啟動巡檢任務。

五、優化效果

架構簡單清晰，鏈路得到精簡，各個節點只關心自己的數據，不再回傳消息；

巡檢數據更加精準，不再有中心節點，不再產生節點結果偶爾被覆蓋的情況；

系統穩定性得到較大提升，發布或dmp-proc意外宕機，都不會影響最終巡檢結果；

提升巡檢效率，一.減少通道不必要的等待時間，提升巡檢速度；

客戶滿意度提升，認可數見平臺數據質量巡檢體系。

------ END ------

作者簡介

曹同學：?研發工程師，目前負責天際-數見平臺的后臺研發工作。

也許您還想看

Go語言plugin的兩種實現方式

在明源云客，一個全新的服務會經歷什么？

云客后臺優化的“前世今生”(一)

云客后臺優化的“前世今生”(二)

回歸統計在DMP中的實戰應用

總結

以上是生活随笔為你收集整理的天际数见数据质量巡检架构优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。