[[379189]]

本文轉載自微信公眾號「Java大數據與數據倉庫」，作者老董。轉載本文請聯系Java大數據與數據倉庫公眾號。  

目錄

1. Yarn調度器介紹

• FIFO(先進先出調度器)
• Capacity(容量調度器)
• Fair(公平調度器)
• Fair與Capacity區別

2.Yarn調度器配置

• Fair
• Capacity配置(默認配置)
• FIFO

理想情況下，我們應用對Yarn資源的請求應該立刻得到滿足，但現實情況資源往往是有限的，特別是在一個很繁忙的集群，一個應用資源的請求經常需要等待一段時間才能的到相應的資源。在Yarn中，負責給應用分配資源的就是Scheduler。其實調度本身就是一個難題，很難找到一個完美的策略可以解決所有的應用場景。為此，Yarn提供了多種調度器和可配置的策略供我們選擇。YARN架構如下:

• ResourceManager(RM)：負責對各NM上的資源進行統一管理和調度，將AM分配空閑的Container運行并監控其運行狀態。對AM申請的資源請求分配相應的空閑Container。主要由兩個組件構成：調度器(Scheduler)和應用程序管理器(Applications Manager)。
• 調度器(Scheduler)：調度器根據容量、隊列等限制條件(如每個隊列分配一定的資源，最多執行一定數量的作業等)，將系統中的資源分配給各個正在運行的應用程序。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位是Container，從而限定每個任務使用的資源量。Scheduler不負責監控或者跟蹤應用程序的狀態，也不負責任務因為各種原因而需要的重啟(由ApplicationMaster負責)。總之，調度器根據應用程序的資源要求，以及集群機器的資源情況，為用程序分配封裝在Container中的資源。調度器是可插拔的，例如CapacityScheduler、FairScheduler。(PS：在實際應用中，只需要簡單配置即可)
• 應用程序管理器(Application Manager)：應用程序管理器負責管理整個系統中所有應用程序，包括應用程序提交、與調度器協商資源以啟動AM、監控AM運行狀態并在失敗時重新啟動等，跟蹤分給的Container的進度、狀態也是其職責。ApplicationMaster是應用框架，它負責向ResourceManager協調資源，并且與NodeManager協同工作完成Task的執行和監控。MapReduce就是原生支持的一種框架，可以在YARN上運行Mapreduce作業。有很多分布式應用都開發了對應的應用程序框架，用于在YARN上運行任務，例如Spark，Storm等。如果需要，我們也可以自己寫一個符合規范的YARN application。
• NodeManager(NM)：NM是每個節點上的資源和任務管理器。它會定時地向RM匯報本節點上的資源使用情況和各個Container的運行狀態;同時會接收并處理來自AM的Container 啟動/停止等請求。ApplicationMaster(AM)：用戶提交的應用程序均包含一個AM，負責應用的監控，跟蹤應用執行狀態，重啟失敗任務等。
• Container：是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM為AM返回的資源便是用Container 表示的。YARN會為每個任務分配一個Container且該任務只能使用該Container中描述的資源。

1. Yarn調度器介紹

1.1. FIFO (先進先出調度器)

FIFO Scheduler把應用按提交的順序排成一個隊列，這是一個先進先出隊列，在進行資源分配的時候，先給隊列中最頭上的應用進行分配資源，待最頭上的應用需求滿足后再給下一個分配，以此類推。FIFO Scheduler是最簡單也是最容易理解的調度器，也不需要任何配置，但它并不適用于共享集群。大的應用可能會占用所有集群資源，這就導致其它應用被阻塞。在共享集群中，更適合采用Capacity Scheduler或Fair Scheduler，這兩個調度器都允許大任務和小任務在提交的同時獲得一定的系統資源。下面“Yarn調度器對比圖”展示了這幾個調度器的區別，從圖中可以看出，在FIFO 調度器中，小任務會被大任務阻塞。

1.2. Capacity (容量調度器)

yarn-site.xml中默認配置的資源調度器。而對于Capacity調度器，有一個專門的隊列用來運行小任務，但是為小任務專門設置一個隊列會預先占用一定的集群資源，這就導致大任務的執行時間會落后于使用FIFO調度器時的時間。用這個資源調度器，就可以配置yarn資源隊列，這個后面后介紹用到。

1.3. Fair (公平調度器)

Fair調度器的設計目標是為所有的應用分配公平的資源(對公平的定義可以通過參數來設置)。在上面的“Yarn調度器對比圖”展示了一個隊列中兩個應用的公平調度;當然，公平調度在也可以在多個隊列間工作。舉個例子，假設有兩個用戶A和B，他們分別擁有一個隊列。當A啟動一個job而B沒有任務時，A會獲得全部集群資源;當B啟動一個job后，A的job會繼續運行，不過一會兒之后兩個任務會各自獲得一半的集群資源。如果此時B再啟動第二個job并且其它job還在運行，則它將會和B的第一個job共享B這個隊列的資源，也就是B的兩個job會用于四分之一的集群資源，而A的job仍然用于集群一半的資源，結果就是資源最終在兩個用戶之間平等的共享。在Fair調度器中，我們不需要預先占用一定的系統資源，Fair調度器會為所有運行的job動態的調整系統資源。當第一個大job提交時，只有這一個job在運行，此時它獲得了所有集群資源;當第二個小任務提交后，Fair調度器會分配一半資源給這個小任務，讓這兩個任務公平的共享集群資源。

a) 公平調度器，就是能夠共享整個集群的資源

b) 不用預先占用資源，每一個作業都是共享的

c) 每當提交一個作業的時候，就會占用整個資源。如果再提交一個作業，那么第一個作業就會分給第二個作業一部分資源，第一個作業也就釋放一部分資源。再提交其他的作業時，也同理。。。。也就是說每一個作業進來，都有機會獲取資源。

1.4. Fair Scheduler與Capacity Scheduler區別

• 資源公平共享：在每個隊列中，Fair Scheduler可選擇按照FIFO、Fair或DRF策略為應用程序分配資源。Fair策略即平均分配，默認情況下，每個隊列采用該方式分配資源
• 支持資源搶占：當某個隊列中有剩余資源時，調度器會將這些資源共享給其他隊列，而當該隊列中有新的應用程序提交時，調度器要為它回收資源。為了盡可能降低不必要的計算浪費，調度器采用了先等待再強制回收的策略，即如果等待一段時間后尚有未歸還的資源，則會進行資源搶占;從那些超額使用資源的隊列中殺死一部分任務，進而釋放資源
• 負載均衡：Fair Scheduler提供了一個基于任務數的負載均衡機制，該機制盡可能將系統中的任務均勻分配到各個節點上。此外，用戶也可以根據自己的需求設計負載均衡機制
• 調度策略靈活配置：Fiar Scheduler允許管理員為每個隊列單獨設置調度策略(當前支持FIFO、Fair或DRF三種)
• 提高小應用程序響應時間：由于采用了最大最小公平算法，小作業可以快速獲取資源并運行完成

2.Yarn調度器配置

yarn資源調度器是在yarn-site.xml中配置。

2.1. Fair Scheduler

Fair Scheduler的配置選項包括兩部分:

一部分在yarn-site.xml中，主要用于配置調度器級別的參數

一部分在一個自定義配置文件(默認是fair-scheduler.xml)中，主要用于配置各個隊列的資源量、權重等信息。

2.1.1 yarn-site.xml

yarn-site.xml介紹

<!– scheduler start –> 
<property> 
    <name>yarn.resourcemanager.scheduler.class</name> 
    <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value> 
    <description>配置Yarn使用的調度器插件類名；Fair Scheduler對應的是：org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</description> 
</property> 
<property> 
    <name>yarn.scheduler.fair.allocation.file</name> 
    <value>/etc/hadoop/conf/fair-scheduler.xml</value> 
    <description>配置資源池以及其屬性配額的XML文件路徑（本地路徑）</description> 
</property> 
<property> 
    <name>yarn.scheduler.fair.preemption</name> 
    <value>true</value> 
    <description>開啟資源搶占,default is True</description> 
</property> 
<property> 
    <name>yarn.scheduler.fair.user-as-default-queue</name> 
    <value>true</value> 
    <description>設置成true，當任務中未指定資源池的時候，將以用戶名作為資源池名。這個配置就實現了根據用戶名自動分配資源池。default is True</description> 
</property> 
<property> 
    <name>yarn.scheduler.fair.allow-undeclared-pools</name> 
    <value>false</value> 
    <description>是否允許創建未定義的資源池。如果設置成true，yarn將會自動創建任務中指定的未定義過的資源池。設置成false之后，任務中指定的未定義的資源池將無效，該任務會被分配到default資源池中。,default is True</description> 
</property> 
<!– scheduler end –> 

2.1.2 fair-scheduler.xml

假設在生產環境Yarn中，總共有四類用戶需要使用集群，production、spark、default、streaming。為了使其提交的任務不受影響，我們在Yarn上規劃配置了四個資源池，分別為production,spark,default,streaming。并根據實際業務情況，為每個資源池分配了相應的資源及優先級等,default用于開發測試目的.

ResourceManager上fair-scheduler.xml配置如下：

<?xml version="1.0"?> 
<allocations> 
    <queue name="root"> 
        <aclSubmitApps></aclSubmitApps> 
        <aclAdministerApps></aclAdministerApps> 
        <queue name="production"> 
            <minResources>8192mb,8vcores</minResources> 
            <maxResources>419840mb,125vcores</maxResources> 
            <maxRunningApps>60</maxRunningApps> 
            <schedulingMode>fair</schedulingMode> 
            <weight>7.5</weight> 
            <aclSubmitApps>*</aclSubmitApps> 
            <aclAdministerApps>production</aclAdministerApps> 
        </queue> 
        <queue name="spark"> 
            <minResources>8192mb,8vcores</minResources> 
            <maxResources>376480mb,110vcores</maxResources> 
            <maxRunningApps>50</maxRunningApps> 
            <schedulingMode>fair</schedulingMode> 
            <weight>1</weight> 
            <aclSubmitApps>*</aclSubmitApps> 
            <aclAdministerApps>spark</aclAdministerApps> 
        </queue> 
        <queue name="default"> 
            <minResources>8192mb,8vcores</minResources> 
            <maxResources>202400mb,20vcores</maxResources> 
            <maxRunningApps>20</maxRunningApps> 
            <schedulingMode>FIFO</schedulingMode> 
            <weight>0.5</weight> 
            <aclSubmitApps>*</aclSubmitApps> 
            <aclAdministerApps>*</aclAdministerApps> 
        </queue> 
        <queue name="streaming"> 
            <minResources>8192mb,8vcores</minResources> 
            <maxResources>69120mb,16vcores</maxResources> 
            <maxRunningApps>20</maxRunningApps> 
            <schedulingMode>fair</schedulingMode> 
            <aclSubmitApps>*</aclSubmitApps> 
            <weight>1</weight> 
            <aclAdministerApps>streaming</aclAdministerApps> 
        </queue> 
    </queue> 
    <user name="production"> 
        <!-- 對于特定用戶的配置:production最多可以同時運行的任務 --> 
        <maxRunningApps>100</maxRunningApps> 
    </user> 
    <user name="default"> 
        <!-- 對于默認用戶配置最多可以同時運行的任務 --> 
        <maxRunningApps>10</maxRunningApps> 
    </user> 
 
    <!-- users max running apps --> 
    <userMaxAppsDefault>50</userMaxAppsDefault> 
    <!--默認的用戶最多可以同時運行的任務 --> 
    <queuePlacementPolicy> 
        <rule name="specified"/>  
        <rule name="primaryGroup" create="false" /> 
        <rule name="secondaryGroupExistingQueue" create="false" /> 
        <rule name="default" queue="default"/> 
    </queuePlacementPolicy> 
</allocations> 

參數介紹:

• minResources:最少資源保證量，設置格式為“X mb, Y vcores”，當一個隊列的最少資源保證量未滿足時，它將優先于其他同級隊列獲得資源，對于不同的調度策略(后面會詳細介紹)，最少資源保證量的含義不同，對于fair策略，則只考慮內存資源，即如果一個隊列使用的內存資源超過了它的最少資源量，則認為它已得到了滿足;對于drf策略，則考慮主資源使用的資源量，即如果一個隊列的主資源量超過它的最少資源量，則認為它已得到了滿足。
• maxResources:最多可以使用的資源量，fair scheduler會保證每個隊列使用的資源量不會超過該隊列的最多可使用資源量。
• maxRunningApps:最多同時運行的應用程序數目。通過限制該數目，可防止超量Map Task同時運行時產生的中間輸出結果撐爆磁盤。
• weight:資源池權重,主要用在資源共享之時，weight越大，拿到的資源越多。比如一個pool中有20GB內存用不了，這時候可以共享給其他pool，其他每個pool拿多少，就是由權重決定的
• aclSubmitApps:可向隊列中提交應用程序的Linux用戶或用戶組列表，默認情況下為“*”，表示任何用戶均可以向該隊列提交應用程序。需要注意的是，該屬性具有繼承性，即子隊列的列表會繼承父隊列的列表。配置該屬性時，用戶之間或用戶組之間用“，”分割，用戶和用戶組之間用空格分割，比如“user1, user2 group1,group2”。
• aclAdministerApps:允許管理任務的用戶名和組;一個隊列的管理員可管理該隊列中的資源和應用程序，比如可殺死任意應用程序。
• minSharePreemptionTimeout ：最小共享量搶占時間。如果一個資源池在該時間內使用的資源量一直低于最小資源量，則開始搶占資源。
• schedulingMode/schedulingPolicy：隊列采用的調度模式，可以是fifo、fair或者drf。
• 管理員也可為單個用戶添加maxRunningJobs屬性限制其最多同時運行的應用程序數目。此外，管理員也可通過以下參數設置以上屬性的默認值：
• userMaxJobsDefault：用戶的maxRunningJobs屬性的默認值。
• defaultMinSharePreemptionTimeout ：隊列的minSharePreemptionTimeout屬性的默認值。
• defaultPoolSchedulingMode：隊列的schedulingMode屬性的默認值。
• fairSharePreemptionTimeout：公平共享量搶占時間。如果一個資源池在該時間內使用資源量一直低于公平共享量的一半，則開始搶占資源。

這樣，每個用戶組下的用戶提交任務時候，會到相應的資源池中，而不影響其他業務。隊列的層次是通過嵌套

元素實現的。所有的隊列都是root隊列的孩子，即使沒有配到元素里。Fair調度器中的隊列有一個權重屬性(這個權重就是對公平的定義)，并把這個屬性作為公平調度的依據。在這個例子中，當調度器分配集群7.5,1,1,0.5資源給production,spark,streaming,default時便視作公平,這里的權重并不是百分比。注意，對于在沒有配置文件時按用戶自動創建的隊列，它們仍有權重并且權重值為1。每個隊列內部仍可以有不同的調度策略。隊列的默認調度策略可以通過頂級元素進行配置，如果沒有配置，默認采用公平調度。盡管是Fair調度器，其仍支持在隊列級別進行FIFO調度。每個隊列的調度策略可以被其內部的元素覆蓋，在上面這個例子中，default隊列就被指定采用fifo進行調度，所以，對于提交到default隊列的任務就可以按照FIFO規則順序的執行了。需要注意，spark,production,streaming,default之間的調度仍然是公平調度。每個隊列可配置最大、最小資源占用數和最大可運行的應用的數量。

Fair調度器采用了一套基于規則的系統來確定應用應該放到哪個隊列。在上面的例子中，元素定義了一個規則列表，其中的每個規則會被逐個嘗試直到匹配成功。例如，上例第一個規則specified，則會把應用放到它指定的隊列中，若這個應用沒有指定隊列名或隊列名不存在，則說明不匹配這個規則，然后嘗試下一個規則。primaryGroup規則會嘗試把應用放在以用戶所在的Unix組名命名的隊列中，如果沒有這個隊列，不創建隊列轉而嘗試下一個規則。當前面所有規則不滿足時，則觸發default規則，把應用放在default隊列中。

當然，我們可以不配置queuePlacementPolicy規則，調度器則默認采用如下規則：

<queuePlacementPolicy> 
      <rule name="specified" /> 
      <rule name="user" /> 
</queuePlacementPolicy> 

上面規則意思是除非隊列被準確的定義，否則會以用戶名為隊列名創建隊列。還有一個簡單的配置策略可以使得所有的應用放入同一個隊列(default)，這樣就可以讓所有應用之間平等共享集群而不是在用戶之間。這個配置的定義如下：

<queuePlacementPolicy> 
     <rule name="default" /> 
</queuePlacementPolicy> 

實現上面功能我們還可以不使用配置文件，直接設置yarn.scheduler.fair.user-as-default-queue=false，這樣應用便會被放入default 隊列，而不是各個用戶名隊列。另外，我們還可以設置yarn.scheduler.fair.allow-undeclared-pools=false，這樣用戶就無法創建隊列了。

當一個job提交到一個繁忙集群中的空隊列時，job并不會馬上執行，而是阻塞直到正在運行的job釋放系統資源。為了使提交job的執行時間更具預測性(可以設置等待的超時時間)，Fair調度器支持搶占。搶占就是允許調度器殺掉占用超過其應占份額資源隊列的containers，這些containers資源便可被分配到應該享有這些份額資源的隊列中。需要注意搶占會降低集群的執行效率，因為被終止的containers需要被重新執行。可以通過設置一個全局的參數yarn.scheduler.fair.preemption=true來啟用搶占功能。此外，還有兩個參數用來控制搶占的過期時間(這兩個參數默認沒有配置，需要至少配置一個來允許搶占Container)：

minSharePreemptionTimeout 
fairSharePreemptionTimeout 

如果隊列在minimum share preemption timeout指定的時間內未獲得最小的資源保障，調度器就會搶占containers。我們可以通過配置文件中的頂級元素</defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout>為所有隊列配置這個超時時間;我們還可以在元素內配置元素來為某個隊列指定超時時間。</defaultminsharepreemptiontimeout>

與之類似，如果隊列在fair share preemption timeout指定時間內未獲得平等的資源的一半（這個比例可以配置），調度器則會進行搶占containers。這個超時時間可以通過頂級元素<defaultfairsharepreemptiontimeout style="font-size: inherit;color: inherit;line-height: inherit;">和元素級元素分別配置所有隊列和某個隊列的超時時間。上面提到的比例可以通過<defaultfairsharepreemptionthreshold style="font-size: inherit;color: inherit;line-height: inherit;">(配置所有隊列)和(配置某個隊列)進行配置，默認是0.5。</defaultfairsharepreemptionthreshold></defaultfairsharepreemptiontimeout>

需要注意的是，所有客戶端提交任務的用戶和用戶組的對應關系，需要維護在ResourceManager上，ResourceManager在分配資源池時候，是從ResourceManager上讀取用戶和用戶組的對應關系的，否則就會被分配到default資源池。在日志中出現”UserGroupInformation: No groups available for user”類似的警告。而客戶端機器上的用戶對應的用戶組無關緊要。

每次在ResourceManager上新增用戶或者調整資源池配額后，需要執行下面的命令刷新使其生效.

yarn rmadmin -refreshQueues yarn rmadmin -refreshUserToGroupsMappings

動態更新只支持修改資源池配額，如果是新增或減少資源池，則需要重啟Yarn集群.

Fair Scheduer各資源池配置及使用情況，在ResourceManager的WEB監控頁面上也可以看到: http://ResourceManagerHost:8088/cluster/scheduler

2.2 Capacity 配置

hadoop2.7默認使用的是Capacity Scheduler容量調度器

yarn-site.xml

<property> 
  <name>yarn.resourcemanager.scheduler.class</name> 
  <value>org.apache.hadoop.yarn.server.resourcemanager.capacity.CapacityScheduler</value> 
</property> 

Capacity 調度器允許多個組織共享整個集群，每個組織可以獲得集群的一部分計算能力。通過為每個組織分配專門的隊列，然后再為每個隊列分配一定的集群資源，這樣整個集群就可以通過設置多個隊列的方式給多個組織提供服務了。除此之外，隊列內部又可以垂直劃分，這樣一個組織內部的多個成員就可以共享這個隊列資源了，在一個隊列內部，資源的調度是采用的是先進先出(FIFO)策略。

一個job可能使用不了整個隊列的資源。然而如果這個隊列中運行多個job，如果這個隊列的資源夠用，那么就分配給這些job，如果這個隊列的資源不夠用了呢?其實Capacity調度器仍可能分配額外的資源給這個隊列，這就是“彈性隊列”(queue elasticity)的概念。

在正常的操作中，Capacity調度器不會強制釋放Container，當一個隊列資源不夠用時，這個隊列只能獲得其它隊列釋放后的Container資源。當然，我們可以為隊列設置一個最大資源使用量，以免這個隊列過多的占用空閑資源，導致其它隊列無法使用這些空閑資源，這就是”彈性隊列”需要權衡的地方。

假設我們有如下層次的隊列：

root 
├── prod 
└── dev 
    ├── eng 
    └── science 

下面是一個簡單的Capacity調度器的配置文件，文件名為capacity-scheduler.xml。在這個配置中，在root隊列下面定義了兩個子隊列prod和dev，分別占40%和60%的容量。需要注意，一個隊列的配置是通過屬性yarn.sheduler.capacity..指定的，代表的是隊列的繼承樹，如root.prod隊列，一般指capacity和maximum-capacity。

<?xml version="1.0"?> 
<configuration> 
    <property> 
        <name>yarn.scheduler.capacity.root.queues(/&eae) 
        <value>prod,dev</value> 
    </property> 
    <property> 
        <name>yarn.scheduler.capacity.root.dev.queues</tta*e>  
        <value>eng,science</value> 
    </property> 
    <property> 
        <name>yarn.scheduler.capacity.root.prod.capacity</name> 
        <value>40</value> 
    </property> 
    <property> 
        <name>yarn.scheduler.capacity.root.dev.capacity</name> 
        <value >60</value> 
    </property> 
    <property> 
        <name>yarn.scheduler.capacity.root.dev.maximuin-capacity</name> 
        <value>75</value> 
    </property> 
    <property> 
        <name>yarn.scheduler.capacity.root.dev.eng.capacity</name> 
        <value >50</value> 
    </property> 
    <property> 
        <name>yarn.scheduler.capacity.root.dev.science.capacity</name> 
        <value >50</value> 
    </property> 
</configuration> 

我們可以看到，dev隊列又被分成了eng和science兩個相同容量的子隊列。dev的maximum-capacity屬性被設置成了75%，所以即使prod隊列完全空閑dev也不會占用全部集群資源，也就是說，prod隊列仍有25%的可用資源用來應急。我們注意到，eng和science兩個隊列沒有設置maximum-capacity屬性，也就是說eng或science隊列中的job可能會用到整個dev隊列的所有資源(最多為集群的75%)。而類似的，prod由于沒有設置maximum-capacity屬性，它有可能會占用集群全部資源。Capacity容器除了可以配置隊列及其容量外，我們還可以配置一個用戶或應用可以分配的最大資源數量、可以同時運行多少應用、隊列的ACL認證等。

關于隊列的設置，這取決于我們具體的應用。比如，在MapReduce中，我們可以通過mapreduce.job.queuename屬性指定要用的隊列。如果隊列不存在，我們在提交任務時就會收到錯誤。如果我們沒有定義任何隊列，所有的應用將會放在一個default隊列中。

注意：對于Capacity調度器，我們的隊列名必須是隊列樹中的最后一部分，如果我們使用隊列樹則不會被識別。比如，在上面配置中，我們使用prod和eng作為隊列名是可以的，但是如果我們用root.dev.eng或者dev.eng是無效的。

2.3 FIFO Scheduler

yarn-site.xml文件

<property> 
  <name>yarn.resourcemanager.scheduler.class</name> 
  <value>org.apache.hadoop.yarn.server.resourcemanager.fifo.FifoScheduler</value> 
</property>