OPPO大數(shù)據(jù)診斷平臺(tái)“羅盤(pán)”正式開(kāi)源

一、背景

OPPO大數(shù)據(jù)平臺(tái)目前有 20+個(gè)服務(wù)組件,數(shù)據(jù)量超 1EB,離線任務(wù)數(shù)近百萬(wàn),實(shí)時(shí)任務(wù)數(shù)千,數(shù)據(jù)開(kāi)發(fā)分析師超千人。這也帶來(lái)了系統(tǒng)復(fù)雜度的問(wèn)題,一方面是用戶(hù)經(jīng)常對(duì)自己的任務(wù)運(yùn)行狀況“摸不著頭腦”,不管是性能問(wèn)題,還是參數(shù)配置問(wèn)題,甚至是一些常見(jiàn)的權(quán)限報(bào)錯(cuò)問(wèn)題,都需要咨詢(xún)平臺(tái)給出具體的解決方案;另一方面是平臺(tái)面對(duì)各類(lèi)繁雜任務(wù),運(yùn)維人員經(jīng)常需要對(duì)任務(wù)故障定位和排除,由于任務(wù)鏈路長(zhǎng),組件日志多,運(yùn)維壓力大。因此急需對(duì)任務(wù)進(jìn)行實(shí)時(shí)監(jiān)控和診斷,不僅要能夠幫助用戶(hù)快速定位異常問(wèn)題,還需給出具體的建議和優(yōu)化方案,同時(shí)還能治理各類(lèi)“僵尸”和不合理任務(wù),從而達(dá)到降本增效的目的。據(jù)調(diào)研,目前業(yè)界尚無(wú)成熟的開(kāi)源任務(wù)診斷平臺(tái)。為此我們開(kāi)發(fā)了大數(shù)據(jù)診斷平臺(tái),通過(guò)診斷平臺(tái)周優(yōu)化任務(wù)實(shí)例數(shù)超 2 萬(wàn),取得了良好的效果。

“羅盤(pán)”(Compass)便是基于 OPPO 內(nèi)部大數(shù)據(jù)診斷平臺(tái)的開(kāi)源項(xiàng)目,可用于診斷 DolphinScheduler、Airflow 等調(diào)度平臺(tái)上所運(yùn)行的大數(shù)據(jù)任務(wù)。我們希望通過(guò)“羅盤(pán)”(Compass)回饋開(kāi)源社區(qū),也希望更多人參與進(jìn)來(lái),共同解決任務(wù)診斷的痛點(diǎn)和難題。

二、羅盤(pán)核心功能

羅盤(pán)目前已支持以下功能和特性:

非侵入式,即時(shí)診斷,無(wú)需修改已有的調(diào)度平臺(tái),即可體驗(yàn)診斷效果。

支持多種主流調(diào)度平臺(tái),例如 DolphinScheduler、Airflow 或自研等。

支持多版本 Spark、Hadoop 2.x 和 3.x 任務(wù)日志診斷和解析。

支持工作流層異常診斷,識(shí)別各種失敗和基線耗時(shí)異常問(wèn)題。

支持引擎層異常診斷,包含數(shù)據(jù)傾斜、大表掃描、內(nèi)存浪費(fèi)等 14 種異常類(lèi)型。

支持各種日志匹配規(guī)則編寫(xiě)和異常閾值調(diào)整,可自行根據(jù)實(shí)際場(chǎng)景優(yōu)化。

羅盤(pán)已支持診斷類(lèi)型概覽:

1.png

(一)非侵入式,即時(shí)診斷

這里以 DolphinScheduler 調(diào)度平臺(tái)為例。

2.png

從架構(gòu)上看,MasterServer 主要負(fù)責(zé) DAG 任務(wù)切分、任務(wù)提交監(jiān)控并持久化任務(wù)實(shí)例數(shù)據(jù)到 DB 中,WorkerServer 主要負(fù)責(zé)任務(wù)的執(zhí)行和提供日志服務(wù),同時(shí)在 UI 提供了查看遠(yuǎn)程日志的功能。為了能夠獲取任務(wù)元數(shù)據(jù)和相關(guān)日志進(jìn)行診斷,一個(gè)方式是在 MasterServer 中監(jiān)聽(tīng)任務(wù)狀態(tài)事件,另一個(gè)方式是訂閱 MySQL binlog 日志。為了減少對(duì) DolphinScheduler 的修改,我們采取了第二種方式。

因此只需要在 DolphinScheduler 創(chuàng)建一個(gè)工作流,并運(yùn)行,等待運(yùn)行結(jié)束,我們便可在羅盤(pán)上看到該任務(wù)運(yùn)行失敗等異常。

3.png

羅盤(pán)不但實(shí)現(xiàn)了對(duì)調(diào)度平臺(tái)的解耦,還能在任務(wù)運(yùn)行結(jié)束后即時(shí)診斷,同時(shí)提供了豐富的 UI 展示服務(wù)。如果您不需要我們提供的 UI 服務(wù),那也可以直接查詢(xún)羅盤(pán)診斷的元數(shù)據(jù),展示在需要的地方。

(二)工作流層異常診斷

對(duì)于工作流層的任務(wù)實(shí)例,常見(jiàn)問(wèn)題可分為兩類(lèi):一類(lèi)是失敗的任務(wù),例如首次失敗、最終運(yùn)行失敗和長(zhǎng)期失敗;另一類(lèi)是耗時(shí)異常的任務(wù),例如基線時(shí)間異常、基線耗時(shí)異常和運(yùn)行耗時(shí)長(zhǎng)。

診斷失敗的任務(wù)

用戶(hù)經(jīng)常忽略首次失敗,甚至加大重試次數(shù),如果不重視,最終可能會(huì)演變?yōu)樽罱K失敗。羅盤(pán)記錄和診斷分析了每次失敗的原因,不僅可以為用戶(hù)快速定位問(wèn)題,還可以在故障回溯時(shí)找到根因。對(duì)于長(zhǎng)期失敗的任務(wù),需要通知用戶(hù)整改或清理,避免造成資源浪費(fèi)。

4.png

診斷耗時(shí)異常的任務(wù)

針對(duì)需要 SLA 保障的任務(wù),羅盤(pán)不僅分析了相對(duì)于歷史正常結(jié)束時(shí)間,是否提前結(jié)束或者晚點(diǎn)結(jié)束的任務(wù),即基線時(shí)間異常,也分析了相對(duì)于歷史正常運(yùn)行時(shí)長(zhǎng),是否運(yùn)行時(shí)間過(guò)長(zhǎng)或者過(guò)短的任務(wù),即基線耗時(shí)異常。對(duì)于運(yùn)行耗時(shí)長(zhǎng)的任務(wù),例如超過(guò)幾個(gè)小時(shí)以上的大任務(wù),用戶(hù)和平臺(tái)都需要分析是任務(wù)本身的問(wèn)題,還是平臺(tái)的問(wèn)題。

5.png

(三)Spark 引擎層異常診斷

對(duì)于 Spark 任務(wù),常見(jiàn)的問(wèn)題可以歸為三類(lèi):一類(lèi)是運(yùn)行時(shí)報(bào)錯(cuò),另一類(lèi)是運(yùn)行時(shí)效率,最后一類(lèi)是資源使用率問(wèn)題。

6.png

診斷運(yùn)行時(shí)報(bào)錯(cuò)異常

引擎層常見(jiàn)報(bào)錯(cuò)有 sql 失敗、shuffle 失敗和內(nèi)存溢出等。此類(lèi)報(bào)錯(cuò)具有明顯的日志特征,可根據(jù)關(guān)鍵字提取分類(lèi),使用已有的知識(shí)庫(kù),提供給用戶(hù)具體的解決方案,提升用戶(hù)體驗(yàn)和效率。

羅盤(pán)提供了 sql 失敗日志分析的規(guī)則,通常涉及到操作權(quán)限,庫(kù)表不存在及語(yǔ)法等問(wèn)題,此類(lèi)問(wèn)題可直接指引用戶(hù)去申請(qǐng)權(quán)限。

7.png

shuffle 問(wèn)題會(huì)嚴(yán)重影響任務(wù)運(yùn)行甚至導(dǎo)致失敗,需要重點(diǎn)關(guān)注,如果您目前沒(méi)有更好的解決方案,也可以參考 OPPO 開(kāi)源的高性能遠(yuǎn)程 shuffle 服務(wù)。

8.png

內(nèi)存溢出也是經(jīng)常導(dǎo)致任務(wù)失敗的一大問(wèn)題,可提取關(guān)鍵日志診斷分析并建議用戶(hù)優(yōu)化內(nèi)存配置參數(shù)。

9.png

除了以上問(wèn)題,羅盤(pán)還提供了 40+的日志識(shí)別規(guī)則及建議,也可自行根據(jù)實(shí)際場(chǎng)景擴(kuò)展識(shí)別規(guī)則。

診斷運(yùn)行時(shí)效率異常

如果任務(wù)執(zhí)行耗時(shí)較長(zhǎng)或者突然變慢,用戶(hù)直接在調(diào)度平臺(tái)無(wú)法判斷是任務(wù)自身問(wèn)題,還是調(diào)度平臺(tái)問(wèn)題,亦或是計(jì)算引擎的問(wèn)題。為了排查 Spark 引擎,一般需要專(zhuān)業(yè)分析 SparkUI,比較不直觀。羅盤(pán)對(duì)影響引擎執(zhí)行效率的問(wèn)題做了全面的檢測(cè),覆蓋大表掃描,數(shù)據(jù)傾斜,Task 長(zhǎng)尾,全局排序,OOM 風(fēng)險(xiǎn),Job/stage 耗時(shí)異常,HDFS 卡頓,推測(cè)執(zhí)行 Task 過(guò)多等問(wèn)題。

大表掃描

羅盤(pán)對(duì)執(zhí)行的 SQL 掃描表行數(shù),直觀呈現(xiàn)在表格中。如果用戶(hù)沒(méi)有進(jìn)行分區(qū)條件篩選,可能會(huì)發(fā)生全表掃描,需要提醒用戶(hù)優(yōu)化 SQL,避免導(dǎo)致內(nèi)存溢出和影響集群,以提升運(yùn)行效率。

10.png

數(shù)據(jù)傾斜

羅盤(pán)檢測(cè)每個(gè) Task 的數(shù)據(jù)處理量并判斷數(shù)據(jù)是否傾斜。當(dāng)數(shù)據(jù)傾斜時(shí),可能會(huì)導(dǎo)致任務(wù)內(nèi)存溢出,計(jì)算資源利用率低,作業(yè)執(zhí)行時(shí)間超出預(yù)期。

11.png

Task 長(zhǎng)尾

羅盤(pán)檢測(cè)所有 Task 的耗時(shí),并按 Stage 呈現(xiàn)在柱狀圖中,方便用戶(hù)判斷是哪個(gè) Stage 執(zhí)行耗時(shí)異常。形成的原因一般是讀取數(shù)據(jù)過(guò)多或讀取數(shù)據(jù)慢。如果是數(shù)據(jù)傾斜造成讀取數(shù)據(jù)過(guò)多,則按數(shù)據(jù)傾斜方式處理。如果同時(shí) HDFS 發(fā)生卡頓,則會(huì)導(dǎo)致讀取數(shù)據(jù)慢,則需要排查集群?jiǎn)栴}。

12.png

全局排序異常

用戶(hù)經(jīng)常在 SQL 中使用了排序函數(shù)卻不加分區(qū)限制,會(huì)導(dǎo)致全局排序。如果只有一個(gè) Task 處理數(shù)據(jù),需要建議用戶(hù)重新分區(qū),避免造成資源浪費(fèi)和影響運(yùn)行效率。

13.png

OOM 預(yù)警分析

羅盤(pán)檢測(cè)執(zhí)行 SQL 廣播內(nèi)存占比,當(dāng)廣播數(shù)據(jù)過(guò)大,會(huì)導(dǎo)致 driver 或 executor 出現(xiàn) OOM 風(fēng)險(xiǎn),需要提醒用戶(hù)禁用廣播或取消強(qiáng)制廣播,必要時(shí)申請(qǐng)?jiān)黾觾?nèi)存。

14.png

Job/stage 耗時(shí)異常

羅盤(pán)計(jì)算每個(gè) Job/stage 實(shí)際計(jì)算時(shí)間和空閑時(shí)間,一般是資源不足時(shí)出現(xiàn),需要關(guān)注集群資源問(wèn)題。

15.png

HDFS 卡頓

當(dāng)出現(xiàn) HDFS 卡頓時(shí),會(huì)影響 Task 讀取數(shù)據(jù)速率,從而影響執(zhí)行效率,需要關(guān)注 HDFS 集群運(yùn)行狀態(tài)。

16.png

推測(cè)執(zhí)行 Task 過(guò)多

推測(cè)執(zhí)行(speculative)是指作業(yè)執(zhí)行單元 Task 在同一個(gè) Stage 中的執(zhí)行時(shí)間相比其他 Task 執(zhí)行時(shí)間長(zhǎng),在其他 Executor 發(fā)起相同 Task 執(zhí)行,先完成的 Task 將 Kill 另個(gè) Task, 并取得結(jié)果。需要關(guān)注集群運(yùn)行狀態(tài)。

17.png

診斷資源使用率異常

對(duì)于用戶(hù)不確定任務(wù) CPU 和內(nèi)存使用情況,不知道怎么申請(qǐng)多大規(guī)格資源的問(wèn)題,羅盤(pán)直觀呈現(xiàn)了 CPU 和內(nèi)存使用占比,方便用戶(hù)優(yōu)化資源配置參數(shù),以節(jié)約資源成本。

18.png

19.png

羅盤(pán)還提供了 GC 日志分析功能,可查看執(zhí)行過(guò)程 GC 是否存在性能問(wèn)題。

20.png

(四)一鍵診斷、報(bào)告總覽等功能

除了以上功能,我們還提供了一鍵診斷的功能,為用戶(hù)提供詳細(xì)的診斷報(bào)告。同時(shí)還有報(bào)告總覽數(shù)據(jù)和白名單功能等。

21.png

22.png

三、羅盤(pán)技術(shù)架構(gòu)

羅盤(pán)主要由同步工作流層任務(wù)元數(shù)據(jù)模塊、同步 Yarn/SparkApp元數(shù)據(jù)模塊、關(guān)聯(lián)工作流層/引擎層 App 元數(shù)據(jù)模塊、工作流任務(wù)異常檢測(cè)模塊,引擎層異常檢測(cè)模塊,Portal 展示模塊組成。

整體架構(gòu)圖

23.png

整體架構(gòu)分 3 層:

第一層為對(duì)接外部系統(tǒng),包括調(diào)度器、Yarn、HistoryServer、HDFS 等系統(tǒng),同步元數(shù)據(jù)、集群狀態(tài)、運(yùn)行環(huán)境狀態(tài)、日志等到診斷系統(tǒng)分析;

第二層為架構(gòu)層,包括數(shù)據(jù)采集、元數(shù)據(jù)關(guān)聯(lián)&模型標(biāo)準(zhǔn)化、異常檢測(cè)、診斷 Portal 模塊;

第三層為基礎(chǔ)組件層,包括 MySQL、Elasticsearch、Kafka、Redis 等組件。

具體模塊流程階段:

(1)數(shù)據(jù)采集階段:從調(diào)度系統(tǒng)將用戶(hù)、DAG、作業(yè)、執(zhí)行記錄等工作流元數(shù)據(jù)同步至診斷系統(tǒng);定時(shí)同步 Yarn ResourceManager、Spark HistoryServer App 元數(shù)據(jù)至診斷系統(tǒng),標(biāo)志作業(yè)運(yùn)行指標(biāo)存儲(chǔ)路徑,為后續(xù)數(shù)據(jù)處理階段作基礎(chǔ);

(2)數(shù)據(jù)關(guān)聯(lián)&模型標(biāo)準(zhǔn)化階段:將分步采集的工作流執(zhí)行記錄、Spark App、Yarn App、集群運(yùn)行環(huán)境配置等數(shù)據(jù)通過(guò) ApplicationID 介質(zhì)進(jìn)行關(guān)聯(lián),此時(shí),工作流層與引擎層元數(shù)據(jù)已關(guān)聯(lián)完畢,得到數(shù)據(jù)標(biāo)準(zhǔn)模型(user, dag, task, application, clusterConfig, time);

(3)工作流層&引擎層異常檢測(cè)階段:至此已經(jīng)獲得數(shù)據(jù)標(biāo)準(zhǔn)模型,針對(duì)標(biāo)準(zhǔn)模型進(jìn)一步 Workflow 異常檢測(cè)流程,同時(shí)平臺(tái)維護(hù)著一套沉淀多年的數(shù)據(jù)治理知識(shí)庫(kù),加載知識(shí)庫(kù)到標(biāo)準(zhǔn)模型,通過(guò)啟發(fā)式規(guī)則,對(duì)標(biāo)準(zhǔn)模型的指標(biāo)數(shù)據(jù)、日志同時(shí)進(jìn)行異常挖掘,結(jié)合集群狀態(tài)及運(yùn)行是環(huán)境狀態(tài),分析得出工作流層、引擎層異常結(jié)果;

24.png

(4)業(yè)務(wù)視圖:存儲(chǔ)、分析數(shù)據(jù),提供給用戶(hù)任務(wù)概覽、工作流層任務(wù)診斷、引擎層作業(yè) Application 診斷,工作流層展示調(diào)度器執(zhí)行任務(wù)引發(fā)的異常,如任務(wù)失敗、回環(huán)任務(wù)、基線偏離任務(wù)等問(wèn)題,計(jì)算引擎層展示 Spark 作業(yè)執(zhí)行引發(fā)的耗時(shí)、資源使用、運(yùn)行時(shí)問(wèn)題;

25.png

四、DolphinScheduler & Compass

DolphinScheduler 是一個(gè)分布式和可擴(kuò)展的開(kāi)源工作流協(xié)調(diào)平臺(tái),具有強(qiáng)大的 DAG 可視化界面,有著豐富的使用場(chǎng)景,提供 Spark、Hive 和 Flink 等 30+種類(lèi)型的任務(wù),可靠性高和拓展性強(qiáng)。DolphinScheduler 經(jīng)歷了多年的實(shí)踐和積累,已經(jīng)成為了一個(gè)成熟的開(kāi)源項(xiàng)目,并有著廣泛的用戶(hù)群體。

(一)部署體驗(yàn)

這里我們以 DolphinScheduler(2.0.6 版本)為例,體驗(yàn)如何快速集成羅盤(pán)。如果你還沒(méi)有部署 DolphinScheduler,可參考官網(wǎng)部署指南。如果你已經(jīng)在使用 DolphinScheduler,那么只需要部署羅盤(pán)即可。羅盤(pán)支持單機(jī)和集群部署,如果你想要快速體驗(yàn)羅盤(pán)的功能,可使用單機(jī)部署模式,羅盤(pán)依賴(lài) Kafka、Redis、zookeeper 和 ElasticSearch,需要提前安裝,依賴(lài)服務(wù)完成后即可通過(guò)部署腳本進(jìn)行羅盤(pán)部署:

代碼編譯

26.jpg

修改配置

27.jpg

28.png

一鍵部署

29.png

(二)使用示例

首先在DolphinScheduler 創(chuàng)建好項(xiàng)目,

30.png

然后創(chuàng)建一個(gè) SPARK 任務(wù)的工作流,

31.png

最后上線該任務(wù)和運(yùn)行。

32.png

打開(kāi)羅盤(pán) Web UI,默認(rèn)路徑為-,輸入 DolphinScheduler 的賬號(hào)密碼,羅盤(pán)自動(dòng)同步了 DolphinScheduler 用戶(hù)信息。

33.png

最后進(jìn)入任務(wù)運(yùn)行頁(yè)面,便可以看到所有的異常任務(wù)診斷信息。

34.png

五、羅盤(pán)開(kāi)源規(guī)劃

羅盤(pán)主要圍繞離線調(diào)度任務(wù)、計(jì)算引擎兩個(gè)方面對(duì)問(wèn)題進(jìn)行定位分析,使用豐富的知識(shí)庫(kù),提供給用戶(hù)解決優(yōu)化方案,同時(shí)達(dá)到降本增效的目的。

目前已開(kāi)源部分主要包含對(duì)任務(wù)工作流和 Spark 引擎層的問(wèn)題診斷,不久將發(fā)布針對(duì) Flink 任務(wù)的異常和資源問(wèn)題診斷。

未來(lái)將引入更深層次的算法和診斷模型,實(shí)現(xiàn)去規(guī)則和閾值,使異常診斷更加智能化。

六、參與貢獻(xiàn)

Github項(xiàng)目名稱(chēng):cubefs/compass

歡迎參與貢獻(xiàn),如果您有需求或建議可以提 issue 到 Github,我們將及時(shí)為您解答。

關(guān)于安第斯智能云

OPPO 安第斯智能云(AndesBrain)是服務(wù)個(gè)人、家庭與開(kāi)發(fā)者的泛終端智能云,致力于“讓終端更智能”。作為 OPPO 三大核心技術(shù)之一,安第斯智能云提供端云協(xié)同的數(shù)據(jù)存儲(chǔ)與智能計(jì)算服務(wù),是萬(wàn)物互融的“數(shù)智大腦”。

(免責(zé)聲明:本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請(qǐng)進(jìn)一步核實(shí),并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏,概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí),應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明,并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后,將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí),溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。 )