基於yarn的公平調度實例

1. 場景描述
         假設遇到這樣的客戶，需要在公司內部的集羣上進行任務提交運行，客戶的任務是每天跑取一些比較簡單的mr程序（凌晨提交上來，需要在當天的6點之前運行結束），而公司內部自己需要用集羣做相應的計算，計算主要是每個月的月初開始執行，一共100多個mr，大概需要執行半個月（前提是mr一個個得提交，資源利用率比較低下）。爲了客戶任務和公司內部自己的任務能夠並行運行，同時確保在規定的時間內完成所有的任務，那麼需要提高資源利用率。
2. 解決方案
          引入基於yarn的公平調度方案，公司內部的任務每個月中只有前半個月是有任務執行的，而且執行的時候需要比較多的資源（100多個mr可以一起提交），客戶的任務是每天都需要執行，但是任務相對而言比較簡單，所以需要的資源相對較少，但是不排除以後客戶變多、任務變複雜的情況，這樣的話要麼添加集羣，要麼將公司內部的資源部分轉移到客戶部分。通過比較合理的配置資源方式，保證在規定的時間內能夠完成客戶和公司內部的所有任務（然後儘量縮短執行時間）。
3. 具體配置（基於CDH5.4.4）

   yarn.resourcemanager.scheduler.class	選擇org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler
   Fair Scheduler XML 高級配置代碼段（安全閥）	具體資源隊列的配置文件（xml）
   yarn.scheduler.fair.user-as-default-queue	false
   yarn.scheduler.fair.preemption	true
   yarn.scheduler.fair.sizebasedweight	true
   yarn.scheduler.fair.assignmultiple	fasle（如果設置成true適合集羣需要運行很多小任務的情況）

   yarn.scheduler.fair.allow-undeclared-pools	false
   yarn.scheduler.increment-allocation-mb	1G
   yarn.scheduler.increment-allocation-vcores	1
   yarn.scheduler.fair.continuous-scheduling-enabled	false
   yarn.scheduler.fair.locality-delay-node-ms	yarn.scheduler.fair.continuous-scheduling-enabled被禁用，該項無效
   yarn.scheduler.fair.locality-delay-rack-ms	yarn.scheduler.fair.continuous-scheduling-enabled被禁用，該項無效

   yarn.scheduler.fair.locality.threshold.node	採用默認
   yarn.scheduler.fair.locality.threshold.rack	採用默認

4. Fair Scheduler XML 高級配置代碼段（安全閥）
   基於測試環境，測試環境僅僅有3臺PC，一共有22G的memory和12個Vcores（下面的配置要視具體集羣大小來配置）
   

   <?xml version="1.0"?>
   <allocations>
     <!-- 客戶資源池配置 -->
     <queue name="cus">
       <minResources>7510 mb,4 vcores</minResources>
       <maxResources>22528 mb,12 vcores</maxResources>
       <maxRunningApps>50</maxRunningApps>
       <weight>2.0</weight>
       <schedulingPolicy>fair</schedulingPolicy>
       <aclSubmitApps>zhaosw</aclSubmitApps>
       <aclAdministerApps>u</aclAdministerApps>
       <minSharePreemptionTimeout>60</minSharePreemptionTimeout>
     </queue>
   
     <!-- 內部資源池配置 -->
     <queue name="ups">
       <minResources>11264 mb,6 vcores</minResources>
       <maxResources>18770 mb, 10 vcores</maxResources>
       <maxRunningApps>150</maxRunningApps>
       <weight>1.0</weight>
       <schedulingPolicy>fair</schedulingPolicy>
       <aclSubmitApps>qianjicheng</aclSubmitApps>
       <aclAdministerApps>u</aclAdministerApps>
       <minSharePreemptionTimeout>300</minSharePreemptionTimeout>
     </queue>
   
     <user name="qianjicheng">
       <maxRunningApps>150</maxRunningApps>
     </user>
   
     <user name="zhaosw">
       <maxRunningApps>50</maxRunningApps>
     </user>
   
     <userMaxAppsDefault>5</userMaxAppsDefault>
   
     <queuePlacementPolicy>
       <rule name="specified" create="false"/>
       <rule name="reject" />
     </queuePlacementPolicy>
   </allocations>

   以上每個參數的解釋見上一篇博客：點擊打開鏈接
   該配置產生的作用：
   1. 禁用不可控的default隊列（所有提交到default的作業被拒絕），提交任務不指定隊列該任務將被拒絕，指定不存在配置文件中的隊列該任務將被拒絕，每個用戶提交的任務只能指定到配置的隊列中（該項的配置貌似不起作用，具體原因需要查明）
      
   2. 不同的用戶提交到不同的資源隊列中（客戶在cus資源池運行，內部的任務在ups），這樣資源隔離，保證雙方任務能夠正常運行
   3. 客戶的任務具有較高的優先權獲得資源，客戶沒有任務提交時ups資源池將會取得cus的資源，但是爲了保證客戶提交任務能夠立即獲得部分資源，ups將會一直預留10%左右的資源給cus
5. 任務提交
   
   1. spark任務提交（spark-submit、spark-shell）需要額外加--queue ups指定具體的資源隊列
   2. hive任務提交  需要加執行語句（本地化的執行不需要）set mapreduce.job.queuename=ups; 或者在啓動hive的時候  hive --hiveconf mapreduce.job.queuename=ups; hive -e 提交同樣需要--hiveconf這個配置，hive -f 需要在hql文件中set這個queue
      
   3. hbase任務提交  正常提交，不受yarn的資源調度控制
   4. mr任務提交   加上參數-Dmapred.job.queue.name=ups
      
6. 說明
          該配置需要在實際的環境中進行測試，並且集羣的規模不同、任務數量、任務複雜度將會影響到以上的配置，以後一旦客戶的規模變大，將需要對部分參數進行調優