導讀 在大資料行業中資料量大、任務多的背景下，如何做智能化、自動化的異常任務識别和分析至關重要。本文就将分享OPPO大資料診斷平台的設計與實踐。
全文目錄：
1. 背景
2. 技術方案
3. 時間效果
4. 總結與規劃
分享嘉賓｜戴巍 OPPO 資料平台架構師
編輯整理｜依依 哔哩哔哩
内容稽核｜李瑤
出品社群｜DataFun
01
背景
1.OPPO大資料現狀
首先介紹一下OPPO大資料的現狀。整體大資料的資料量已經超過了一億，系統元件20+，整體離線任務達到百萬級别，實時任務也有數千，整個公司的資料分析師和開發師超過了1000人。資料和任務的複雜情況也帶來了系統級的複雜度，其中包括：
- 資料開發人員水準參差不齊，問題排查困難；
- 任務鍊路長，元件衆多，運維複雜；
- 僵屍任務和不合理任務治理難度大；
2.業界産品對比
現在業界有一些類似的開源産品，比如Dr. Elephant，它是Linkedin開發并開源的，主要用來提高開發人員的效率和增加叢集任務調試的高效性。
支援很多種計算引擎，例如Spark，Tez，MapReduce，同時也支援多種排程架構，比如Azkaban，Airflow等。并且能夠形成分析報告，作為曆史作業和工作流性能統計的名額。
通過我們的實踐和測試，發現它存在一些不足之處。首先，它對于新版本的相容性不夠好；另外，支援的Spark診斷名額非常少，目前隻有4個；診斷手段也相對較少；最後就是存在一些穩定性風險，因為它需要不斷對Spark History的服務接口做頻繁的調用，影響了整體的穩定性。
基于這樣的背景，我們自研了一套大資料平台的任務診斷系統。
02
技術方案
1.平台特性
我們的平台具有以下一些特性：
- 首先，做到了非侵入式，即時診斷，無需修改已有的排程平台，即可體驗診斷效果；
- 第二，支援OPPO自研排程平台以及多種主流開源排程平台，包括DolphinScheduler，Airflow等，并可進行工作流層面的異常診斷；
- 第三，在計算引擎和存儲上面支援多版本的Flink、Hadoop、Spark；
- 第四，目前支援了40+ 離線和實時場景的異常類型判定，并仍在不斷完善和豐富；
- 最後，支援自定義規則編寫和異常門檻值調整，可以針對不同場景自行調整。
診斷規則層面，可以通過效率分析、成本分析以及穩定性分析等，做任務診斷分析。在互動層面，首先提供了我們自己的Web UI，來檢視整體的任務情況，也提供了Http API接口，這樣可以将我們的任務診斷能力賦能給互動查詢、任務排程和資料治理等資料應用。在互動查詢上可以幫助開發人員快速做異常發現和任務排查，應用在任務排程上可以做後續任務的不斷優化，在資料治理上可以提供健康分的概念，推動資料治理在集團當中的推廣。
2.系統架構
系統架構主要分為三層：
- 外部系統适配層，将Yarn、排程器、計算引擎、叢集狀态、運作環境狀态等名額收集到診斷系統當中；
- 診斷架構層，主要包括資料采集，中繼資料關聯，資料模型标準化，異常檢測以及診斷Portal子產品；
- 底層是通用基礎元件層。
3.流程階段
整體流程包括三大階段：
- 首先是資料采集階段，會将排程系統的DAG、使用者、執行記錄等工作流的中繼資料進行同步，在計算引擎采集Yarn、ResourceManager、Spark、Flink的中繼資料；
- 采集完成之後，會通過工作流的模式把各個元件的資料關聯起來，并行成一個标準化的模型；
- 得到标準化模型之後，通過加載已有的知識庫到标準模型，通過啟發式規則，進行診斷和異常挖掘，并結合叢集狀态以及運作時狀态做相關的分析，最終得到是否異常的結果。
最終我們會将相關資料的存儲和分析，通過直覺、簡潔的UI提供給業務方，幫助業務方及時準确地發現問題。
03
實踐效果
下面我們來看一下診斷平台在我們公司内部的實踐效果。
1.互動設計
互動設計層面，我們做到了非常統一、簡潔和直覺的Web UI，這樣使用者可以一眼看到他所關心的任務問題所在，并且我們也會給出一些指導性處理建議。
2.診斷類型豐富
平台提供了較為豐富的診斷類型，針對離線、實時任務的健康度診斷，目前支援了40+ 場景的異常類型判定。整體上可分為四大方面：
- 效率分析方面，包括長尾Task分析、HDFS卡頓分析、推測執行過多分析，以及全局排序異常分析等；
- 穩定性分析方面，例如全表掃描問題、資料傾斜分析、Shuffle失敗分析、記憶體溢出等；
- 實時作業分析，支援作業TM空跑、并行度不足、反壓算子和慢算子的診斷等；
- 成本分析方面，包括CPU浪費分析、記憶體浪費分析、長期失敗分析和任務耗時分析等。
3.效率分析案例
在效率分析方面，有一個長尾Task分析的案例。在整體的WEB界面可以明顯看出哪些任務耗時是比較長的，拖慢了整個任務的運作時間。平台會給出一些分析和建議，比如是由于單個Task讀取資料量過多或者讀取資料過慢，如果讀取資料量過多，可能是資料傾斜的問題，建議按照資料傾斜方式處理，如果是讀取資料過慢，可能是HDFS叢集節點負載過高或者是網絡丢包等問題，可以聯系運維相關同學進行進一步的排查。
4.成本分析案例
在成本分析方面，這裡給出了一個CPU浪費分析的案例，在界面上面也能非常直覺地看到每個Driver的cores的運作時間和空閑時間，可以設定一個門檻值，當空閑時間超過門檻值，就會判定為浪費，并且給出一個降低啟用CPU數量的建議。
5.穩定性分析案例
在穩定性分析方面，這裡給出了一個資料傾斜分析的案例。資料傾斜是Task計算過程中Key分布不均造成的，個别Key的資料特别多，超出計算節點的計算能力，會導緻記憶體溢出，計算資源使用率低，整體作業逾時的問題。我們基于自身大量資料處理的經驗，對如何處理這種問題進行了總結，如上圖中所示。如果發現資料傾斜的異常，會給出相應的處理建議，結合業務方具體的任務去選擇恰當的處理方式。
還有一些SQL的常見問題分析。比如沒有權限、表不存在、文法錯誤等，因為我們在任務上線的時候會做一些SQL的校驗，但是在運作過程中會出現權限失效，或者是表被修改了等等問題。我們也能夠非常明确地給出問題和解決方法，比如重新去申請相應權限，或者修改SQL和表結構等。
6.實時分析案例
再來分享一個實時分析的案例。我們去跑Flink任務的時候，可以做一些診斷，給使用者相關的建議，比如Flink參數設定不合理造成的CPU和記憶體的浪費，使用率是否過多，并且會給出建議值，比如數量建議是多少，任務的并行程度大概是多少，類似這樣的診斷建議。
7.降本增效
最終我們通過異常任務、不合理任務的分析，轉換成成本口徑的統計，給到資料治理，形成健康分統一的口徑，進行資料治理。這樣在公司内部，通過長期的推進治理，可以看出成本下降明顯，任務問題得到了改善。
04
總結與規劃
最後來分享一下整體的總結和規劃。
OPPO大資料診斷平台主要圍繞的是排程引擎和計算引擎兩個方面進行智能化定位分析，為使用者快速處理和優化任務，為企業降本增效。
技術方面采用了非入侵方案對接其他系統，這樣保證了其他系統的安全性。系統架構基于啟發式規則定位和分析問題方式，但知識庫比較依賴人員經驗，目前計劃引入一些資料挖掘算法擴大整體檢測範圍，實作更加智能化的診斷。目前支援Spark和Flink任務問題的診斷，除了OPPO自研的一些排程平台之外，還支援DolphinScheduler、Airflow等開源排程平台。
為了回饋開源社群，并且希望更多人參與進來，共同解決任務診斷的痛點和難題，我們現在已經把一些功能做了開源的處理，項目名稱叫做“羅盤”。上圖中給出了Github位址和微信群，大家有興趣可以關注一下。
開源的版本主要支援DolphinScheduler和Airflow兩種主流排程平台；同時支援多版本Spark、Hadoop 2.0和3.0任務日志診斷和解析；目前支援14種異常診斷類型；同時支援各種日志比對規則編寫和異常門檻值調整，可自己根據實際場景進行優化。
05
問答環節
Q1：CPU浪費是如何計算出來的？
A1：我們之前相關的介紹文檔已經通過公衆号發出來了，裡面會有比較詳細的CPU浪費的計算公式。主要就是針對整體空閑時間和運作時間的計算，判斷比例的情況，達到一定的門檻值之後判斷為浪費。
Q2：請問這裡面的診斷是如何實作智能化的？使用的是一些什麼樣的模型？
回答：我們目前是基于知識庫，相當于是基于曆史的資料處理經驗，智能化是我們仍在探索中的工作，後續還會将成果分享出來。