鑽石舞台

1 背景

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

2 資源調度框架---Yarn

2.1Yarn的總體結構

從大數據的整個生態體系來說，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%。表明作業申請的資源大小存在"虛胖"問題。這部分浪費的資源如果能利用起來，其實能極大提高集群資源使用率。我們針對這部分浪費資源的優化利用也會在後續一併討論。

4Yarn的優化之路

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等客戶端直接提交的任務，都會在神盾系統上進行用戶的認證和隊列的鑒權，無權限的用戶會被拒絕訪問。