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

一、項目背景介紹

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

? ? 由于時間緊任務(wù)重，團隊在較短時間內(nèi)滿足了客戶的基本需求，但在使用過程中仍然發(fā)現(xiàn)了一些問題，因此決定對該功能進行系統(tǒng)性分析并進行優(yōu)化。

二、老版本數(shù)據(jù)質(zhì)量巡檢架構(gòu)

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

? ? 說明：DMP為數(shù)據(jù)可視化平臺，RunDeck 為定時任務(wù)調(diào)度系統(tǒng)，DMP-Proc為任務(wù)執(zhí)行子系統(tǒng)，DMP-Celery為異步任務(wù)系統(tǒng)。通過上圖可以發(fā)現(xiàn)當(dāng)DMP-Proc子系統(tǒng)處理完成后，通過API和DMP-Celery異步任務(wù)系統(tǒng)發(fā)生通信，通信完成后DMP-Celery又向DMP-Proc子系統(tǒng)回傳消息。

整個巡檢邏輯如下圖：

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

三、為什么需要重構(gòu)

? ? 通過上面的內(nèi)容我們可以發(fā)現(xiàn)老的數(shù)據(jù)質(zhì)量巡檢存在以下問題：

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

子系統(tǒng)之間形成循環(huán)通信：子系統(tǒng)之間形成循環(huán)通信，使架構(gòu)變的復(fù)雜難以維護，需要精簡為單向通信；

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

系統(tǒng)穩(wěn)定性不足：由于使用了協(xié)程常駐內(nèi)存檢測通道消息，當(dāng)遇到整個子系統(tǒng)重啟后或者發(fā)生故障，通道消息丟失，該次巡檢便無法更新為完成狀態(tài)。

四、怎樣進行優(yōu)化

1. 精簡鏈路，重新設(shè)計表結(jié)構(gòu)，實現(xiàn)每個節(jié)點只關(guān)注自身業(yè)務(wù)和節(jié)點，中間節(jié)點不再處理所有業(yè)務(wù)，每個節(jié)點只關(guān)心自身節(jié)點數(shù)據(jù)，完成巡檢即更新節(jié)點結(jié)果，DMP-Proc系統(tǒng)接收到巡檢消息后定時輪詢各個節(jié)點狀態(tài)，最終更新總狀態(tài)和結(jié)果。

2.通信方式優(yōu)化為單向通信，子系統(tǒng)不再向中間節(jié)點回傳信息。由于各個節(jié)點只更改本節(jié)點數(shù)據(jù)，不會導(dǎo)致多節(jié)點并發(fā)更新同一份數(shù)據(jù)的問題，因此無需再向中心節(jié)點回傳結(jié)果消息。

3.監(jiān)控超時機制更改為單獨的獨立協(xié)程常駐內(nèi)存進行監(jiān)控，不依賴于其他通道傳送信息，只依賴于數(shù)據(jù)庫中最終數(shù)據(jù)。

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

五、優(yōu)化效果

架構(gòu)簡單清晰，鏈路得到精簡，各個節(jié)點只關(guān)心自己的數(shù)據(jù)，不再回傳消息；

巡檢數(shù)據(jù)更加精準(zhǔn)，不再有中心節(jié)點，不再產(chǎn)生節(jié)點結(jié)果偶爾被覆蓋的情況；

系統(tǒng)穩(wěn)定性得到較大提升，發(fā)布或dmp-proc意外宕機，都不會影響最終巡檢結(jié)果；

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

客戶滿意度提升，認可數(shù)見平臺數(shù)據(jù)質(zhì)量巡檢體系。

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

作者簡介

曹同學(xué)：?研發(fā)工程師，目前負責(zé)天際-數(shù)見平臺的后臺研發(fā)工作。

也許您還想看

Go語言plugin的兩種實現(xiàn)方式

在明源云客，一個全新的服務(wù)會經(jīng)歷什么？

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

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

回歸統(tǒng)計在DMP中的實戰(zhàn)應(yīng)用

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。