Yarn 调度器Scheduler

Yarn中,负责给应用分配资源的就是Scheduler。其实调度本身就是一个难题,很难找到一个完美的策略可以解决所有的应用场景。为此,Yarn提供了多种调度器和可配置的策略供我们选择。

在Yarn中有三种调度器可以选择:FIFO Scheduler Capacity SchedulerFair Scheduler

 

 FIFO Scheduler

FIFO Scheduler把应用按提交的顺序排成一个队列,这是一个先进先出队列,在进行资源分配的时候,先给队列中最头上的应用进行分配资源,待最头上的应用需求满足后再给下一个分配,以此类推。

FIFO Scheduler是最简单也是最容易理解的调度器,也不需要任何配置,但它并不适用于共享集群。大的应用可能会占用所有集群资源,这就导致其它应用被阻塞。在共享集群中,更适合采用Capacity Scheduler或Fair Scheduler,这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。

 

Capacity Scheduler

 

Capacity 调度器允许多个组织共享整个集群,每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列,然后再为每个队列分配一定的集群资源,这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外,队列内部又可以垂直划分,这样一个组织内部的多个成员就可以共享这个队列资源了,在一个队列内部,资源的调度是采用的是先进先出(FIFO)策略。

容量调度器 Capacity Scheduler 最初是由 Yahoo 最初开发设计使得 Hadoop 应用能够被多用户使用,且最大化整个集群资源的吞吐量,现被 IBM BigInsights 和 Hortonworks HDP 所采用。

Capacity Scheduler 被设计为允许应用程序在一个可预见的和简单的方式共享集群资源,即"作业队列"。Capacity Scheduler 是根据租户的需要和要求把现有的资源分配给运行的应用程序。Capacity Scheduler 同时允许应用程序访问还没有被使用的资源,以确保队列之间共享其它队列被允许的使用资源。管理员可以控制每个队列的容量,Capacity Scheduler 负责把作业提交到队列中。

Fair Scheduler

在Fair调度器中,我们不需要预先占用一定的系统资源,Fair调度器会为所有运行的job动态的调整系统资源。如下图所示,当第一个大job提交时,只有这一个job在运行,此时它获得了所有集群资源;当第二个小任务提交后,Fair调度器会分配一半资源给这个小任务,让这两个任务公平的共享集群资源。

需要注意的是,在下图Fair调度器中,从第二个任务提交到获得资源会有一定的延迟,因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源,大任务又获得了全部的系统资源。最终效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。

公平调度器 Fair Scheduler 最初是由 Facebook 开发设计使得 Hadoop 应用能够被多用户公平地共享整个集群资源,现被 Cloudera CDH 所采用。

Fair Scheduler 不需要保留集群的资源,因为它会动态在所有正在运行的作业之间平衡资源。

 

 

Capacity调度器配置使用

调度器的使用是通过yarn-site.xml配置文件中的

yarn.resourcemanager.scheduler.class参数进行配置的,默认采用Capacity Scheduler调度器

假设我们有如下层次的队列:

root

├── prod

└── dev

├── mapreduce

└── spark

下面是一个简单的Capacity调度器的配置文件,文件名为capacity-scheduler.xml。在这个配置中,在root队列下面定义了两个子队列proddev,分别占40%和60%的容量。需要注意,一个队列的配置是通过属性yarn.sheduler.capacity.<queue-path>.<sub-property>指定的,<queue-path>代表的是队列的继承树,如root.prod队列,<sub-property>一般指capacitymaximum-capacity

<configuration>

 <property>

    <name>yarn.scheduler.capacity.root.queues</name>

    <value>prod,dev</value>

  </property>

 <property>

    <name>yarn.scheduler.capacity.root.dev.queues</name>

    <value>mapreduce,spark</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.maximum-capacity</name>

    <value>75</value>

  </property>

  <property>

    <name>yarn.scheduler.capacity.root.dev.mapreduce.capacity</name>

    <value>50</value>

  </property>

   <property>

    <name>yarn.scheduler.capacity.root.dev.spark.capacity</name>

    <value>50</value>

  </property>

</configuration>
 
 
 
59
 
 
 
 
 
1
<configuration>
2
 
          
3
 <property>
4
 
          
5
    <name>yarn.scheduler.capacity.root.queues</name>
6
 
          
7
    <value>prod,dev</value>
8
 
          
9
  </property>
10
 
          
11
 <property>
12
 
          
13
    <name>yarn.scheduler.capacity.root.dev.queues</name>
14
 
          
15
    <value>mapreduce,spark</value>
16
 
          
17
  </property>
18
 
          
19
    <property>
20
 
          
21
    <name>yarn.scheduler.capacity.root.prod.capacity</name>
22
 
          
23
    <value>40</value>
24
 
          
25
  </property>
26
 
          
27
    <property>
28
 
          
29
    <name>yarn.scheduler.capacity.root.dev.capacity</name>
30
 
          
31
    <value>60</value>
32
 
          
33
  </property>
34
 
          
35
    <property>
36
 
          
37
    <name>yarn.scheduler.capacity.root.dev.maximum-capacity</name>
38
 
          
39
    <value>75</value>
40
 
          
41
  </property>
42
 
          
43
  <property>
44
 
          
45
    <name>yarn.scheduler.capacity.root.dev.mapreduce.capacity</name>
46
 
          
47
    <value>50</value>
48
 
          
49
  </property>
50
 
          
51
   <property>
52
 
          
53
    <name>yarn.scheduler.capacity.root.dev.spark.capacity</name>
54
 
          
55
    <value>50</value>
56
 
          
57
  </property>
58
 
          
59
</configuration>
 
 

我们可以看到,dev队列又被分成了mapreducespark两个相同容量的子队列。devmaximum-capacity属性被设置成了75%,所以即使prod队列完全空闲dev也不会占用全部集群资源,也就是说,prod队列仍有25%的可用资源用来应急。我们注意到,mapreducespark两个队列没有设置maximum-capacity属性,也就是说mapreducespark队列中的job可能会用到整个dev队列的所有资源(最多为集群的75%)。而类似的,prod由于没有设置maximum-capacity属性,它有可能会占用集群全部资源。

关于队列的设置,这取决于我们具体的应用。比如,在MapReduce中,我们可以通过mapreduce.job.queuename属性指定要用的队列。如果队列不存在,我们在提交任务时就会收到错误。如果我们没有定义任何队列,所有的应用将会放在一个default队列中。

注意:对于Capacity调度器,我们的队列名必须是队列树中的最后一部分,如果我们使用队列树则不会被识别。比如,在上面配置中,我们使用prodmapreduce作为队列名是可以的,但是如果我们用root.dev.mapreduce或者dev. mapreduce是无效的。

 

总结:

yarn的调度scheduler

  • 什么是调度?当集群繁忙的时候,各种程序都来申请资源,yarn如何分配资源的问题
  • 调度策略?
    • FIFO schduler 先进先出 所有的程序按照提交的时间排队 缺点:大job阻塞小job
    • capacity schduler 容量调度 把集群资源划分不同队列 大job提交大job 小的提交job

      缺点:每个队列内部还是fifo 某一个时期 某种任务够多 其他过少 导致浪费资源

    • fair scheduler 公平调度 队列内部动态的调整资源使用 尽量满足当下运行的所有程序

      缺点:释放资源的过程需要等待

  • 默认调度策略
    • Apache 官方版本: capacity schduler
    • CDH 商业版:fair scheduler 公平调度
    • 配置参数:yarn.resourcemanager.scheduler.class yarn-site.xml
  • capacity 调度示例
    • 动态平衡点概念 需要通过最大上限限制不断蚕食的现象
    • 如果分配了调度队列的层次 在提交程序的时候 必须指定清楚队列名称 否则就失败
      mapreduce.job.queuename = /root/dev/mapreduce 错误
      mapreduce.job.queuename =root.dev.mapreduce 错误
      mapreduce.job.queuename =mapreduce 正确 队列名必须是队列树中的最后一部分
       
       
       
       
       
       
       
       
       
      1
      mapreduce.job.queuename = /root/dev/mapreduce 错误
      2
      mapreduce.job.queuename =root.dev.mapreduce 错误
      3
      mapreduce.job.queuename =mapreduce 正确 队列名必须是队列树中的最后一部分
       
       
    • 如果用户不配置 默认capacity 全局只有一个队列 队列名/default

      而此时mr程序默认提交的队列名也是default 所以不指定 也可以提交成功

 



转载于:https://www.cnblogs.com/TiePiHeTao/p/5458afee4fb50ee4c16efb9a8aa94ce5.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值