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兩種計算引擎診斷,屆時將會對平臺(羅盤)進行開源。
#作者簡介
BobZhuang OPPO高階資料平臺工程師
專注大資料分散式系統研發,曾就職於Kingsoft公司。
Xiaoyou Wang OPPO資料平臺工程師
2019年加入OPPO,負責大資料系統相關設計和開發工作,擁有豐富的後端研發經驗。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024924/viewspace-2929781/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 魅族大資料之流平臺設計部署實踐大資料
- 工商銀行打造線上診斷平臺的探索與實踐
- B站大資料系統診斷實踐-SQLSCAN篇大資料SQL
- 案例|政務大資料平臺資料安全建設實踐大資料
- QCon-OPPO資料平臺Cloud Lake 降本增效實踐Cloud
- OPPO大資料離線計算平臺架構演進大資料架構
- 基石視覺化資料分析平臺設計實踐視覺化
- AI助力-58恆星資料標註平臺的設計與實踐AI
- 愛奇藝大資料實時分析平臺的建設與實踐大資料
- 美圖大資料平臺架構實踐大資料架構
- vivo霍金實驗平臺設計與實踐-平臺產品系列02
- 基於雲端計算的大資料平臺基礎設施建設實踐 排序大資料排序
- 大語言模型與資料庫故障診斷模型資料庫
- vivo統一告警平臺設計與實踐
- 美團酒旅起源資料治理平臺的建設與實踐
- SQL on Hadoop在快手大資料平臺的實踐與優化SQLHadoop大資料優化
- JuiceFS 在大搜車資料平臺的實踐UI
- 大資料平臺架構設計探究大資料架構
- 大資料平臺安全標準設計大資料
- 百分點萬億級大資料平臺的建設實踐大資料
- DataPipeline在大資料平臺的資料流實踐API大資料
- 將軍令:資料安全平臺建設實踐
- 餘利華:網易大資料平臺架構實踐分享!大資料架構
- 企業大資料平臺MapReduce應用之Join實踐!大資料
- [平臺建設] Spark任務的診斷調優Spark
- [平臺建設] HBase平臺建設實踐
- 高途資料平臺遷移與成本治理實踐
- vivo 實時計算平臺建設實踐
- 騰訊資料平臺 SaaS 化實踐
- 美團圖資料庫平臺建設及業務實踐資料庫
- OWI效能診斷與調整實踐指南(1~4)
- 淺談因果推斷與在內容平臺的實踐
- 網易考拉規則引擎平臺架構設計與實踐架構
- 大資料開發實戰:實時資料平臺和流計算大資料
- O2O行業資料平臺實戰:從監控到診斷的資料產品搭建行業
- 大資料開發平臺(Data Platform)在有讚的最佳實踐大資料Platform
- 實踐:大資料平臺1.0總結和2.0演化路線大資料
- 【流沙】宜信安全資料平臺實踐