OPPO大資料計算叢集資源排程架構演進

OPPO數智技術發表於2021-12-30

1 背景

隨著公司這兩年業務的迅速擴增,業務資料量和資料處理需求也是呈幾何式增長,這對底層的儲存和計算等基礎設施建設提出了較高的要求。本文圍繞計算叢集資源使用和資源排程展開,將帶大家瞭解叢集資源排程的整體過程、面臨的問題,以及我們在底層所做的一系列開發優化工作。

2 資源排程框架---Yarn

2.1 Yarn的總體結構

從大資料的整個生態體系來說,hadoop處於離線計算的核心位置。為了實現大資料的儲存和計算,hadoop1.0提供了hdfs分散式儲存以及mapreduce計算框架,雖然整體具備了大資料處理的雛形,但還不支援多型別的計算框架,如後來的spark、flink,這個時候也並沒有資源排程的概念。

到了hadoop2.0,為了減輕單臺服務節點的排程壓力,相容各個型別的排程框架,hadoop抽離出了分散式資源排程框架---YARN(Yet Another Resource Negotiator)。Yarn在整個架構中所處的地位如圖1:

圖1:Hadoop生態體系

Yarn通過優化後的雙層排程框架,將hadoop1.0中原本需要執行資源排程和任務排程的單點JobTracker分為Resourcemanager和ApplicationMaster兩個角色,分別負責叢集總體的資源排程和單個任務的管理排程,而新增的Nodemanager角色負責各計算節點的管理。Yarn任務提交流程如圖2:

圖2:Yarn任務提交過程

客戶端提交的任務實際由Resourcemanager直接處理,Resourcemanager為每一個任務啟動ApplicationMaster,任務資源申請由ApplicationMaster直接負責,這樣,各個框架通過實現自己的ApplicationMaster來管理任務,申請container作為資源,就能成功在yarn叢集將任務執行起來,資源的獲取對任務完全透明,任務框架和yarn完全解耦。

2.2 Yarn的排程策略

Yarn對於任務的排程在開源版本實現了3種策略,分別為先進先出(FIFO Scheduler)、容量排程(Capacity Scheduler)和公平排程(Fair Scheduler),經過社群版本演化,目前公平排程已經按佇列級別實現了公平機制,我們叢集採用的正是公平排程策略。

在瞭解幾種排程策略之前我們先理解一個概念:佇列。在Yarn中,佇列其實就是指資源池,如果把整個叢集的資源看做大的資源池的話,Yarn會根據使用者配置把這個資源池進一步劃分成小的資源池;父佇列可以進一步向下劃分,子佇列會繼承父佇列的資源並且不會超過父佇列的最大資源,整個資源佇列的組織形式就像一顆多叉樹。

先進先出和容量排程策略分別按任務提交順序和為任務劃分佇列的方式來組織任務,這兩種方式對生產環境來說並不是十分適用,因為我們的目的是讓儘可能多的任務執行起來,並且儘量充分利用叢集資源,而這兩種策略分別會導致任務堵塞以及資源浪費。

生產環境中的公平排程遵循這樣一種規則:保證任務資源分配的公平,當小任務提交過來沒資源時,排程器會將大任務釋放的資源留給小任務,保證了不會讓大任務一直佔有資源不釋放。三種排程策略的組織形式如圖3:

圖3:Yarn的三種排程策略

公平排程除了上述所說保證任務間的資源公平之外,還會動態調整佇列大小,保證佇列間的資源公平,調整依據是叢集實時負載,當叢集閒時,佇列基本能獲得配置的最大資源值;當叢集忙時,排程器優先滿足佇列最小值,滿足不了時會根據配置的最小值等引數來平均分配。

2.3 Yarn的聯邦排程

在單個叢集到達數千節點規模時,單臺Resourcemanager實際已經接近了排程的效能瓶頸,要想進一步擴大叢集規模社群給出的方案是通過聯邦排程橫向擴充套件。該方案的核心就在於Router,對外,Router提供了任務提交的統一入口;對內,Router管理了多套叢集,實際任務由Router負責轉發,轉發到哪個叢集由Router來決定。Router的實際工作流程如圖4:
圖4:Yarn的聯邦排程

可以看到,通過Router管理的聯邦排程方式,叢集的概念實際已經對使用者透明,並且在當某個叢集出現問題時,Router能通過配置及時進行故障轉移,將任務路由到健康的叢集,從而保證了整體叢集的對外服務穩定性。

3 OPPO計算叢集現狀

3.1 叢集規模和現狀

經過兩年多的叢集建設,目前我們的叢集已經達到了比較可觀的規模,在這樣的叢集規模下,維護穩定性其實是第一要務,我們對叢集做了不少穩定性方面的工作,如許可權管控、各項重要指標監控等。

除了部分穩定性建設的工作之外,另一個重點關注的是叢集資源使用率,當前大部分叢集資源使用有比較明顯的週期性規律,從圖5的叢集監控能看出叢集經常凌晨繁忙而白天相對空閒。

圖5:單個叢集資源使用率變化圖

叢集高峰期的資源緊張問題僅依靠叢集內部自身協調其實能取得的效果有限,我們針對這種情況是考慮在凌晨高峰期與k8s聯合排程,將空閒的線上資源協調部分到離線叢集,後文將對該方案進行詳細描述。

3.2 叢集pending問題

除了高峰期的資源緊張,我們發現在白天也會出現佇列任務大量pending的情況,我們對具體的pending任務進行分析,總結出了以下3種導致任務pending的問題:

  1. 佇列配置不合理:
    根據公平排程機制,佇列的實時可用資源很大程度由配置的最小值決定,某些佇列配置的最小值過小或為0會直接導致佇列無法獲取足夠的資源。另外,如果佇列配置的CPU和記憶體比例與實際執行的任務CPU記憶體比差距過大,也會導致資源不足任務無法執行。
  2. 使用者突然向某一佇列提交大量任務,資源使用量超出佇列上限:
    這種情況實際上與使用者自身的使用有關,當自身的任務量加大後,向我們提出申請來擴充佇列是比較合適的。
  3. 有大任務佔住資源不釋放,導致後續提交的任務申請不到啟動資源:

Spark或者Flink任務與傳統的Mapreduce任務執行機制不太一樣,這兩類任務會長期佔有資源不釋放,導致新提交任務無法及時獲取到資源。針對該問題,我們也設計了相應的資源搶佔機制,後文詳述。

總體來說,佇列配置很大程度上影響了作業的執行,合理地優化配置往往能達到事半功倍的效果。

3.3 叢集資源使用率現狀

從上文看出監控中的叢集大部分時間都處於繁忙狀態,但是我們通過統計單臺伺服器的資源使用,發現還有很多資源的空餘,如圖6所示:

圖6:單臺伺服器CPU和記憶體使用率

導致該問題的原因實際是使用者作業申請的資源經常遠超過實際需要的資源,我們統計發現95%的Container實際利用率低於76%, 99%的Container實際利用率低於90%。表明作業申請的資源大小存在"虛胖"問題。這部分浪費的資源如果能利用起來,其實能極大提高叢集資源使用率。我們針對這部分浪費資源的優化利用也會在後續一併討論。

4 Yarn的優化之路

4.1 Yarn聯邦排程的優化

社群的聯邦排程方案對於我們來說過於簡單,只是實現了簡單的加權隨機路由。在後續計劃中,我們會把更多的資源接入路由叢集中,Router服務會提供統一個佇列和任務管理,使用者只需要把任務統一提交到Router叢集,而不用關係具體到哪個叢集。Router會統計所有叢集的狀態和負載,尋找合適的資源排程給任務。

圖7:Yarn router動態路由

4.2 資源編配和超賣

資源變配和資源超賣的目的是為了提升每個節點的實際資源使用效率。

資源變配:基於歷史的統計值,在排程資源時,調整分配給container的資源更接近container實際需求的資源。經過我們的實踐,資源變配可以提升10-20%的資源使用效率。

資源超賣:每個container執行時,都會產生一定的碎片,nodemanager可以將自己管理資源碎片收集起來,插入一些額外的container上去。我們計劃通過一個額外的碎片排程器來完成這個過程,在碎片比較多時,啟動一些額外的container,碎片如果減少,這些額外container會被回收掉。

圖8:資源限售

圖9:資源超賣

4.3資源動態擴縮

為了解決資源波峰波谷的問題,我們正在與雲平臺合作,實現一個線上離線資源的混部框架,通過錯峰的資源排程,提升資源的整體使用率。排程過程主要通過Yarn Router和OKE兩個服務協調完成,在實時資源有空閒而離線資源緊張時,Yarn會向OKE申請資源,實時資源緊張時,OKE會向YARN申請回收這部分資源。同時,我們引入了自研的Remote Shuffle Service來提升動態Nodemanager的穩定性。

圖10:Yarn動態擴縮容

4.4 任務優先順序管理

在實踐過程中,我們發現使用者任務會有明顯的優先順序區別,因此我們計劃實現一個基於優先順序的公平排程器,來保障高優先順序任務的執行延時和效率。一個佇列下的資源會優先保障高優先順序任務,統一優先順序的任務之間公平分配資源。同時,我們也實現了任務搶佔功能,即使低階任務已經拿到了資源,高階別任務也可以用搶佔排程來強行獲取資源。

圖11:基於優先順序的公平排程

4.5 佇列許可權管理

Oppo yarn許可權採用神盾統一鑑權,每個使用者組在神盾申請佇列許可權。使用者通過hive,livy,或者flink等客戶端直接提交的任務,都會在神盾系統上進行使用者的認證和佇列的鑑權,無許可權的使用者會被拒絕訪問。

圖12:Yarn佇列許可權管理

5 總結

本文主要介紹了Yarn的基本工作原理及Yarn在OPPO的落地實踐,總體來說可以歸納為以下幾點:

  1. Yarn作為典型的雙層排程架構,突破了單層排程架構的資源和框架限制,使作業的執行和資源分配更加靈活。
  2. 如何優化作業pending與如何使資源利用最大化是所有排程系統都會面臨的問題,對此,我們可以從自己系統本身特點來分析,尋找適合自己的解決方案。我們認為分析可以基於現有的資料統計。
  3. 離線和線上業務的錯峰特性決定了單項業務無法充分利用所有伺服器資源,通過合適的排程策略組織這些資源將會極大降低伺服器成本。

作者簡介

Cheng OPPO後端工程師

主要負責YARN離線資源排程平臺的開發和建設工作,對大資料基礎平臺的建設有較豐富的經驗。

Zhejia OPPO高階資料平臺工程師

主要負責OPPO YARN叢集的開發和優化工作,在大資料計算任務排程方面有豐富的經驗。

獲取更多精彩內容,請掃碼關注[OPPO數智技術]公眾號

相關文章