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

碼農談IT發表於2022-12-28

01 背景


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


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


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


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


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


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


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


02 業界產品


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


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


工作原理:


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等。


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

整體架構圖


整體架構分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異常檢測流程,同時平臺維護著一套沉澱多年的資料治理知識庫,載入知識庫到標準模型,透過啟發式規則,對標準模型的指標資料、日誌同時進行異常挖掘,結合叢集狀態及執行是環境狀態,分析得出工作流層、引擎層異常結果;


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


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


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


04 實踐效果


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


(1)診斷平臺UI


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


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


(2)效率分析


長尾Task分析

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


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

危害:作業執行時間過長,資源浪費

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


HDFS卡頓分析

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


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

危害:作業執行時間過長,浪費資源;

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


推測執行過多分析

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


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

危害:任務執行時間長,資源浪費惡化;

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


全域性排序異常分析

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


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

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

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


(3)成本分析


CPU浪費分析

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


原因: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時間

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

總CPU計算時間估算為:

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

實際使用CPU計算時間為:

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

CPU浪費百分比:

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


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


記憶體浪費分析


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


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

危害:沒用高效利用資源

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


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

  • 每個Executor執行時間

OPPO大資料診斷平臺設計與實踐
  • 每個Executor執行過程記憶體峰值 

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

總的記憶體時間估算為:

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

實際記憶體時間為:

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

浪費記憶體百分比:

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


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


(4)穩定性分析


全表掃描問題


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


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

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

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


資料傾斜分析


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


原因:資料傾斜是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失敗分析


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


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

危害:作業異常退出,資源浪費

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


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


由圖看出,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通訊時間配置,可以讓資料處理完成等;


記憶體溢位


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


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

危害:作業異常退出,資源浪費

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

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


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


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

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

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


定位到原因後,可以有多種處理方式:

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

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

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

  • 提高executorMemoryOverhead引數,堆外記憶體增大;

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


SQL其他常見問題分析


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


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

危害:任務執行異常退出,浪費資源

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


(5)降本增效


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


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


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


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


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


05 總結與規劃


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

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

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



#作者簡介


BobZhuang  OPPO高階資料平臺工程師


專注大資料分散式系統研發,曾就職於Kingsoft公司。


Xiaoyou Wang  OPPO資料平臺工程師


2019年加入OPPO,負責大資料系統相關設計和開發工作,擁有豐富的後端研發經驗。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024924/viewspace-2929781/,如需轉載,請註明出處,否則將追究法律責任。

相關文章