基于yarn的公平调度实例

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

相关文章