https://blog.csdn.net/mrzhangbaby/article/details/98256130
https://www.cnblogs.com/BYRans/p/5567650.html
http://itxw.net/article/372.html
集群资源是非常有限的,在多用户、多任务环境下,需要有一个协调者,来保证在有限资源或业务约束下有序调度任务,YARN资源调度器就是这个协调者。
YARN调度器有多种实现,自带的调度器为
- FIFO Scheduler
- Capacity Scheduler(默认的资源调度器)
- Fair Scheduler
YARN资源调度器均实现Resource Scheduler接口。是一个插拔式组件,用户可以通过配置参数来使用不同的调度器
FIFO Scheduler
- FIFO Scheduler把应用按提交的顺序排成一个队列,这是一个先进先出队列,在进行资源分配的时候,先给队列中先进去的应用进行分配资源,等待先进去的应用需求满足后再给下一个分配,以此类推。
- FIFO Scheduler是最简单也是最容易理解的调度器,也不需要任何配置,但它并不适用于共享集群。
- 缺点:大的应用可能会占用所有集群资源,这就导致其它应用被阻塞。
capacity Scheduler-容量调度
- 把资源划分为多个队列(队列还可以有子队列)
- 弹性队列(queue elasticity): 支持占用其他空闲队列资源。
通过为每个组织分配专门的队列,然后再为每个队列分配一定的集群资源,这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外,队列内部又可以垂直划分,这样一个组织内部的多个成员就可以共享这个队列资源了,在一个队列内部,资源的调度是采用的是先进先出(FIFO)策略。
弹性队列
- 一个job可能使用不了整个队列的资源。然而如果这个队列中运行多个job,如果这个队列的资源够用,那么就分配给这些job,如果这个队列的资源不够用了呢?其实Capacity调度器仍可能分配额外的资源给这个队列,这就是弹性队列(queue elasticity)的概念。
- 在正常的操作中,Capacity调度器不会强制释放Container,当一个队列资源不够用时,这个队列只能获得其它队列释放后的Container资源。当然,我们可以为队列设置一个最大资源使用量,以免这个队列过多的占用空闲资源,导致其它队列无法使用这些空闲资源,这就是弹性队列需要权衡的地方。
capacity scheduler中基于标签的调度机制
从Hadoop 2.6.0起YARN引入了一种新的调度策略:基于标签的调度机制。该机制的主要引入动机是更好地让YARN运行在异构集群中,进而更好地管理和调度混合类型的应用程序。
- 基本思想是: 用户可以为每个nodemanager标注几个标签,比如highmem,highdisk等,以表明该nodemanager的特性;同时,用户可以为调度器中每个队列标注几个标签,这样,提交到某个队列中的作业,只会使用标注有对应标签的节点上的资源。
- 举个例子: 比如最初你们的hadoop集群共有20个节点,硬件资源是32GB内存,4TB磁盘;后来,随着spark地流行,公司希望引入spark计算框架,而为了更好地运行spark程序,公司特地买了10个大内存节点,比如内存是64GB,为了让spark程序与mapreduce等其他程序更加和谐地运行在一个集群中,你们希望spark程序只运行在后来的10个大内存节点上,而之前的mapreduce程序既可以运行在之前的20个节点上,也可以运行在后来的10个大内存节点上,怎么办?
- 有了label-based scheduling后,这是一件非常easy的事情。
- 你需要按以下步骤操作:
- 步骤1:为旧的20个节点打上normal标签,为新的10个节点打上highmem标签;
- 步骤2:在capacity scheduler中,创建两个队列,分别是hadoop和spark,其中hadoop队列可使用的标签是nornal和highmem,而spark则是highmem,并配置两个队列的capacity和maxcapacity。 最终提交作业时指定队列和labels。
Fair Scheduler-公平调度
强调用户公平地使用资源。默认情况下Fair Scheduler根据内存资源对应用程序进行公平调度,通过配置可以修改为根据内存和CPU两种资源进行调度。
- 在Fair Scheduler中,不需要预先占用一定的系统资源,Fair Scheduler会动态调整应用程序的资源分配。例如,当第一个大job提交时,只有这一个job在运行,此时它获得了所有集群资源;当第二个小任务提交后,Fair调度器会分配一半资源给这个小任务,让这两个任务公平的共享集群资源。
- Fair Scheduler中,从第二个任务提交到获得资源会有一定的延迟,因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源,大任务又获得了全部的系统资源。
Fair Scheduler将应用程序支持以队列的方式组织,这些队列之间公平的共享资源。默认,所有的用户共享一个队列。如果应用程序在请求资源时指定了队列,那么请求将会被提交到指定的队列中。也可以通过配置,根据用户名称来分配队列。在每个队列内部,应用程序基于内存公平共享或FIFO共享资源。
- 举个例子,假设有两个用户A和B,他们分别拥有一个队列。当A启动一个job而B没有任务时,A会获得全部集群资源;当B启动一个job后,A的job会继续运行,不过一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个job并且其它job还在运行,则它将会和B的第一个job共享B这个队列的资源,也就是B的两个job会用于四分之一的集群资源,而A的job仍然用于集群一半的资源,结果就是资源最终在两个用户之间平等的共享。
Fair Scheduler允许为队列分配最小的共享资源量,这样可以保证某些用户、groups或者应用程序总能获取充足的资源。当一个队列中有正在运行的应用程序时,它至少能够获取设置的最小资源,当队列中无任务时,它的资源将会被拆分给其他运行中的任务。
Fair Scheudler在默认情况下允许所有的任务运行,但是这也可以通过配置文件来限制每个用户下和每个队列下运行的任务个数。处于限制时,新提交的任务不会提交失败,而是在Scheduler queue中等待,直到先前的任务结束,再执行