基于yarn的公平调度实例

场景描述
假设遇到这样的客户，需要在公司内部的集群上进行任务提交运行，客户的任务是每天跑取一些比较简单的mr程序（凌晨提交上来，需要在当天的6点之前运行结束），而公司内部自己需要用集群做相应的计算，计算主要是每个月的月初开始执行，一共100多个mr，大概需要执行半个月（前提是mr一个个得提交，资源利用率比较低下）。为了客户任务和公司内部自己的任务能够并行运行，同时确保在规定的时间内完成所有的任务，那么需要提高资源利用率。
解决方案
引入基于yarn的公平调度方案，公司内部的任务每个月中只有前半个月是有任务执行的，而且执行的时候需要比较多的资源（100多个mr可以一起提交），客户的任务是每天都需要执行，但是任务相对而言比较简单，所以需要的资源相对较少，但是不排除以后客户变多、任务变复杂的情况，这样的话要么添加集群，要么将公司内部的资源部分转移到客户部分。通过比较合理的配置资源方式，保证在规定的时间内能够完成客户和公司内部的所有任务（然后尽量缩短执行时间）。

具体配置（基于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	采用默认

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>

以上每个参数的解释见上一篇博客：点击打开链接
该配置产生的作用：

禁用不可控的default队列（所有提交到default的作业被拒绝），提交任务不指定队列该任务将被拒绝，指定不存在配置文件中的队列该任务将被拒绝，每个用户提交的任务只能指定到配置的队列中（该项的配置貌似不起作用，具体原因需要查明）
不同的用户提交到不同的资源队列中（客户在cus资源池运行，内部的任务在ups），这样资源隔离，保证双方任务能够正常运行
客户的任务具有较高的优先权获得资源，客户没有任务提交时ups资源池将会取得cus的资源，但是为了保证客户提交任务能够立即获得部分资源，ups将会一直预留10%左右的资源给cus

任务提交
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
说明
该配置需要在实际的环境中进行测试，并且集群的规模不同、任务数量、任务复杂度将会影响到以上的配置，以后一旦客户的规模变大，将需要对部分参数进行调优

秒客网

基于yarn的公平调度实例

相关文章