Hadoop集群三种作业调度算法介绍

jopen 9年前

Hadoop集群中有三种作业调度算法,分别为FIFO,公平调度算法和计算能力调度算法

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

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

计算能力调度
计算能力调度和公平调度有点类似,公平调度策略是以作业池为单位分配任务槽,而计算能力调度是以队列为单位分配tasktracker(集群中一个节 点),这种调度策略配置了多个队列,每个队列配置了最小额度的tasktracker数量,同公平调度策略类似,当一个队列有空闲的 tasktracker时,调度器会将空闲的分配给其他的队列,当有空闲的tasktracker时,由于这时候可能有多个队列没有得到最小额度的 tasktracker而又在申请新的,空闲的tasktracker会被优先分配到最饥饿的队列中去,如何衡量饥饿程度呢?可以通过计算队列中正在运行 的任务数与其分得的计算资源之间的比值是否最低来判断的,越低说明饥饿程度越高。
计算能力调度策略是以队列的方式组织作业的,所以一个用户的作业可能在多个队列中,如果不对用户做一定的限制,很可能出现在多个用户之间出现严重不公平的现象。所以在选中新作业运行时候,还需要考虑作业所属的用户是否超过了资源的限制,如果超过,作业不会被选中。
对于在同一个队列中,这种策略使用的是基于优先级的FIFO策略,但是不会抢占。