设计方案_Yarn队列高效管理的结构设计方案

篇首语：本文由编程笔记#小编为大家整理，主要介绍了Yarn队列高效管理的结构设计方案相关的知识，希望对你有一定的参考价值。

Yarn架构

YARN是从Hadoop 2.0引入的资源管理系统，主要由Resource Manager、Node Manager、Application Master和Container等几个组件构成。它的基本设计思想是将MRv1中的Job Tracker拆分成了两个独立的服务：一个全局的资源管理器Resource Manager和每个应用程序特有的Application Master。其中Resource Manager负责整个系统的资源管理和分配，而Application Master负责单个应用程序的管理。他们之间的关系可参见图1.1所示：

图1.1

YARN总体上仍然是master/slave结构，在整个资源管理框架中，Resource Manager为master，Node Manager是slave。Resource Manager负责对各个Node Manger上资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的Application Master，它负责向Resource Manager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的Application Master被分布到不同的节点上，因此它们之间不会相互影响。

Resource Manager是Master上一个独立运行的进程，负责集群统一的资源管理、调度、分配等等；NodeManager是Slave上一个独立运行的进程，负责上报节点的状态。Application Master和Container是运行在Slave上的组件，Container是yarn中分配资源的一个单位，包涵内存、CPU等等资源，yarn以Container为单位分配资源。

Yarn资源调度策略

Yarn中有三种Scheduler可以选择：FIFO Scheduler，Capacity Scheduler，Fair Scheduler，接下来我们将对此一一展开进行讲解。

FIFO Scheduler:把应用按照提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中第一个应用分配资源，待第一个应用需求满足后再给下一个分配，以此类推。例子参见图2.1所示： 

图2.1

上图的示例：有一个很大的job1，它先提交，并且占据了全部的资源。那么job2提交时发现没有资源了，则job2必须等待job1执行结束，才能获得资源执行。

PS:FIFO Scheduler它并不适用于共享集群。复杂的应用可能会占用所有集群资源，这就导致其它应用被阻塞。

Capacity Scheduler：有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFOScheduler时的时间。 Capacity Scheduler允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。当队列已满，Capacity Scheduler不会强制释放Container，当一个队列资源不够用时，这个队列只能获得其它队列释放后的Container资源，这个称为“弹性队列”，也可以设置最大值，防止过多占用其他队列的资源。 例子参见图2.2所示：

图2.2

上图的示例：有一个专门的队列允许小的apps提交之后能够尽快执行，注意到job1先提交，先执行时并没有占用系统的全部资源（假如job1需要100G内存，但是整个集群只有100G内存，那么只分配给job1  80G），而是保留了一部分的系统资源。

Fair Scheduler：我们不需要预先占用一定的系统资源，Fair Scheduler会为所有运行的job动态的调整系统资源。如下图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair Scheduler会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。 需要注意的是，在下图Fair Scheduler中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair Scheduler即得到了高的资源利用率又能保证小任务及时完成。例子参见图2.3所示：

图2.3

上图的示例：大的任务job1提交并执行，占用了集群的全部资源，开始执行。之后小的job2执行时，获得系统一半的资源，开始执行。因此每个job可以公平地使用系统的资源。当job2执行完毕，并且集群中没有其他的job加入时，job1又可以获得全部的资源继续执行。

PS:job2提交之后并不能马上就获取到集群一半的资源，因为job2必须等待job1释放containers。

相同点：

（1）以队列划分资源

（2）设定最低保证和最大使用上限

（3）在某个队列空闲时可以将资源共享给其他队列。

不同点：

（1）Fair Scheduler队列内部支持多种调度策略，包括FIFO、Fair（队列中的N个作业，每个获得该队列1 / N的资源）、DRF（Dominant Resource Fairness）（多种资源类型CPU，内存 的公平资源分配策略）。

（2）Fair Scheduler支持资源抢占。当队列中有新的应用提交时，系统调度器理应为它回收资源，但是考虑到共享的资源正在进行计算，所以调度器采用先等待再强制回收的策略，即等待一段时间后仍没有获得资源，那么从使用共享资源的队列中杀死一部分任务。

（3）Fair Scheduler中有一个基于任务数量的负载均衡机制，该机制尽可能将系统中的任务分配到各个节点。

（4）Fair Scheduler可以为每个队列单独设置调度策略（FIFO Fair DRF）。

（5）Fair Scheduler由于可以采用Fair算法，因此可以使得小应用程序快速获得资源，避免了长期得不到资源而“饿死”的情况。

说明：由于共享集群不适合采用FIFO Scheduler策略，所以Fair Scheduler和Capacity Scheduler更适合共享集群，其中Fair Scheduler是一种最常用和配置简单的调度策略被广泛应用。

应用场景与Yarn队列设计思路

Yarn队列设计的基本原则：根据不同的业务类型和资源占用特点，按照实际需求合理分配队列资源。现在我们分析一下不同业务类型和资源占用特点的关系。

交互式场景，主要应用于HiveSQL查询语句,通常带有一定的随机性,不是按照计划进行。无论用户何时向指定队列提交HiveSQL，会请求已经分配给队列的计算资源，当然不同复杂度的HiveSQL对资源的请求是不同的，通常这种程序的运行时长也和HiveSQL复杂度紧密相关。

交互式场景的资源请求特点是：阶段性或间歇性资源请求，实时性要求一般。我们在设计队列时要考虑如何充分利用空闲下来时间段的资源，避免长时间的资源闲置，同时又保证不能抢占集群的总体资源。

交互式场景的队列设计思路是：建立交互式队列资源组，同时限制队列组能够使用的最大资源，组内的队列设置Max Capacity为70%-80%即可，orderling police可设置为fair。应避免设置Max Capacity为100%，导致一段时间内后提交的程序可能无法请求到资源。这样交互式应用无法抢占组外的资源，同时又保证了组内资源的充分利用。

批处理场景和交互式场景类似，也是一种阶段性的资源请求场景，不同的是批处理场景通常有一定计划性和规律性，它通常都是采用定时任务的方式进行，每批次处理的时长和资源请求情况大致相同。

批处理场景的资源请求特点是：阶段性或间歇性资源请求，但实时性要求低，只有在规定时间点或特定情况下才会请求资源，其他时间队列资源是闲置的。

批处理场景的队列设计思路是：建立批处理队列资源组，同时限制队列组能够使用的最大资源。组内的队列设置Max Capacity为100%，同时orderling police可设置为fair或fifo。保障每批次都能请求到已分配的最大资源，提高每批次处理效率的同时又保证了组内资源的充分利用。

实时处理场景，顾名思义它要求队列资源实时保障，是所有大数据集群的重点支撑对象。实时处理场景通常具有连续性强、业务优先极高、影响范围广等特点，每个任务都是不间断持续运行。

批处理场景的资源请求特点是：实时处理程序运行起来，他的队列资源会一直占用，不会释放的。除非终止程序，但很明显这是不符合业务实时性保障要求的。

批处理场景的队列设计思路是：建立实时队列资源组，同时严格限制能够使用的最大资源， Max Capacity可以设置和Capacity一致或略大（10%左右），不建议过大，以避免资源占用后无法释放。同时orderling police设置为fair。

Yarn队列设计总体结构

上面已经讨论了，不同的业务类型对Yarn资源的占用特点是不同的。现在我们根据不同资源请求特点，对Yarn队列进行设计。主要设计思路如下：第一级为root根队列拥有100%资源，在root队列下新增二级三个子队列，每个子队列对应一种Yarn队列应用场景。可分别命名为，交互式队列：interactive；批处理队列：batch;实时队列streaming(命名规则自己确定，简单容易理解即可)。在每中类型的队列下再按需创建三级队列，可分别命名为：i_001,i_002…..;b_001,b_002…..;s_001,s_002……最后的Yarn设计结构如下图4.1所示：

图4.1

重要说明：上图的资源配置占比，不做实际环境推荐值，需根据实际生产环境业务类型自行调整每种队列类型的资源占比情况。

队列结构确定后，我们要为Yarn队列分配一定比例的资源。因为不同场景的资源使用特点前文已经提过多次，在此不做赘述，直接开始设计资源分配方案。

交互式队列（interactive）资源分配方案：

首要原则按需分配，需要注意的：交互式队列资源除Capacity外，Max Capacity可以设置80%左右，不建议达到100%，同时orderling police设置为fair。

批处理队列（batch）资源分配方案：

首要原则按需分配，需要注意的：批处理程序队列除Capacity外，Max Capacity可以设置100%。

同时orderling police可设置为fair或fifo。

实时队列（streaming）资源分配方案：

首要原则按需分配，需要注意的：实时程序队列除Capacity外，Max Capacity可以设置和Capacity一致或略大（10%左右），不建议过大。同时orderling police设置为fair。

采用三级Yarn队列结构存在诸多的优点，主要在以下几个方面：

(1) 从Yarn资源“隔离”角度，每种应用场景使用独立的动态资源池（本人习惯称为队列组），形成一对一的关系。例如：所有的实时程序都从streaming队列里分配，所有的交互式程序都从interactive队列里分配，批量程序亦然。这样可以更好地隔离每种应用场景对资源请求之间的相互影响。

(2) 从业务保障的角度，采用三级队列结构，更有助于集群管理员确定业务优先级，合理分配Yarn资源的同时，更快速地排查因资源问题导致的性能问题；

(3) 从集群队列管理角度，有助于集群管理员明确队列结构，分而治之，便于管理和资源分配。

总结

采用三级Yarn队列管理的方案，可以有效避免不同场景间Yarn资源请求的相互影响，这点在共享集群的性能调优上显得尤为突出。同时，此方案提升了集群管理员的对集群的把控粒度，合理的资源分配可以避免集群的过度扩容，减轻了维护成本和服务器投入成本。

在大数据共享集群环境中，按需分配是基础。任何优化方案都是在持续的观察和统计业务运行情况和集群资源实际使用情况的基础上得出。大数据集群管理没有最好方案，只有更合适方案。