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

一、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分區都不夠用的時候，才會觸發彈性擴容，往屬于自己的獨占分區中擴容資源。

二、對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分配最合適的分區。

三、實操演練

測試環境：指定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分區。

四、Hadoop Yarn on Kubernetes Pod 最佳實踐

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

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

通過Hadoop Yarn on Kubernetes Pod ?案對客戶的在線TKE集群資源使用進行優化后，集群閑時CPU使用率能提高500%。

在線集群閑時CPU占用

離在線混部后CPU占用

五、總結

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

作者簡介

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

點擊文末「閱讀原文」，了解騰訊云彈性 MapReduce更多信息~

騰訊云大數據

長按二維碼
關注我們

總結

以上是生活随笔為你收集整理的腾讯云EMR基于YARN针对云原生容器化的优化与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。