別眨眼網

yarn的基本概念

yarn由兩部分組成：

ResourceManager 負責整個叢集資源的管理和分配

NodeManager 管理很多容器，容器中執行著正真的分散式計算程式，比如flink，或者spark。NodeManager需要向ResourceManager上報自己的任務執行情況，同時向ResourceManager發起資源申請

從客戶端向yarn提交的應用，最終都根據其資源需求，被放在NodeManager的容器中執行。yarn會對每個應用啟動一個ApplicationMaster，它負責收集和監控該應用在其它NodeManager容器中執行的分散式任務狀態，並和ResourceManager進行資源協調（具體同ResourceManager中的Scheuler）。圖中綠色的模組即為一個應用在NodeManager中的分散式執行結構。

ResourceManager由兩部分組成：

scheduler 只負責整個叢集的磁碟、cpu、網路、記憶體等資源的管理，並根據應用的需求分配資源

ApplicationManager 注意同應用的ApplicationMaster區分開。ApplicationManager主要負責初始化應用的ApplicationMaster容器，同時監控ApplicationMaster的執行狀態，並在其失敗後嘗試恢復。

總結來看：

yarn提供了一個分散式的資源管理和任務執行管理平臺。yarn相當於一個分散式的作業系統，管理資源和任務執行

其中的ResourceManager的ApplicationMananger負責管理應用的ApplicationMaster ApplicationMaster又負責管理自己具體的所有分散式任務

scheduler

hadoop 2。6。0提供了兩種scheduler

CapacityScheduler

Fair Scheduler

兩者都是基於佇列。前者是yahoo開源貢獻的，後者是facebook開源貢獻的。重點介紹Fair Scheduler ，也是cdh官方推薦的scheduler

最新的yarn版本支援更細粒度的資源管理。加入了ReservationSystem，可以對job的資源做deadline限制，以及可預期的任務做資源保留

叢集整體的資源定義

cpu， 記憶體。配置引數

fair scheduler簡介

配置demo

<？xml version=“1。0”？> 10000 mb，0vcores 90000 mb，0vcores 50 0。1 2。0 fair charlie 5000 mb，0vcores 0。5 <！—- Queue ‘secondary_group_queueue’ is a parent queue and may have user queues under it ——> 3。0 30 5

佇列的資源限制

佇列可以有子佇列

所有佇列都是root的子佇列

基於具體資源限制

10000 mb，0vcores 90000 mb，0vcores 50 0。1 2。0 fair

maxRunningApps是硬性限制，即便叢集有空閒資源，也無法超越該限制。

叢集擴容後，也不會跟著變化，所以該種限制不推薦

基於權重資源限制

1。0 drf * * 10。0 60。0 30。0

權重是基於比例劃分父佇列的所有資源

同級子佇列的權重相加不需要等於100，按他們相加的整體算比例

隨著叢集擴容、縮容動態比例調整

佇列執行狀態限制

100。3

maxRunningApps佇列最大執行應用

佇列分配到AM的資源比例

基於使用者和分組限制

user1，user2，user3，。。。 group1，group2，。。。userA，userB，userC，。。。 groupA，groupB，。。。

aclSubmitApps限制可以提交到佇列的使用者 -aclAdministerApps限制可以管理該佇列的使用者，比如殺死任務

佇列的資源搶佔

搶

使用權重時，為了最大化叢集資源利用率。在叢集空閒時，繁忙的Ａ佇列會獲得超出自己權重比例的資源，以使其快速執行。

但此時Ｂ佇列有一個任務需要執行，Ｂ佇列的資源被Ａ佇列佔用，Ｂ佇列只有等待Ａ佇列中的任務執行完成釋放屬於自己的資源

但如果Ａ佇列一直有任務執行，Ｂ佇列就要一直等下去，為了避免這種情況發生，需要引入搶佔機制

在Ｂ佇列中配置自己能忍耐的極限，超過則要求fair scheduler幫忙搶資源，殺死Ａ佇列中的任務，釋放資源

首先在yarn-site。xml中啟用搶佔功能

yarn。scheduler。fair。preemption true

然後在fair-scheduler。xml對應的佇列中配置

10。0 60 0。5

fairSharePreemptionThreshold （0到１的小數）當佇列獲得的資源小於

fairSharePreemptionThreshold乘以自己應獲得的資源

時，

fairSharePreemptionTimeout並且等待了60s，都還沒獲取自己要求的這個資源。那fair scheduler將會幫忙殺死Ａ佇列中的任務，分配資源給B佇列

被搶

那如果Ａ佇列本身的任務非常重要，不允許執行過程中被殺，那麼需要以下配置

10。0 false

allowPreemptionFrom 是否允許排程器從自己這搶走資源，預設為true

佇列內部資源排程策略

前面說了佇列之間透過權重、或具體大小來劃分叢集資源。但佇列內部對於先後提交的多個任務有以下幾種排程方式

fair FairSharePolicy

fifo FifoPolicy

drf DominantResourceFairnessPolicy

FairSharePolicy

基於記憶體做公平排程。而不不同應用對cpu的的需求

FifoPolicy

先進先出，優先保證先提交到佇列的應用所需要的所有資源，有空閒再給後續任務

DominantResourceFairnessPolicy

基於應用申請記憶體和cpu所在總資源的比例大小來選取佔絕對主導權的（dominant）比例

假設總的佇列資源是100 CPUs， 10000 GB Memory A應用程式需求的資源是：2 CPUs， 300 GB Memory，其申請各項的佔比為 2% of CPUs vs 3% of Memory B應用程式需求的資源是：6 CPUs， 100 GB Memory ，其申請的各項佔比為6% of CPUs vs 1% of Memory

所以A佔主導的記憶體申請，%3 B的佔主導的應該是cpu申請，%6

B的主導比例是Ａ的兩倍，所以Ｂ會獲得多餘Ａ兩倍的資源

對應論文：https：//people。eecs。berkeley。edu/~alig/papers/drf。pdf

佇列的分配規則

。 。

流程方式順序選擇規則，不匹配這下一條

規則的種類有

<！—— Put one of the other Queue Placement Policies here。 ——>

specifiedrule

user rule

primary rule

secondaryGroupExistingQueue

nestedUserQueue

default 和 reject

兜底，以上所有規則不滿足，default為使用預設規則，reject為直接拒絕掉

透過cdh的一個叢集資源劃分示例

azkaban離線計算，60%，可搶佔，不可被搶佔

flink實時計算，10%， 可搶佔，不可被搶佔

hueuser 即系查詢，30%，可搶佔，不可被搶佔

對應xml配置

<？xml version=“1。0” encoding=“UTF-8” standalone=“yes”？> 1。0 drf * * 1。0 drf 10。0 60 0。5 false drf 60。0 60 0。5 false drf 30。0 60 0。5 drf drf

基於組限制hue使用者

使用者組的方式進行佇列分配時，yarn的實現是在linux賬號體系下去拿該使用者對應的組。而預設你在hue中新建的賬號在hive的linux機器上沒有對應的使用者，所以上述配置在分組時，會異常，從而導致使用者無法在hue中做hive查詢。

所以後面新增新的hue使用者的流程是

在hue中新建一個使用者假設名為tom

去hiveserver 所在機器上新建同名使用者adduser tom

由於linux中新建使用者的預設primary group跟使用者名稱同名，這裡需要將其修改為hueser 組（該組我已在107上建立），所以需要接著執行命令usermod -g hueuser tom

參考資料

https：//stackoverflow。com/questions/13842241/can-we-use-both-fair-scheduler-and-capacity-scheduler-in-the-same-hadoop-cluster

https：//clouderatemp。wpengine。com/blog/2016/06/untangling-apache-hadoop-yarn-part-4-fair-scheduler-queue-basics/

歡迎關注我的個人公眾號"西北偏北UP"，記錄程式碼人生，行業思考，科技評論