Hadoop系列-Yarn资源调度器（七）

最新推荐文章于 2024-05-19 08:42:31 发布

Just Jump

最新推荐文章于 2024-05-19 08:42:31 发布

阅读量471

点赞数 1

分类专栏： Hive & Hadoop 文章标签： Hadoop任务调度器 Yarn资源调度器

原文链接：https://www.hadoopdoc.com/hadoop/hadoop-scheduler

版权

Hive & Hadoop 专栏收录该内容

21 篇文章 3 订阅

订阅专栏

一、资源调度 Yarn Scheduler

https://blog.51cto.com/u_12279910/4218195

Hadoop 是一个可以高效处理大数据量的分布式集群，并且支持多用户多任务执行。我们应用对Yarn资源的请求应该立刻得到满足，但现实情况资源往往是有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到相应的资源。在Yarn中，负责给应用分配资源的就是Scheduler。

ResourceManager（RM）：负责对各NM上的资源进行统一管理和调度，将AM分配空闲的Container运行并监控其运行状态。对AM申请的资源请求分配相应的空闲Container。主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager）。

调度器（Scheduler）：调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位是Container，从而限定每个任务使用的资源量。Scheduler不负责监控或者跟踪应用程序的状态，也不负责任务因为各种原因而需要的重启（由ApplicationMaster负责）。总之，调度器根据应用程序的资源要求，以及集群机器的资源情况，为用程序分配封装在Container中的资源。调度器是可插拔的，例如CapacityScheduler、FairScheduler。（PS：在实际应用中，只需要简单配置即可）

应用程序管理器（Application Manager）：应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动AM、监控AM运行状态并在失败时重新启动等，跟踪分给的Container的进度、状态也是其职责。ApplicationMaster是应用框架，它负责向ResourceManager协调资源，并且与NodeManager协同工作完成Task的执行和监控。MapReduce就是原生支持的一种框架，可以在YARN上运行Mapreduce作业。有很多分布式应用都开发了对应的应用程序框架，用于在YARN上运行任务，例如Spark，Storm等。如果需要，我们也可以自己写一个符合规范的YARN application。

NodeManager（NM）：NM是每个节点上的资源和任务管理器。它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；同时会接收并处理来自AM的Container 启动/停止等请求。ApplicationMaster（AM）：用户提交的应用程序均包含一个AM，负责应用的监控，跟踪应用执行状态，重启失败任务等。

Container：是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container 表示的。YARN会为每个任务分配一个Container且该任务只能使用该Container中描述的资源。

二、任务调度器Scheduler

Hadoop支持3种调度器：FIFO调度器、公平调度器（Fair Scheduler）、容量调度器（Capacity Scheduler）

1、FIFO调度器

上图为 FIFO 调度器的执行过程示意图。FIFO 调度器也就是平时所说的先进先出（First In First Out）调度器。

FIFO 调度器是 Hadoop 最早应用的一种调度策略，可以简单的将其理解为一个 Jav a队列，它的含义在于集群中同时只能有一个作业在运行。将所有的 Application 按照提交时候的顺序来执行，只有当上一个 Job 执行完成之后后面的 Job 才会按照队列的顺序依次被执行。FIFO 调度器以集群资源独占的方式来运行作业，这样的好处是一个作业可以充分利用所有的集群资源，但是对于运行时间短，重要性高或者交互式查询类的 MR 作业就要等待排在序列前的作业完成才能被执行，这也就导致了如果有一个非常大的Job在运行，那么后面的作业将会被阻塞。

因此，虽然单一的 FIFO 调度实现简单，但是对于很多实际的场景并不能满足要求。这也就催生了 Capacity 调度器和 Fair 调度器的出现。

相关参数配置:

minResources:最少资源保证量，设置格式为“X mb, Y vcores”，当一个队列的最少资源保证量未满足时，它将优先于其他同级队列获得资源，对于不同的调度策略（后面会详细介绍），最少资源保证量的含义不同，对于fair策略，则只考虑内存资源，即如果一个队列使用的内存资源超过了它的最少资源量，则认为它已得到了满足；对于drf策略，则考虑主资源使用的资源量，即如果一个队列的主资源量超过它的最少资源量，则认为它已得到了满足。

maxResources:最多可以使用的资源量，fair scheduler会保证每个队列使用的资源量不会超过该队列的最多可使用资源量。

maxRunningApps:最多同时运行的应用程序数目。通过限制该数目，可防止超量Map Task同时运行时产生的中间输出结果撑爆磁盘。

weight:资源池权重,主要用在资源共享之时，weight越大，拿到的资源越多。比如一个pool中有20GB内存用不了，这时候可以共享给其他pool，其他每个pool拿多少，就是由权重决定的

aclSubmitApps:可向队列中提交应用程序的Linux用户或用户组列表，默认情况下为“*”，表示任何用户均可以向该队列提交应用程序。需要注意的是，该属性具有继承性，即子队列的列表会继承父队列的列表。配置该属性时，用户之间或用户组之间用“，”分割，用户和用户组之间用空格分割，比如“user1, user2 group1,group2”。

aclAdministerApps:允许管理任务的用户名和组；一个队列的管理员可管理该队列中的资源和应用程序，比如可杀死任意应用程序。

minSharePreemptionTimeout ：最小共享量抢占时间。如果一个资源池在该时间内使用的资源量一直低于最小资源量，则开始抢占资源。

schedulingMode/schedulingPolicy：队列采用的调度模式，可以是fifo、fair或者drf。
管理员也可为单个用户添加maxRunningJobs属性限制其最多同时运行的应用程序数目。此外，管理员也可通过以下参数设置以上属性的默认值：

userMaxJobsDefault：用户的maxRunningJobs属性的默认值。

defaultMinSharePreemptionTimeout ：队列的minSharePreemptionTimeout属性的默认值。

defaultPoolSchedulingMode：队列的schedulingMode属性的默认值。

fairSharePreemptionTimeout：公平共享量抢占时间。如果一个资源池在该时间内使用资源量一直低于公平共享量的一半，则开始抢占资源。
这样，每个用户组下的用户提交任务时候，会到相应的资源池中，而不影响其他业务。队列的层次是通过嵌套

元素实现的。所有的队列都是root队列的孩子，即使没有配到元素里。Fair调度器中的队列有一个权重属性（这个权重就是对公平的定义），并把这个属性作为公平调度的依据。在这个例子中，当调度器分配集群7.5,1,1,0.5资源给production,spark,streaming,default时便视作公平,这里的权重并不是百分比。注意，对于在没有配置文件时按用户自动创建的队列，它们仍有权重并且权重值为1。每个队列内部仍可以有不同的调度策略。队列的默认调度策略可以通过顶级元素进行配置，如果没有配置，默认采用公平调度。尽管是Fair调度器，其仍支持在队列级别进行FIFO调度。每个队列的调度策略可以被其内部的元素覆盖，在上面这个例子中，default队列就被指定采用fifo进行调度，所以，对于提交到default队列的任务就可以按照FIFO规则顺序的执行了。需要注意，spark,production,streaming,default之间的调度仍然是公平调度。每个队列可配置最大、最小资源占用数和最大可运行的应用的数量。

2、容量调度器（Capacity Scheduler）

上图是 Capacity 调度器的执行过程示意图。Capacity 调度器也就是日常说的容器调度器。可以将它理解成一个个的资源队列。这个资源队列是用户自己去分配的。例如因为工作所需要把整个集群分成了AB两个队列，A队列下面还可以继续分，比如将A队列再分为1和2两个子队列。那么队列的分配就可以参考下面的树形结构：

—-A[60%]
|—-A.1[40%]
|—-A.2[60%]
—-B[40%]

上述的树形结构可以理解为A队列占用整个资源的60%，B队列占用整个资源的40%。A队列里面又分了两个子队列，A.1占据40%，A.2占据60%，也就是说此时A.1和A.2分别占用A队列的40%和60%的资源。虽然此时已经具体分配了集群的资源，但是并不是说A提交了任务之后只能使用它被分配到的60%的资源，而B队列的40%的资源就处于空闲。只要是其它队列中的资源处于空闲状态，那么有任务提交的队列可以使用空闲队列所分配到的资源，使用的多少是依据配来决定。

Capacity 调度器的特性

层次化的队列设计，这种层次化的队列设计保证了子队列可以使用父队列设置的全部资源。这样通过层次化的管理，更容易合理分配和限制资源的使用。
容量保证，队列上都会设置一个资源的占比，这样可以保证每个队列都不会占用整个集群的资源。
安全，每个队列又严格的访问控制。用户只能向自己的队列里面提交任务，而且不能修改或者访问其他队列的任务。
弹性分配，空闲的资源可以被分配给任何队列。当多个队列出现争用的时候，则会按照比例进行平衡。
多租户租用，通过队列的容量限制，多个用户就可以共享同一个集群，同事保证每个队列分配到自己的容量，提高利用率。
操作性，Yarn支持动态修改调整容量、权限等的分配，可以在运行时直接修改。还提供给管理员界面，来显示当前的队列状况。管理员可以在运行时，添加一个队列；但是不能删除一个队列。管理员还可以在运行时暂停某个队列，这样可以保证当前的队列在执行过程中，集群不会接收其他的任务。如果一个队列被设置成了stopped，那么就不能向他或者子队列上提交任务了。
基于资源的调度，协调不同资源需求的应用程序，比如内存、CPU、磁盘等等。

3、公平调度器（Fair Scheduler）

上图是 Fair调度器在一个队列中的执行过程示意图。Fair调度器也就是日常说的公平调度器。Fair调度器是一个队列资源分配方式，在整个时间线上，所有的Job平均的获取资源。默认情况下，Fair调度器只是对内存资源做公平的调度和分配。当集群中只有一个任务在运行时，那么此任务会占用整个集群的资源。当其他的任务提交后，那些释放的资源将会被分配给新的Job，所以每个任务最终都能获取几乎一样多的资源。

公平调度器也可以在多个队列间工作，如上图所示，例如有两个用户A和B，他们分别拥有一个队列。当A启动一个Job而B没有任务提交时，A会获得全部集群资源；当B启动一个Job后，A的任务会继续运行，不过队列A会慢慢释放它的一些资源，一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个Job并且其它任务也还在运行时，那么它将会和B队列中的的第一个Job共享队列B的资源，也就是队列B的两个Job会分别使用集群四分之一的资源，而队列A的Job仍然会使用集群一半的资源，结果就是集群的资源最终在两个用户之间平等的共享。

在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
a) 公平调度器，就是能够共享整个集群的资源
b) 不用预先占用资源，每一个作业都是共享的
c) 每当提交一个作业的时候，就会占用整个资源。如果再提交一个作业，那么第一个作业就会分给第二个作业一部分资源，第一个作业也就释放一部分资源。再提交其他的作业时，也同理也就是说每一个作业进来，都有机会获取资源。

Fair Scheduler与Capacity Scheduler区别

资源公平共享：在每个队列中，Fair Scheduler可选择按照FIFO、Fair或DRF策略为应用程序分配资源。Fair策略即平均分配，默认情况下，每个队列采用该方式分配资源
支持资源抢占：当某个队列中有剩余资源时，调度器会将这些资源共享给其他队列，而当该队列中有新的应用程序提交时，调度器要为它回收资源。为了尽可能降低不必要的计算浪费，调度器采用了先等待再强制回收的策略，即如果等待一段时间后尚有未归还的资源，则会进行资源抢占；从那些超额使用资源的队列中杀死一部分任务，进而释放资源
负载均衡：Fair Scheduler提供了一个基于任务数的负载均衡机制，该机制尽可能将系统中的任务均匀分配到各个节点上。此外，用户也可以根据自己的需求设计负载均衡机制
调度策略灵活配置：Fiar Scheduler允许管理员为每个队列单独设置调度策略（当前支持FIFO、Fair或DRF三种）
提高小应用程序响应时间：由于采用了最大最小公平算法，小作业可以快速获取资源并运行完成