hadoop之YARN

在YARN中，资源调度器（Scheduler），是ResourceManager中的重要组件，主要负责对整个集群（CPU，内存）的资源进行分配和调度，分配以资源Container的形式分发到各个应用程序中（如MapReduce作业），
应用程序与资源所在节点的NodeManager协作利用Container完成具体的任务（如Reduce Task)。
	
框架默认提供了三种Scheduler：
1）FIFO Scheduler：
先进先出即先来后到。
2）Capacity Scheduler：
以Capacity为中心，把资源划分到若干个队列中，各个队列内根据自己的逻辑分配资源。例如队列A可以调度的资源可以占80%，队列B占有剩下的20%，各队列接受相应的作业请求。
3）Fair Scheduler：
秉承公平性原则，尽可能让各个作业得到的资源平均。作业2提交之后，原本Job1占有的资源拨出一半给作业2。

采用Capacity调度的集群，资源被划分到一系列的Queue中，每个队列管理整个集群资源的一部分。队列内部可以再嵌套，形成层级结构。队列内资源采用FIFO的方式。
通常情况下，作业不能使用超过队列容量的资源，但是如果有空闲的资源，则调度器会为作业分配资源，即使这会导致队列超出容量限制。该特性叫队列弹性。
	
为了避免占用过多其他队列的资源，可配置一个最大容量，队列只能使用该容量以内的资源，但是会牺牲一定的弹性。在这个层次结构中，root队列下定义了prod和dev两个队列，假设占有集群资源容量的比例分别为40%和60%。
dev下又分为各占50%容量的eng和science队里。队列划分好之后，应用程序也需要配置使用哪一个队列中的资源。
例如，对于MapReduce作业，mapreduce.job.queuename属性配置作业所使用的队列。如果没有指定队列，作业被放到一个叫default的队列中。

fair scheduler试图保证运行中的应用程序都能分配到平均的资源，这里的平均是通过资源的数量来定义的，例如内存大小。假设有两个用户A和B，分别持有队列queue A和B。
在一开始的时候，A启动了job1，此时因为B没有资源需要，因此job1霸占了所有资源。一段时间后B启动了job2，一段时间后（等待job1释放资源），job1和job2各占一半资源。如果用户B接着启动job3，则job2和job3将共享队列B，也就是各占集群总资源的25%。当job2结束之后，job3占据整个队列B（50%）。
因此我们得出一个结论，公平性是指用户之间的公平性，而不是应用之间的公平性。

默认使用的是Capacity Scheduler。

优先权：当一个集群处于繁忙状态时，如果我们提交一个作业到其中一个空的队列，此时需要等待其他作业释放资源才能开始运行。为了使得等待释放的时间可以控制在预测范围内，Fair Scheduler支持优先权。

优先权运行Scheduler杀死占用（按公平原则划分）别的队列的Container，腾出空间被占用队列的应用。优先权可能会降低集群的效率，因为被杀死的Container都需要重新执行。
杀死之前的等待时间通过allocaion文件中的queue元素内的fairSharePreemptionTimeut元素配置，而fairSharePreemptionThreshold和 defaultFairSharePreemptionThreshold则用于设置等待时间内，
原本属于队列的资源可用比例，例如设为0.5表示当等待时间到时，如果原本属性该队列（按照公平原则）的资源可用比例还没有达到一半，则会启动杀死其他应用的Container。

延时调度，当应用程序请求在某个特定的节点上运行时，如果该节点刚好处于忙碌状态无法分配给应用，一种选择方式是就近选择同一机架中的其他节点。但是在实际中发现，稍微等一小段时间，
很有可能就能够分配到指定的节点，进而提高集群效率。这个特性叫延迟调度。

默认情况下，集群中的NodeManager每一秒中都想RM发送心跳，心跳张包含节点当前正在运行的Container以及可用于新Container的资源。
因此每次心跳都是一个调度机会。当启用延迟调度时，对于有节点位置要求的资源请求，调度器不会简单地使用第一次调度机会（牺牲数据locality），而是会尝试等待直到最大次数的调度机会，一旦发现符合要求的调度机会，及分配给应用。
如果直到最大次数还是没有合适的节点资源，则放宽数据locality要求，退而求其次采用同一机架。