騰訊雲EMR基於YARN針對雲原生容器化的優化與實踐

​導語 | 傳統HADOOP生態系統使用YARN管理/調度計算資源，該系統⼀般具備明顯的資源使⽤週期。實時計算集羣資源消耗主要在⽩天，而數據報表型業務則安排在離線計算集羣中。離在線業務分開部署的首要問題就是資源使用率低，消耗成本⾼。隨着業務的增⻓和突發的報表計算需求，爲了解決爲離線集羣預留資源，騰訊雲EMR團隊和容器團隊聯合推出Hadoop Yarn on Kubernetes Pod，以提⾼容器資源使用率，下降資源成本，將閒時容器集羣CPU使⽤率提高數倍之多。本文主要介紹HADOOP資源調度器YARN在容器環境中的優化與實踐。

1、Hadoop Yarn on Kubernetes Pod 混合部署模式

Hadoop Yarn on Kubernetes Pod 方案提供彈性擴縮容和離在線混合部署兩項功能。彈性擴縮容主要聚焦於如何利⽤雲原生資源，快速擴容資源以補充算力。離在線混合部署模式的目的是爲了充分使用在線集羣的空閒資源，儘量減小爲離線集羣預留空閒資源的頻次。

EMR彈性擴縮容模塊（yarn-autoscaler）提供按負載和按時間彈性伸縮兩種擴縮容方式。對於按負載伸縮，用戶能夠對不一樣指標設置閾值來觸發擴縮容，好比設置Yarn隊列中availablevcore、 pending vcore、available mem、pending mem。亦可使用時間擴縮規則，按天、按周、按月等規則指定觸發。

當彈性規則被觸發後，離在線部署模塊獲取當前在線TKE集羣中能夠提供的閒置算力的規格及數量，調用Kubernetes api建立對應數量的資源，ex-scheduler擴展調度器確保Pod被建立在剩餘資源更多的節點上，該POD負責啓動YARN的服務。

經過該方案，Yarn的NodeManager服務能夠快速部署到POD節點中。但也Yarn原生調度沒有考慮異構資源，由此引起了兩個問題：

1. AM的POD被驅逐，致使APP失敗

在node節點的資源緊缺的條件下，kubelet爲了保證node節點的穩定性，回觸發主動驅逐pod的機制。若是該節點存在AM服務，則整個Application就要被視爲失敗，ResourceManager此時會從新分配AM。對於計算量很大的任務，Application重跑的代價不可承受。

2. Yarn原生非獨佔分區資源共享侷限性

Yarn的標籤分區特性⽀持獨佔分區（Exclusive），非獨佔分區（Non-exclusive）。

• 獨佔分區（Exclusive）：例如指定獨佔分區x，Yarn的container只會分配到該x分區。
• 非獨佔分區（Non-exclusive）：例如非獨佔分區x，x分區的資源能夠共享給default分區。

只有當指定分區default時，default上運⾏的Application可使⽤分區x的資源。

可是在實際使⽤場景中，⽤戶要給各個業務部門分配各自的獨佔分區資源，同時會劃分出供各部門使用的default分區。default分區資源會比較充足，業務部門但願可以使用本身的獨佔分區和同時充分利用default分區資源，獨佔分區資源和default分區都不夠用的時候，纔會觸發彈性擴容，往屬於本身的獨佔分區中擴容資源。

2、對Yarn改造帶來的挑戰

對上述feature的開發，除了需求技術本⾝的難度。還須要考慮到儘量下降用戶存量集羣穩定性的影響，減小用戶業務側改形成本。

• 集羣穩定性：Hadoop Yarn做爲大數據系統中的基礎調度組件，若是改動過多，引起的故障概率就會增大。同時引入的feature,必然須要升級存量集羣的Haoop Yarn。升級操做要作到對存量業務集羣無感知，不能影響到當天的業務。
• 業務側使用成本：引入的新feature也必須符合原⽣yarn的使用習慣，方便業務側用戶理解，同時下降業務側對代碼的改造。

1. AM自主選擇存儲介質

目前Yarn的社區沒有考慮雲上異構資源混合部署的特色。在線TKE集羣中，當資源緊張時會對容器進行驅逐。爲了不Appliction從新計算，浪費資源的現象，必須提供AM能夠指定可否分配到POD 類型資源。

自主選擇存儲介質中，使用配置化標識，由NodeManager經過RPC上報可否將資源提供給AM使用，ResourceManager經過上報信息決定將Application的AM分配到穩定資源介質中。由NodeManager經過配置化上報信息的好處是顯而易見的：

• 去集中化：減小ResourceManager處理邏輯。不然，擴容資源時，還需將資源信息經過RPC/配置流入到ResourceManager中。如無必要，勿增實體，對ResourceManager的改造應該輕量化。
• 集羣穩定性：存量業務集羣對Yarn升級後，須要重啓NodeManager, 只須要重啓ResourceManager。Yare的高可用特性可保證升級過程對業務無影響。無需重啓NodeManager 的緣由是，NM默認將本機資源視爲可分配。
• 簡單易用：用戶能夠經過配置⾃由決定任務資源擁有分配AM的權利，不僅僅侷限POD容器資源。

2. 多標籤動態分配資源

Yarn的原生標籤設計中，提交任務時的標籤表達式中只能含有單個標籤。若是爲了提⾼利用率，同時使用多個分區資源，就必須將非default分區設置爲Non-exclusive特性。標籤表達式必須解決以下三個問題：

• 資源隔離：分區A設置Non-exclusive後，資源被其餘分區上的APP佔用後，沒法及時交換給分區A的App。
• 自由共享資源：只有default分區纔有資格申請Non-exclusive分區資源。
• 動態選擇分區資源：多分區資源共享時，沒法根據分區剩餘資源大小選擇可用區，影響任務執行效率。

騰訊雲EMR團隊經過支持擴展表達式語法，增長對邏輯運算符表達式的支持，使App能夠申請多個分區資源。同時開發資源統計模塊動態統計分區可用資源，爲App分配最合適的分區。

3、實操演練

測試環境：指定172.17.48.28/172.17.48.17的NodeManager爲default分區，172.17.48.29/172.17.48.26的NodeManager爲x分區。

隊列設置：

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>a,b</value>
</property>
​
​
<property>
<name>yarn.scheduler.capacity.root.accessible-node-labels.x.capacity</nam e>
<value>100</value>
</property>
​
​
<property>
<name>yarn.scheduler.capacity.root.accessible-node-labels.y.capacity</nam e>
<value>100</value>
</property>
​
​
<!-- configuration of queue-a -->
<property>
<name>yarn.scheduler.capacity.root.a.accessible-node-labels</name>
<value>x</value>
</property>
​
​
<property>
<name>yarn.scheduler.capacity.root.a.capacity</name>
<value>50</value>
</property>
​
​
<property>
<name>yarn.scheduler.capacity.root.a.accessible-node-labels.x.capacity</n ame>
<value>100</value>
</property>
​
​
<!-- configuration of queue-b -->
<property>
<name>yarn.scheduler.capacity.root.b.accessible-node-labels</name>
<value>y</value>
</property>
​
​
<property>
<name>yarn.scheduler.capacity.root.b.capacity</name>
<value>50</value>
</property>
​
​
<property>
<name>yarn.scheduler.capacity.root.b.accessible-node-labels.y.capacity</n ame>
<value>100</value>
</property>
​
​
</configuration>

1. 規定AM只能分配在172.17.48.28

對另外三個節點的NodeManager節點配置以下配置項:

yarn.nodemanager.am-alloc-disabled = true

配置後，提交的Application的AM只能在172.17.48.28節點啓動。

2. 使用組合標籤

經過mapreduce.job.node-label-expression指定標籤表達式，x||表示同時使用x/default分區。

hadoop jar /usr/local/service/hadoop/share/hadoop/mapreduce/hadoop-mapredu ce-examples-3.1.2.jar pi -D mapreduce.job.queuename="a" -D mapreduce.job. node-label-expression="x||" 10 10

使用該命令提交後，觀察到Application的container被分配在x/default分區。

4、Hadoop Yarn on Kubernetes Pod 最佳實踐

該客戶大數據應用和存儲跑在Yarn管理的大數據集羣，在生產環境中，面臨諸多問題，主要體如今大數據的算力不足和在線業務波谷時資源的浪費。如離線計算在算力不足時，數據準時性沒法獲得保證，尤爲是當遇到隨機緊急大數據查詢任務，沒有可用的計算資源，只能停掉已有的計算任務，或者等已有任務完成，⽆論哪一種⽅式，整體任務執行的效率都會大打折扣。

基於Hadoop Yarn on Kubernetes Pod 方案，將離線任務自動擴容至雲上集羣，與TKE在線業務集羣混合部署，充分利用雲上波谷時段的閒置資源，提升離線業務的算力，並利用雲上資源快速的彈性擴容能力，及時補充離線計算的算力。

經過Hadoop Yarn on Kubernetes Pod ⽅案對客戶的在線TKE集羣資源使用進下優化後，集羣閒時CPU使用率能提升500%。

5、總結

本文提出了基於YARN針對雲原生容器化的優化與實踐，在混合部署雲原生環境中，極大地提升了任務運行的穩定性，高效性，有效提升了集羣資源利用率，節約硬件成本。在將來，咱們會探討更多大數據雲原生場景，爲企業客戶帶來更多的實際效益。

做者簡介

張翮，騰訊雲高級工程師，目前主要負責騰訊雲大數據產品彈性MapReduce的管控相關模塊，和重要組件Hive的技術研發。向Apache Hive，Apache Calcite開源項目貢獻過代碼，畢業於電子科技大學。