OPPO大資料診斷平臺設計與實踐

01 背景

隨著歐加集團大資料業務的發展，現階段公司大資料平臺20+個元件，1EB+級別資料量，平臺1000人均日活，服務已經有相當大的規模。在這樣的業務背景下，越來越多的使用者在使用大資料平臺時，發現難以定位問題。基於此，我們設計大資料診斷平臺，旨在提升使用者解決問題效率，降低使用者異常成本。代號“羅盤”，意為使用者定位問題，給出最佳化方案。

此前業務存在問題現狀總結如下：

1、問題定位效率相對低。平臺元件多，從上層排程器、Livy客戶端到中層計算引擎Spark，最後底層Hadoop系統；使用者作業日誌量大，沒法串聯一起，問題上下文關聯難；使用者人員角色非單一研發角色人員，自行分析能力有限，需平臺方提供協助解決，溝通與定位讓雙方工作量只增不減；缺乏自動化工具定位問題等等。各種因素說明，海量作業排程，多種型別執行環境，TB級別日誌量，依靠人力盤查作業問題是非常耗的。

2、異常問題型別多，缺乏有效知識庫，高效重複利用已有的解決方案。從作業排程任務系統到計算引擎層，常見的業務問題常見如：晚點溯源、高頻失敗、執行耗時長、資料傾斜、暴力掃描、shuffle失敗、CPU浪費、記憶體浪費、記憶體溢位等，需將問題數量降低收斂。

3、異常任務、不合理任務成本多。使用者任務在執行週期內發生異常或者配置不合理，將導致任務浪費資源，產生許多額外的成本，需將此類問題成本損失降至最低。

總體上希望，從問題出發、經過快速定位、最佳化方案、問題收斂環節，最後達到降本增效目的。

02 業界產品

基於以上問題，我們調研了業界有關大資料診斷系統，目前比較類似的是Dr. Elephant開源系統，Dr. Elephant一個Hadoop和Spark的效能監控調優工具。它能自動採集Airflow、Azkaban、Oozie等排程系統作業流及計算引擎Spark和Hadoop MR的執行指標，分析作業的異常和效能結果，指導開發者進行作業調優，從而提升開發者工作效率和叢集資源利用率。

工作原理：

Dr. Elephant定期從Yarn資源管理中心拉取近期成功和失敗的作業列表。每個作業會實時從歷史伺服器中獲取到後設資料、配置及排程器作業資訊以及監控資料。一旦獲取到所有的後設資料資訊，Dr. Elephant就基於這些後設資料執行啟發式演算法，並生成一份該作業的診斷報告。對該作業報告，進行標記和評級，分為五個級別來評定作業存在新能問題嚴重程度。

核心功能：

• 整合多個排程器框架如Azkaban、Airflow、Oozie等；

• 統計歷史作業和工作流的效能指標；

• Job級別工作流對比；

• 支援多個計算引擎框架效能診斷（Spark、Tez、MapReduce、TonY）；

• 基於自定義規則的可配置啟發式外掛，使用者診斷作業；

• 提供REST API, 使用者能透過API獲取所有資訊；

欠缺功能：

• 支援Spark, Hadoop系統版本比較低，對於新版本Spark, Hadoop相容性不友好；

• 不支援Spark, Hadoop新版本的特性的診斷；

• 診斷指標比較少，其中Spark相關指標僅4個，對於高度依賴Spark引擎是非常欠缺的；

• 不支援日誌級別問題診斷，不能夠診斷排程器執行任務或者App應用程式的出現的異常;

• 排程器和作業App後設資料的關聯在一些場景下不支援；

• 不支援異常資源的管理，達到降本增效指引目的；

• 對Spark History服務介面頻繁呼叫影響History服務的穩定性；

• 缺乏有效的降本增效流程輔組工具；

綜上所述，結合我們有大規模Spark叢集排程特點，業界產品對我們解決業務痛點效果不佳， 我們決定自研診斷系統來解決業務帶來的挑戰。

03 技術方案

由上述可知，系統在業務層面既能快速定位解決使用者問題，又能幫助使用者管理異常資源；架構層面支援Spark, Hadoop多指標診斷又不影響第三方系統效能問題，我們採用非入侵的方式設計診斷系統。

架構層主要由同步工作流層任務後設資料模組、同步Yarn/Spark App後設資料模組、關聯工作流層/引擎層App後設資料模組、工作流任務異常檢測模組，引擎層異常檢測模組，Portal展示模組組成。同時排程器（Scheduler Server）可以適配多個開源排程器專案, 如內部系統Oflow、Airflow、DolphinScheduler等。

整體架構圖

整體架構分3層：

• 第一層為對接外部系統，排程器、Yarn、HistoryServer、HDFS等系統，同步後設資料、叢集狀態、執行環境狀態、日誌等到診斷系統分析；

• 第二層為架構層, 包括資料採集、後設資料關聯&模型標準化、異常檢測、診斷Portal模組；

• 第三層為基礎元件層，包括MySQL、 Elasticsearch、Kafka、Redis等元件。

具體模組流程階段：

（1）資料採集階段：從排程系統將使用者、DAG、作業、執行記錄等工作流後設資料同步至診斷系統；定時同步Yarn ResourceManager、Spark HistoryServer App後設資料至診斷系統，標誌作業執行指標儲存路徑，為後續資料處理階段作基礎；

（2）資料關聯&模型標準化階段：將分步採集的工作流執行記錄、Spark App、Yarn App、叢集執行環境配置等資料透過ApplicationID介質進行關聯，此時，工作流層與引擎層後設資料已關聯完畢，得到資料標準模型 (user, dag, task, application, clusterConfig, time) ；

（3）工作流層&引擎層異常檢測階段：至此已經獲得資料標準模型，針對標準模型進一步Workflow異常檢測流程，同時平臺維護著一套沉澱多年的資料治理知識庫，載入知識庫到標準模型，透過啟發式規則，對標準模型的指標資料、日誌同時進行異常挖掘，結合叢集狀態及執行是環境狀態，分析得出工作流層、引擎層異常結果；

（4）業務檢視：儲存、分析資料，提供給使用者任務概覽、工作流層任務診斷、引擎層作業Application診斷，工作流層展示排程器執行任務引發的異常，如任務失敗、迴環任務、基線偏離任務等問題，計算引擎層展示Spark作業執行引發的耗時、資源使用、執行時問題；

04 實踐效果

我們從四個方面簡述診斷平臺帶來的效果：診斷平臺UI、效率分析、成本分析、穩定性分析、降本增效分析。

（1）診斷平臺UI

引擎層分析主要展示Spark計算過程中異常、不合理的作業，並給作業記錄異常標籤，如CPU浪費、資料傾斜、Task長尾、大表掃描等異常型別標籤，這些標籤是資料標準模型經過工作流層、引擎層異常檢測得出，同時可以讓使用者清楚作業的問題原因。

（2）效率分析

長尾Task分析

原因：長尾任務是由於作業執行過程中，一個Task或多個Task單元執行時間過長，拖延整個任務執行時間。

危害：作業執行時間過長，資源浪費

診斷：從時間角度計算，執行時間過長原因在於Task讀取資料量多或者資料讀取慢。如果讀取資料過多，那麼將出現資料傾斜，按資料傾斜方式處理；如果讀取資料過慢，那麼Hadoop叢集的節點負載高或者有網路丟包問題等，導致資料讀取慢，可以聯絡運維處理。

HDFS卡頓分析

原因：HDFS卡頓是Spark作業中Task最小執行單元讀取資料速率比其他Task慢，低於閾值；

危害：作業執行時間過長，浪費資源；

診斷：作業資料所在機器網路IO問題或者叢集配置不一致問題，導致Task從Hadoop讀取資料速率低下。這種情況一般伴隨著長尾Task出現，同時表現Task執行時間過長、讀取資料量少，導致整個資料處理Task無法高效利用回收。這種情況需排查資料在節點配置及機器硬體配置；

推測執行過多分析

原因：推測執行(speculative)是指作業執行單元Task在同一個Stage中的執行時間相比其他Task執行時間長，在其他Executor發起相同Task執行，先完成的Task將Kill另個Task, 並取得結果。這樣情況下如果作業大部分Task都發起推測執行，超過一定比例，就是推測執行過多的表現；

危害：任務執行時間長，資源浪費惡化；

診斷：機器配置不同、網路波動、叢集負載高、作業資料傾斜等都會引起推測執行，過多的慢任務執行推測將會導致資源惡化，推測執行其實是對資源的壓榨、用空間換取時間的做法。解決執行推測要從多方面入手，結合叢集狀態環境。

全域性排序異常分析

原因：Spark Stage中的Task只有一個時，而且處理的數量級別大，Stage中的所有資料都集中在一個Task中，這種情況即發生全域性排序異常。

危害：任務處理時間長、消耗資源大

診斷：全域性排序異常並沒有發揮Spark併發計算特性，Task處理資料漫長，非常消耗資源，解決這個問題需要對作業進行重新分割槽，併發計算資料。

（3）成本分析

CPU浪費分析

原因：Spark Driver/Executor cores引數配置不合理導致CPU空閒浪費

危害：沒用高效利用資源

診斷：透過Spark Application採集指標，分析Spark Driver、Spark Executor執行過程中的CPU的執行時間（單位: vcore·second）佔比，如果空閒時間超過一定的比例，判定為浪費，使用者根據比例降低啟用CPU數量。

計算Application CPU浪費過程中，採集到Executor執行開始和結束時間、Executor執行所有Job開始和結束時間、Job內部真正執行Task CPU時間,  最終獲得以下指標：

• 所有Executor的併發個數Count，每個Executor固定核數ExecutorCores

• 所有Executor內Job真正執行時間和JobTime（計算Job開始結束時間交叉和）

• 所有Executor內Task個數 TaskCount及每個Task執行CPU時間

總CPU計算時間估算為：

實際使用CPU計算時間為：

CPU浪費百分比：

如果空閒比很大，可以適當降低引數spark.executor.cores的值，降低併發度，或者減少RDD分割槽數和Shuffle引數spark.sql.shuffle.partitions。

記憶體浪費分析

原因：分析Driver/Executor記憶體使用峰值佔總記憶體比例，當空閒比例值超過閾值，為記憶體浪費

危害：沒用高效利用資源

診斷：採集Spark Application Driver/Executor的相關記憶體指標，與CPU浪費計算同理，獲得Executor指標如下：

• 所有Executor個數Count, 每個Executor記憶體ExecutorMemory

• 每個Executor執行時間

• 每個Executor執行過程記憶體峰值 

總的記憶體時間估算為：

實際記憶體時間為：

浪費記憶體百分比：

如果空閒比很大，可以適當降低引數spark.executor.memory的值；

（4）穩定性分析

全表掃描問題

原因：SparkSQL查詢大表資料時，沒有進行分割槽條件篩選，或者SQL比較複雜時，發生了全表掃描；

危害：作業執行時間長，叢集負載高，影響其他作業執行

診斷：Spark SQL掃描資料表時，儘管現在Spark對最佳化器已經有不少的最佳化，如謂詞下推、列裁剪、常量合併等，但都相對簡單，在沒分割槽的大表或者使用者Join大表和小表時，會出現全表掃描或者分割槽不合理暴力掃描情況。一旦執行了這種作業，一方面使用者長時間才能得到資料結果，另一方面平臺方承載作業掃描全表的壓力，作業會佔用叢集主要資源，拖慢其他作業。因此使用者需要根據具體業務做條件限制，調整Spark SQL以及對錶分割槽等。

資料傾斜分析

原因：資料傾斜是Task計算過程中Key分佈不均造成的，個別Key的資料特別多，超出計算節點的計算能力；

危害：會導致任務記憶體溢位、計算資源利用率低、作業執行時間超出預期；

診斷：資料傾斜發生時，大量的Map Stage資料傳送到Reduce Stage，Reduce Stage節點需要處理大量資料，其他依賴該節點將處於長時間等待狀態。比如Stage1依賴Stage0的執行執行結果，如果Stage0發生資料傾斜，導致執行過長或者直接掛起，Stage1將處於等待狀態，整個作業也一直掛起，這是資源將被這個作業佔有，但只有極少數Task在執行，造成計算資源浪費，利用率低；大量資料將集中在少數計算節點上，當資料量超出單個節點的記憶體範圍，最終記憶體溢位，導致任務失敗。一般出現在SQL欄位：join on, group by, partition by, count distinct等，解決資料傾斜常用方式有：

• 增大並行度spark.sql.shuffle.partitions，使得資料再次分配到不同Task；

• 過濾異常值的資料，過多冗餘值也會導致資料傾斜；

• SQL中group by或者RDD的reduceByKey新增key的隨機數打散Map, Reduce兩個階段資料，最後在Reduce階段將隨機數去掉；

• 表Join關聯時，可以使用Broadcast方式廣播小表資料，避免shuffle, 就不會發生資料傾斜；

Shuffle失敗分析

原因：由於作業配置、網路、作業系統、硬體多個因素，Shuffle在節點之間傳輸資料會失敗

危害：作業異常退出，資源浪費

診斷：作業計算過程中，Shuffle作為Spark MapReduce框架中的資料紐帶，經常出現失敗問題，問題可以分Shuffle Read和Shuffle Write兩部分。

由圖看出，Shuffle Write的分割槽（partition）數量跟MapTask（RDD）的數量一致，檔案被分割後，經運算元計算的中間排序結果臨時存放在各個Executor所在的本地磁碟，可以理解為Shuffle Write做了本地磁碟儲存檔案操作。Shuffle Read的分割槽數有Spark提供的一些引數控制，引數不合理將會導致Reduce Task異常，如資料傾斜，甚至OOM造成Executor退出，下游網路連線不上。由診斷抓取異常瞭解到原因後，從Shuffle的資料量和處理Shuffle資料的分割槽數兩個角度給出方案：

• 減少shuffle資料量，使用Broadcast Join或者去掉不必要欄位等；

• 有group by、Join、 reduce by、partition by等運算元操作可以透過shuffle的partitions引數，根據資料量或計算複雜度提高引數值，另外控制好並行度以及執行任務的總核數，官方推薦執行Task為核數的2-3倍；

• 提高Executor的記憶體，防止記憶體溢位或者JVM Crash;

• 提高Spark網路RPC通訊時間配置,可以讓資料處理完成等；

記憶體溢位

原因：Spark記憶體使用超出了容量造成記憶體溢位

危害：作業異常退出，資源浪費

診斷：按照Spark記憶體模型，使用者實際使用記憶體如下

使用者作業記憶體溢位分堆內和堆外兩種方式：

• 堆外記憶體溢位：表現為作業被Yarn節點Kill, 主要原因是MonitorMemory超出申請記憶體限制

• 堆內記憶體溢位：表現為JVM記憶體空間不足或者GC超出限制，任務內的資料量過多導致

定位到原因後，可以有多種處理方式：

• 提高executorMemory, 堆內記憶體增大；

• 降低executorCores, 減少並行度，處理資料量變少；

• 重新分配分割槽（repartition）, 對每個Task產生的RDD、Dataframe資料量減少等；

• 提高executorMemoryOverhead引數，堆外記憶體增大；

• 處理資料傾斜，如group by、reduce by等熱點key打散；

SQL其他常見問題分析

原因：SQL執行過程中沒許可權、表不存在、語法錯誤等；

危害：任務執行異常退出，浪費資源

診斷：具有SQL失敗特徵從指標資料或者日誌提取，使用者根據問題去申請相應許可權、建立表或者修正語法問題，能快速解決問題。

（5）降本增效

以上講述了常見的問題案例場景，這裡不再多介紹，接下來我們分析下降本增效。

透過作業層和引擎層分析識別異常、不合理任務，累計識別任務的記憶體、CPU資源，轉化為相應的成本，透過任務後設資料關聯，按個人、業務、部門三個維度彙總給使用者，並設定排名等機制，推進資料治理。

以下透過長期推進治理，可以看成本趨勢，使用者聚焦的任務問題得以改善。

05 總結與規劃

• OPPO大資料任務診斷平臺主要圍繞離線排程任務、計算引擎兩個方面對問題進行定位分析，使用豐富的知識庫，提供給使用者解決最佳化方案，同時達到降本增效的目的。

• 技術方面採用非入侵方案對接其他系統，保證了其他系統的安全性。系統架構基於啟發式規則定位、分析問題方式，但知識庫比較依賴人員經驗的積累，更深層次問題需要資料探勘演算法擴大檢測範圍，智慧化診斷。

• 另外，除了對Spark任務問題診斷，OPPO大資料診斷平臺還針對Flink任務進行異常、資源問題診斷，整體平臺包含Spark、Flink兩種計算引擎診斷，屆時將會對平臺（羅盤）進行開源。