Hadoop YRAN 资源调度器

资源调度器背景

• 不同的应用程序有不同的服务质量要求（Quality of Service, QoS）

  • 批处理作业：耗时长，对完成时间一般没有严格要求
  • 交互式作业：期望能及时返回结果
  • 生产性作业：要求有一定的资源量保证

• 不用的应用程序对硬件资源需求量有区别

  • CPU密集型：过滤、统计等
  • I/O密集型：数据挖掘、机器学习作业等

FIFO First In First Out 先进先出 Yahoo! => Capacity Scheduler 最大化吞吐量和集群利用率调度 Facebook => Fair Scheduler 公平调度 额外可以参考 https://www.cnblogs.com/sodawoods-blogs/p/8877197.html Hadoop集群中有三种作业调度算法，分别为FIFO，公平调度算法和计算能力调度算法

先来先服务（FIFO）

Hadoop中默认的调度器FIFO，它先按照作业的优先级高低，再按照到达时间的先后选择被执行的作业。

FIFO比较简单，hadoop中只有一个作业队列，被提交的作业按照先后顺序在作业队列中排队，新来的作业插入到队尾。一个作业运行完后，总是从队首取下一个作业运行。这种调度策略的优点是简单、易于实现，同时也减轻了jobtracker的负担。但是它的缺点也是显然的，它对所有的作业都一视同仁，没有考虑到作业的紧迫程度，另外对小作业的运行不利。

公平调度策略

这种策略在系统中配置了任务槽，一个任务槽可以运行一个task任务，这些任务就是一个大的作业被切分后的小作业。当一个用户提交多个作业时，每个作业可以分配到一定的任务槽以执行task任务（这里的任务槽可以理解为可以运行一个map任务或reduce任务）。如果把整个hadoop集群作业调度跟操作系统的作业调度相比，第一种FIFO就相当于操作系统中早期的单道批处理系统，系统中每个时刻只有一道作业在运行，而公平调度相当于多道批处理系统，它实现了同一个时刻多道作业同时运行。由于 linux 是多用户的，若有多个用户同时提交多个作业会怎样？在这种策略中给每个用户分配一个作业池，然后给每个作业池设置一个最小共享槽个数，什么是最小共享槽个数呢？先要理解一个最小什么意思，最小是指只要这个作业池需要，调度器应该确保能够满足这个作业池的最小任务槽数的需求，但是如何才能确保在它需要的时候就有空的任务槽，一种方法是固定分配一定数量的槽给作业池不动，这个数量至少是最小任务槽值，这样只要在作业池需要的时候就分配给它就行了，但是这样在这个作业池没有用到这么多任务槽的时候会造成浪费，这种策略实际上是这样做的，当作业池的需求没有达到最小任务槽数时，名义上是自己的剩余的任务槽会被分给其他有需要的作业池，当一个作业池需要申请任务槽的时候若系统中没有了，这时候不会去抢占别人的（也不知道抢谁的啊），只要当前一个空的任务槽释放会被立即分配给这个作业池。

在一个用户的作业池内，多个作业如何分配槽这个可以自行选择了如FIFO。所以这种调度策略分为两级： 第一级，在池间分配槽，在多用户的情况下，每个用户分配一个作业池。 第二级，在作业池内，每个用户可以使用不同的调度策略。

计算能力(容量)调度

计算能力调度和公平调度有点类似，公平调度策略是以作业池为单位分配任务槽，而计算能力调度是以队列为单位分配tasktracker（集群中一个节点），这种调度策略配置了多个队列，每个队列配置了最小额度的tasktracker数量，同公平调度策略类似，当一个队列有空闲的tasktracker时，调度器会将空闲的分配给其他的队列，当有空闲的tasktracker时，由于这时候可能有多个队列没有得到最小额度的tasktracker而又在申请新的，空闲的tasktracker会被优先分配到最饥饿的队列中去，如何衡量饥饿程度呢？可以通过计算队列中正在运行的任务数与其分得的计算资源之间的比值是否最低来判断的，越低说明饥饿程度越高。

计算能力调度策略是以队列的方式组织作业的，所以一个用户的作业可能在多个队列中，如果不对用户做一定的限制，很可能出现在多个用户之间出现严重不公平的现象。所以在选中新作业运行时候，还需要考虑作业所属的用户是否超过了资源的限制，如果超过，作业不会被选中。 对于在同一个队列中，这种策略使用的是基于优先级的FIFO策略，但是不会抢占

• 资源表示模型
• 资源调度模型

• 资源抢占模型 YARN资源调度模型

• 双层资源调度模型

  • 第一层 RM => AM
  • 第二层 AM => Task

  • 分配资源的过程

    1. NM => heartbeat 汇报节点信息
    2. RM 接收到心跳，返回应答
    3. RM接收到 NM 信息后，会触发 NODE_UPDATE event
    4. RS 收到 NODE_UPDATE event 后，会按照一定的策略将该节点上的资源分配给各应用程序，并将结果存储到内存
    5. AM => RM 发送心跳 => 领取 container
    6. RM 收到 AM 的心跳信息后，心跳应答分配 container
    7. AM 收到 container 后，进一步分配给具体的任务

• 资源保证机制

YRAN 层级队列管理机制

其他调度器（除 Fair Scheduler）

06C952D3-F8AB-4234-8BCE-851ABE9AFD7C.png