一、背景
OPPO 大數(shù)據(jù)平臺目前有 20+個服務(wù)組件，數(shù)據(jù)量超 1EB，離線任務(wù)數(shù)近百萬，實(shí)時(shí)任務(wù)數(shù)千，數(shù)據(jù)開發(fā)分析師超千人。這也帶來了系統(tǒng)復(fù)雜度的問題，一方面是用戶經(jīng)常對自己的任務(wù)運(yùn)行狀況“摸不著頭腦”，不管是性能問題，還是參數(shù)配置問題，甚至是一些常見的權(quán)限報(bào)錯問題，都需要咨詢平臺給出具體的解決方案；另一方面是平臺面對各類繁雜任務(wù)，運(yùn)維人員經(jīng)常需要對任務(wù)故障定位和排除，由于任務(wù)鏈路長，組件日志多，運(yùn)維壓力大。因此急需對任務(wù)進(jìn)行實(shí)時(shí)監(jiān)控和診斷，不僅要能夠幫助用戶快速定位異常問題，還需給出具體的建議和優(yōu)化方案，同時(shí)還能治理各類“僵尸”和不合理任務(wù)，從而達(dá)到降本增效的目的。據(jù)調(diào)研，目前業(yè)界尚無成熟的開源任務(wù)診斷平臺。為此我們開發(fā)了大數(shù)據(jù)診斷平臺，通過診斷平臺周優(yōu)化任務(wù)實(shí)例數(shù)超 2 萬，取得了良好的效果。
“羅盤”（Compass）便是基于 OPPO 內(nèi)部大數(shù)據(jù)診斷平臺的開源項(xiàng)目，可用于診斷 DolphinScheduler、Airflow 等調(diào)度平臺上所運(yùn)行的大數(shù)據(jù)任務(wù)。我們希望通過“羅盤”（Compass）回饋開源社區(qū)，也希望更多人參與進(jìn)來，共同解決任務(wù)診斷的痛點(diǎn)和難題。
二、羅盤核心功能
羅盤目前已支持以下功能和特性：
非侵入式，即時(shí)診斷，無需修改已有的調(diào)度平臺，即可體驗(yàn)診斷效果。
支持多種主流調(diào)度平臺，例如 DolphinScheduler、Airflow 或自研等。
支持多版本 Spark、Hadoop 2.x 和 3.x 任務(wù)日志診斷和解析。
支持工作流層異常診斷，識別各種失敗和基線耗時(shí)異常問題。
支持引擎層異常診斷，包含數(shù)據(jù)傾斜、大表掃描、內(nèi)存浪費(fèi)等 14 種異常類型。
支持各種日志匹配規(guī)則編寫和異常閾值調(diào)整，可自行根據(jù)實(shí)際場景優(yōu)化。
羅盤已支持診斷類型概覽：
（一）非侵入式，即時(shí)診斷
這里以 DolphinScheduler 調(diào)度平臺為例。
從架構(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)行診斷，一個方式是在 MasterServer 中監(jiān)聽任務(wù)狀態(tài)事件，另一個方式是訂閱 MySQL binlog 日志。為了減少對 DolphinScheduler 的修改，我們采取了第二種方式。
因此只需要在 DolphinScheduler 創(chuàng)建一個工作流，并運(yùn)行，等待運(yùn)行結(jié)束，我們便可在羅盤上看到該任務(wù)運(yùn)行失敗等異常。
羅盤不但實(shí)現(xiàn)了對調(diào)度平臺的解耦，還能在任務(wù)運(yùn)行結(jié)束后即時(shí)診斷，同時(shí)提供了豐富的 UI 展示服務(wù)。如果您不需要我們提供的 UI 服務(wù)，那也可以直接查詢羅盤診斷的元數(shù)據(jù)，展示在需要的地方。
（二）工作流層異常診斷
對于工作流層的任務(wù)實(shí)例，常見問題可分為兩類：一類是失敗的任務(wù)，例如首次失敗、最終運(yùn)行失敗和長期失�。涣硪活愂呛臅r(shí)異常的任務(wù)，例如基線時(shí)間異常、基線耗時(shí)異常和運(yùn)行耗時(shí)長。
診斷失敗的任務(wù)
用戶經(jīng)常忽略首次失敗，甚至加大重試次數(shù)，如果不重視，最終可能會演變?yōu)樽罱K失敗。羅盤記錄和診斷分析了每次失敗的原因，不僅可以為用戶快速定位問題，還可以在故障回溯時(shí)找到根因。對于長期失敗的任務(wù)，需要通知用戶整改或清理，避免造成資源浪費(fèi)。
診斷耗時(shí)異常的任務(wù)
針對需要 SLA 保障的任務(wù)，羅盤不僅分析了相對于歷史正常結(jié)束時(shí)間，是否提前結(jié)束或者晚點(diǎn)結(jié)束的任務(wù)，即基線時(shí)間異常，也分析了相對于歷史正常運(yùn)行時(shí)長，是否運(yùn)行時(shí)間過長或者過短的任務(wù)，即基線耗時(shí)異常。對于運(yùn)行耗時(shí)長的任務(wù)，例如超過幾個小時(shí)以上的大任務(wù)，用戶和平臺都需要分析是任務(wù)本身的問題，還是平臺的問題。
（三）Spark 引擎層異常診斷
對于 Spark 任務(wù)，常見的問題可以歸為三類：一類是運(yùn)行時(shí)報(bào)錯，另一類是運(yùn)行時(shí)效率，最后一類是資源使用率問題。
診斷運(yùn)行時(shí)報(bào)錯異常
引擎層常見報(bào)錯有 sql 失敗、shuffle 失敗和內(nèi)存溢出等。此類報(bào)錯具有明顯的日志特征，可根據(jù)關(guān)鍵字提取分類，使用已有的知識庫，提供給用戶具體的解決方案，提升用戶體驗(yàn)和效率。
羅盤提供了 sql 失敗日志分析的規(guī)則，通常涉及到操作權(quán)限，庫表不存在及語法等問題，此類問題可直接指引用戶去申請權(quán)限。
shuffle 問題會嚴(yán)重影響任務(wù)運(yùn)行甚至導(dǎo)致失敗，需要重點(diǎn)關(guān)注，如果您目前沒有更好的解決方案，也可以參考 OPPO 開源的高性能遠(yuǎn)程 shuffle 服務(wù)。
內(nèi)存溢出也是經(jīng)常導(dǎo)致任務(wù)失敗的一大問題，可提取關(guān)鍵日志診斷分析并建議用戶優(yōu)化內(nèi)存配置參數(shù)。
除了以上問題，羅盤還提供了 40+的日志識別規(guī)則及建議，也可自行根據(jù)實(shí)際場景擴(kuò)展識別規(guī)則。
診斷運(yùn)行時(shí)效率異常
如果任務(wù)執(zhí)行耗時(shí)較長或者突然變慢，用戶直接在調(diào)度平臺無法判斷是任務(wù)自身問題，還是調(diào)度平臺問題，亦或是計(jì)算引擎的問題。為了排查 Spark 引擎，一般需要專業(yè)分析 SparkUI，比較不直觀。羅盤對影響引擎執(zhí)行效率的問題做了全面的檢測，覆蓋大表掃描，數(shù)據(jù)傾斜，Task 長尾，全局排序，OOM 風(fēng)險(xiǎn)，Job/stage 耗時(shí)異常，HDFS 卡頓，推測執(zhí)行 Task 過多等問題。
大表掃描
羅盤對執(zhí)行的 SQL 掃描表行數(shù)，直觀呈現(xiàn)在表格中。如果用戶沒有進(jìn)行分區(qū)條件篩選，可能會發(fā)生全表掃描，需要提醒用戶優(yōu)化 SQL，避免導(dǎo)致內(nèi)存溢出和影響集群，以提升運(yùn)行效率。
數(shù)據(jù)傾斜
羅盤檢測每個 Task 的數(shù)據(jù)處理量并判斷數(shù)據(jù)是否傾斜。當(dāng)數(shù)據(jù)傾斜時(shí)，可能會導(dǎo)致任務(wù)內(nèi)存溢出，計(jì)算資源利用率低，作業(yè)執(zhí)行時(shí)間超出預(yù)期。
Task 長尾
羅盤檢測所有 Task 的耗時(shí)，并按 Stage 呈現(xiàn)在柱狀圖中，方便用戶判斷是哪個 Stage 執(zhí)行耗時(shí)異常。形成的原因一般是讀取數(shù)據(jù)過多或讀取數(shù)據(jù)慢。如果是數(shù)據(jù)傾斜造成讀取數(shù)據(jù)過多，則按數(shù)據(jù)傾斜方式處理。如果同時(shí) HDFS 發(fā)生卡頓，則會導(dǎo)致讀取數(shù)據(jù)慢，則需要排查集群問題。
全局排序異常
用戶經(jīng)常在 SQL 中使用了排序函數(shù)卻不加分區(qū)限制，會導(dǎo)致全局排序。如果只有一個 Task 處理數(shù)據(jù)，需要建議用戶重新分區(qū)，避免造成資源浪費(fèi)和影響運(yùn)行效率。
OOM 預(yù)警分析
羅盤檢測執(zhí)行 SQL 廣播內(nèi)存占比，當(dāng)廣播數(shù)據(jù)過大，會導(dǎo)致 driver 或 executor 出現(xiàn) OOM 風(fēng)險(xiǎn)，需要提醒用戶禁用廣播或取消強(qiáng)制廣播，必要時(shí)申請?jiān)黾觾?nèi)存。
Job/stage 耗時(shí)異常
羅盤計(jì)算每個 Job/stage 實(shí)際計(jì)算時(shí)間和空閑時(shí)間，一般是資源不足時(shí)出現(xiàn)，需要關(guān)注集群資源問題。
HDFS 卡頓
當(dāng)出現(xiàn) HDFS 卡頓時(shí)，會影響 Task 讀取數(shù)據(jù)速率，從而影響執(zhí)行效率，需要關(guān)注 HDFS 集群運(yùn)行狀態(tài)。
推測執(zhí)行 Task 過多
推測執(zhí)行(speculative)是指作業(yè)執(zhí)行單元 Task 在同一個 Stage 中的執(zhí)行時(shí)間相比其他 Task 執(zhí)行時(shí)間長，在其他 Executor 發(fā)起相同 Task 執(zhí)行，先完成的 Task 將 Kill 另個 Task, 并取得結(jié)果。需要關(guān)注集群運(yùn)行狀態(tài)。
診斷資源使用率異常
對于用戶不確定任務(wù) CPU 和內(nèi)存使用情況，不知道怎么申請多大規(guī)格資源的問題，羅盤直觀呈現(xiàn)了 CPU 和內(nèi)存使用占比，方便用戶優(yōu)化資源配置參數(shù)，以節(jié)約資源成本。
羅盤還提供了 GC 日志分析功能，可查看執(zhí)行過程 GC 是否存在性能問題。
（四）一鍵診斷、報(bào)告總覽等功能
除了以上功能，我們還提供了一鍵診斷的功能，為用戶提供詳細(xì)的診斷報(bào)告。同時(shí)還有報(bào)告總覽數(shù)據(jù)和白名單功能等。
三、羅盤技術(shù)架構(gòu)
羅盤主要由同步工作流層任務(wù)元數(shù)據(jù)模塊、同步 Yarn/Spark App 元數(shù)據(jù)模塊、關(guān)聯(lián)工作流層/引擎層 App 元數(shù)據(jù)模塊、工作流任務(wù)異常檢測模塊，引擎層異常檢測模塊，Portal 展示模塊組成。
整體架構(gòu)圖
整體架構(gòu)分 3 層：
第一層為對接外部系統(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)化、異常檢測、診斷 Portal 模塊；
第三層為基礎(chǔ)組件層，包括 MySQL、Elasticsearch、Kafka、Redis 等組件。
具體模塊流程階段：
（1）數(shù)據(jù)采集階段：從調(diào)度系統(tǒng)將用戶、DAG、作業(yè)、執(zhí)行記錄等工作流元數(shù)據(jù)同步至診斷系統(tǒng)；定時(shí)同步 Yarn ResourceManager、Spark HistoryServer App 元數(shù)據(jù)至診斷系統(tǒng)，標(biāo)志作業(yè)運(yùn)行指標(biāo)存儲路徑，為后續(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ù)通過 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）工作流層&引擎層異常檢測階段：至此已經(jīng)獲得數(shù)據(jù)標(biāo)準(zhǔn)模型，針對標(biāo)準(zhǔn)模型進(jìn)一步 Workflow 異常檢測流程，同時(shí)平臺維護(hù)著一套沉淀多年的數(shù)據(jù)治理知識庫，加載知識庫到標(biāo)準(zhǔn)模型，通過啟發(fā)式規(guī)則，對標(biāo)準(zhǔn)模型的指標(biāo)數(shù)據(jù)、日志同時(shí)進(jìn)行異常挖掘，結(jié)合集群狀態(tài)及運(yùn)行是環(huán)境狀態(tài)，分析得出工作流層、引擎層異常結(jié)果；
（4）業(yè)務(wù)視圖：存儲、分析數(shù)據(jù)，提供給用戶任務(wù)概覽、工作流層任務(wù)診斷、引擎層作業(yè) Application 診斷，工作流層展示調(diào)度器執(zhí)行任務(wù)引發(fā)的異常，如任務(wù)失敗、回環(huán)任務(wù)、基線偏離任務(wù)等問題，計(jì)算引擎層展示 Spark 作業(yè)執(zhí)行引發(fā)的耗時(shí)、資源使用、運(yùn)行時(shí)問題；
四、DolphinScheduler & Compass
DolphinScheduler 是一個分布式和可擴(kuò)展的開源工作流協(xié)調(diào)平臺，具有強(qiáng)大的 DAG 可視化界面，有著豐富的使用場景，提供 Spark、Hive 和 Flink 等 30+種類型的任務(wù)，可靠性高和拓展性強(qiáng)。DolphinScheduler 經(jīng)歷了多年的實(shí)踐和積累，已經(jīng)成為了一個成熟的開源項(xiàng)目，并有著廣泛的用戶群體。
（一）部署體驗(yàn)
這里我們以 DolphinScheduler（2.0.6 版本）為例，體驗(yàn)如何快速集成羅盤。如果你還沒有部署 DolphinScheduler，可參考官網(wǎng)部署指南。如果你已經(jīng)在使用 DolphinScheduler，那么只需要部署羅盤即可。羅盤支持單機(jī)和集群部署，如果你想要快速體驗(yàn)羅盤的功能，可使用單機(jī)部署模式，羅盤依賴 Kafka、Redis、zookeeper 和 ElasticSearch，需要提前安裝，依賴服務(wù)完成后即可通過部署腳本進(jìn)行羅盤部署：
代碼編譯
修改配置
一鍵部署
（二）使用示例
首先在 DolphinScheduler 創(chuàng)建好項(xiàng)目，
然后創(chuàng)建一個 SPARK 任務(wù)的工作流，
最后上線該任務(wù)和運(yùn)行。
打開羅盤 Web UI，默認(rèn)路徑為-，輸入 DolphinScheduler 的賬號密碼，羅盤自動同步了 DolphinScheduler 用戶信息。
最后進(jìn)入任務(wù)運(yùn)行頁面，便可以看到所有的異常任務(wù)診斷信息。
五、羅盤開源規(guī)劃
羅盤主要圍繞離線調(diào)度任務(wù)、計(jì)算引擎兩個方面對問題進(jìn)行定位分析，使用豐富的知識庫，提供給用戶解決優(yōu)化方案，同時(shí)達(dá)到降本增效的目的。
目前已開源部分主要包含對任務(wù)工作流和 Spark 引擎層的問題診斷，不久將發(fā)布針對 Flink 任務(wù)的異常和資源問題診斷。
未來將引入更深層次的算法和診斷模型，實(shí)現(xiàn)去規(guī)則和閾值，使異常診斷更加智能化。
六、參與貢獻(xiàn)
Github項(xiàng)目名稱：cubefs/compass
歡迎參與貢獻(xiàn)，如果您有需求或建議可以提 issue 到 Github，我們將及時(shí)為您解答。
關(guān)于安第斯智能云
OPPO 安第斯智能云（AndesBrain）是服務(wù)個人、家庭與開發(fā)者的泛終端智能云，致力于“讓終端更智能”。作為 OPPO 三大核心技術(shù)之一，安第斯智能云提供端云協(xié)同的數(shù)據(jù)存儲與智能計(jì)算服務(wù)，是萬物互融的“數(shù)智大腦”。
