Hadoop yarn中Scheduler资源调度器

迈不过友情╰ 2022-05-27 06:17 283阅读 0赞

理想情况下，我们应用对Yarn资源的请求应该立刻得到满足，但现实情况资源往往是有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到相应的资源。在Yarn中，负责给应用分配资源的就是Scheduler。其实调度本身就是一个难题，很难找到一个完美的策略可以解决所有的应用场景。为此，Yarn提供了多种调度器和可配置的策略供我们选择。

双层调度框架：RM将资源分配给AM，AM将资源进一步分配给各个task
    基于资源预留的调度策略：资源不够时会为task预留，直到资源充足，与all or nothing策略不同（Mesos）
    多类型资源调度：采用DRF算法，目前仅支持CPU和内存两种资源
    提供多种资源调度器：FIFO Scheduler，Fair Scheduler，Capacity Scheduler
    多租户资源调度器：支持资源按比例分配，支持层级队列划分方式，支持资源抢占

在Hadoop中资源调度器有三种，默认的调度器是原始的基于队列的先入先出调度器(FIFO Scheduler)  
还有两个多用户调度器：公平调度器(Fair Scheduler)、计算能力调度器(Capacity Scheduler)

**YARN资源调度语义**

支持的语义

请求某个特定节点、机架上的特定资源量
    将某些节点加入或移除黑名单，不再为自己分配这些节点的资源
    请求归还某些资源

不支持的语义

请求任意节点、机架上的特定资源量
    请求一组或几组符合某种特质的资源
    超细粒度资源
    动态调整container资源

**YARN资源隔离方案**

支持内存和CPU两种资源隔离：内存是一种决定生死的资源，CPU是一种影响快慢的资源  
内存隔离：基于线程监控的方案，基于Cgroups的方案  
CPU隔离：默认不对CPU资源进行隔离，基于Cgroups的方案

## 1、FIFO 先入先出调度器 ##

![这里写图片描述][70]

FIFO Scheduler先入先出调度器（基于队列调度）是hadoop的默认调度器，它先按照作业的优先级高低，再按照到达时间的先后选择被执行的作业。将应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。

在FIFO中设置【作业优先级没有作用】，因为FIFO调度并不支持抢占，所以后来的高优先级的Job仍然会被先来低优先级的Job所阻塞。必须等待先进入队列的低优先级作作业执行完毕后才能执行。

FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。

**优点**：调度算法简单，JobTracker工作负担轻。  
**缺点**：忽略了不同作业的需求差异。例如如果类似于对海量数据进行统计分析的作业长期占据计算资源，那么在其后提交的交互型作业有可能迟迟得不到处理，从而影响用户体验。

## 2、Capacity Scheduler 计算能力调度 ##

Capacity调度器中会有很多队列，每个队列有一定的分配能力，在每个队列内会按照FIFO去分配集群资源。并且有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。  
![这里写图片描述][70 1]

**计算能力调度器 容量调度器Capacity Scheduler(Yahoo 开发)**

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

该调度默认情况下不支持优先级，但是可以在配置文件中开启此选项，如果支持优先级，调度算法就是带有优先级的FIFO。而且不支持优先级抢占，一旦一个工作开始执行，在执行完之前它的资源不会被高优先级作业所抢占。

为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交的作业所占资源量进行限定。调度时，首先按以下策略选择一个合适队列：计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值，选择一个该比值最小的队列；然后按以下策略选择该队列中一个作业：按照作业优先级和提交时间顺序选择 ，同时考虑用户资源量限制和内存限制。但是不可剥夺式。

本质上，Capacity Scheduler允许用户（使用队列进行定义）为每个用户或模拟一个独立的使用FIFO的MapReduce集群。每个队列都可以通过配置获得一定数量的task tracker资源用于处理map/reduce操作，调度算法将按照配置文件为队列分配相应的计算资源量。

**Capacity Scheduler内存管理**  
Capacity Scheduler能有效地对hadoop集群的内存资源进行管理，以支持内存密集型应用。作业对内存资源需求高时，调度算法将把该作业的相关任务分配到内存资源充足的task tracker上。在作业选择过程中，Capacity Scheduler会检查空闲的tasktracker上的内存资源是否满足作业要求。Tasktracker上的空闲资源（内存）数量值可以通过tasktracker的内存资源总量减去当前已经使用的内存数量得到，而后者包含在tasktracker向jobtracker发送的周期性心跳信息中。

## 3、Fair Scheduler 公平调度器 ##

公平调度器为任务分配资源的方法，其目的是随着时间的推移，让提交的作业获取等量的集群共享资源，让用户公平地共享集群。具体做法是：当集群上只有一个任务在运行时，它将使用整个集群，当有其他作业提交时，系统会将TaskTracker节点空间的时间片分配给这些新的作业，并保证每个任务都得到大概等量的CPU时间。  
![这里写图片描述][70 2]

**公平调度器（相当于时间片轮转调度）**

公平调度器目标是让每个用户公平共享集群的能力。如果只有一个作业，则这个作业会的到集群中所有的资源，随着作业数的增多，在MR1中闲置的任务槽会以”每个用户公平共享集群”这种方式分配。默认请款下每个用户都有自己的作业池，但不会因为作业数多就得到更多的资源(所以，他是以用户级别为单位进行资源分配的)。公平调度器支持抢占式机制，如果一个作业池一段时间未能公平共享集群资源，就会终止运行池中得到过多的资源的任务，把空任务槽给运行资源不够的作业池。

作业都被放在作业池中，在默认情况下，每个用户都有自己的作业池。当一个用户提交的作业数超过另一个用户时，不会因此而比后者获得更多集群资源。可以用map和reduce的任务槽数来定制作业池的最小容量，也可设置每个池的权重

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

另外Fair Scheduler支持抢占，所以，如果一个池在特定的一段时间内未得到公平的资源共享，它会中止运行池中得到过多资源的任务，以便把任务槽让给运行资源不足的池。

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

在使用公平调度器时，要将其放到hadoop类路径下，即lib目录下。然后设置mapreduce.jobtracker.taskshceduler属性为：org.apache.hadoop.mapreduce.FariScheduler。如果需要充分发挥其优势需要读取官方文档

## 4、其他调度器 ##

适用于异构集群的调度器LATE，现有的Hadoop调度器都是建立在同构集群的假设前提下，具体假设如下：

1）集群中各个节点的性能完全一样
    2）对于reduce task，它的三个阶段：copy、sort和reduce，用时各占1/3
    3）同一job的同类型的task是一批一批完成的，他们用时基本一样。

现有的Hadoop调度器存在较大缺陷，主要体现在探测落后任务的算法上：如果一个task的进度落后于同类型task进度的20%，则把该task当做落后任务(这种任务决定了job的完成时间，需尽量缩短它的执行时间)，从而为它启动一个备份任务（speculative task）。如果集群异构的，对于同一个task，即使是在相同节点上的执行时间也会有较大差别，因而在异构集群中很容易产生大量的备份任务。

LATE（Longest Approximate Time to End）调度器从某种程度上解决了现有调度器的问题，它定义三个阈值：

1.  SpeculativeCap，系统中最大同时执行的speculative task数目（推荐值为总slot数的10%）；
2.  SlowNodeThreshold（推荐值为25%）：得分（分数计算方法见论文）低于该阈值的node（快节点）上不会启动  
    speculative task；
3.  SlowTaskThreshold（推荐值为25%）：当task进度低于同批同类task的平均进度的SlowTaskThreshold时，会为该task启动speculative task。它的调度策略是：当一个节点出现空闲资源且系统中总的备份任务数小于SpeculativeCap时，（1）如果该节点是慢节点（节点得分高于SlowNodeThreshold），则忽略这个请求。 （2）对当前正在运行的task按估算的剩余完成时间排序 （3）选择剩余完成时间最大且进度低于SlowTaskThreshold的task，为该task启动备份任务。

**适用于实时作业的调度器Deadline Scheduler和Constraint-based Scheduler**

主要用于有时间限制的作业，即给作业一个deadline时间，让它在该时间内完成。实际上，这类调度器分为两种，软实时（允许作业有一定的超时）作业调度器和硬实时（作业必须严格按时完成）作业调度器。

Deadline Scheduler主要针对的是软实时作业，该调度器根据作业的运行进度和剩余时间动态调整作业获得的资源量，以便作业尽可能的在deadline时间内完成。

Constraint-based Scheduler主要针对的是硬实时作业，该调度器根据作业的deadline和当前系统中的实时作业运行情况，预测新提交的实时作业能不能在deadline时间内完成，如果不能，则将作业反馈给用户，让他重调整作业的deadline。

[70]: /images/20220527/6fe8241f5703480f936bf5ecbe6d9069.png
[70 1]: /images/20220527/6eff44c27b354238b178471ad65314a6.png
[70 2]: /images/20220527/11fbcc2ab443497ab4902f5224b7b094.png