一、YARN(分布式资源管理器)

  一)YARN的整体架构

  Yarn 是 Hadoop2.x 版本提出的一种全新的资源管理架构,此架构不仅支持 MapReduce 计算,还方便管理,比如 HBase、Spark、Storm、Tez/Impala 等应用。这种新的架构设计能够使各种类型的计算引擎运行在 Hadoop 上面,并通过 Yarn 从系统层面进行统一的管理。也就是说,通过 Yarn 资源管理器,各种应用就可以互不干扰地运行在同一个 Hadoop 系统中了,来共享整个集群资源。

  Yarn 的架构设计基于主从(Master-Slave)模式,主要由 ResourceManager(RM)NodeManager(NM)两大部分组成。除此之外,还有 ApplicationMaster(AM)、Application Manager、Scheduler 及 Container 等组件辅助实现所有功能。

  

YARN分布式资源管理器_xml

 

  二)YARN知识点讲解

  1、为什么会出现YARN

  Hadoop1.0的主要问题

  1. 计算资源和计算模型的管理调度耦合
  2. 集群规模受以及调度管理能力限制
  3. 只有单一计算模型MR

  2.0时代的解决问题(基于YARN)

  1. 管理资源和计算模型解耦合
  2. 二级调度
  3. 对更多计算模型的支持

  YARN上的计算模型

  

YARN分布式资源管理器_xml_02

  MRv1与MRv2架构

  

YARN分布式资源管理器_hadoop_03

  

YARN分布式资源管理器_应用程序_04

  2、什么是YARN

  YARN是一代MapReduce,即MRv2。是在第一代MapReduce基础上演变而来的,主要是为了解决原始Hadoop扩展性查,不支持多计算框架而提出的。

     YARN是下一代Hadoop计算平台,是一个通用的运行框架,用户可以编写自己计算框架,在该运行环境中运行。

  用于自己编写的框架作为客户端的一个lib,在运行提交作业时打包即可。

  • YARN=Yet Another Resource Negotiator:前身是MRv1的集群管理器
  • MRv2最基本的设计思想是将Job Tracker的两个主要功能,即资源管理和作业调度/监控分成两个独立的进程。全局的ResourceManager(RM)和与每个应用相关的ApplicationMaster(AM)
  • 这里的“应用”指一个单独的MapReduce作业。RM和与NodeManager(NM,每个节点一个)共同组成整个数据计算管理框架

  3、YARN的核心组件

  Yarn 中有两大组件,即 ResourceManager(RM)和 NodeManager(NM),其中 ResourceManager 由 ApplicationManager 和 Scheduler 组成。当用户提交 job 或 application 到 Yarn 上时,还会出现一个 ApplicationMaster 组件,此组件是应用程序级别的,用来管理运行在 Yarn 上的应用程序。这些 job 或 application 最终是在一个或多个 Container 中运行,而 Container 的资源则是通过 NodeManager 来分配。

    1)ResourceManager(RM)

  RM 是一个全局的资源管理器,集群里只有一个。它负责整个 Hadoop 系统的资源管理和分配,包括处理客户端请求、启动监控 ApplicationMaster、监控 NodeManager、资源的分配与调度等。它主要由两个组件构成,即调度器(Scheduler)和应用程序管理器 (ApplicationsManager,AsM)

  资源管理:包括应用程序管理和机器资源管理

  Scheduler 是一个集群资源调度器,根据集群的容量、队列等限制条件,将集群中的资源分配给各个正在运行的应用程序,以保障整个集群高效、合理地使用资源。

  Scheduler 主要有两种,即 Capacity Scheduler 和 Fair Scheduler。第一个是基于容量的资源调度,而第二个是基于公平的资源调度

  ApplicationsManager 负责管理整个集群中所有的应用程序,包括应用程序的提交、与调度器协商资源、启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。它的主要功能总结如下:

  • 负责接收用户提交的任务请求,为应用分配第一个 Container,此 Container 用来运行 ApplicationMaster;
  • 负责监控 ApplicationMaster 的状态,如果发现 ApplicationMaster 失败,会自动重启 ApplicationMaster 运行的 Container。

  Container 是最底层的计算单元,所有应用程序都是在 Container 中执行计算任务的。

  • ResourceManager负责对各个NodeManager(NM)上的资源进行统一管理和调度。它由两个组件构成
  • (1)调度器(scheduler):根据容量、队列等限制条件,将系统资源分配给正在运行的应用程序。
  • (2)应用程序管理器(applicationManager,AsM):负责管理整个系统中所有应用程序,包括应用程序提交、与调度器协商资源以启动;applicationManager(AM)、监控AM运行状态并在失败的时候重启
    2)ApplicationMaster

  当用户提交一个分析任务时,ApplicationMaster 进程首先启动。接着,它向 ResourceManager 申请资源并和 NodeManager 协同工作来运行此任务;同时,它还会跟踪监视任务的执行状态。当遇到失败的任务时自动重启它;当任务执行完成后,ApplicationMaster 会关闭自己并释放自己的容器。

  ApplicationMaster 执行过程是按照如下顺序进行的:

(1)ApplicationMaster 切分数据,对任务进行分片;

(2)ApplicationMaster 向 ResourceManager 申请资源,然后把申请下来的资源交给 NodeManager;

(3)监控任务的运行,并对错误任务进行重启;

(4)通过 NodeManager 监视任务的执行和资源使用情况。

  • 管理application
  • 代理App向RM申请/释放计算资源,以及与NM交互
  • 管理App内部的container
  • container生命周期管理
  • container Failover处理
  • container状态监控
    3)NodeManager

  NodeManager 进程运行在集群中的多个计算节点上,与 HDFS 分布式文件系统中 Datande 的角色类似,每个计算节点都运行一个 NodeManager 服务。

  NodeManager 负责每个节点上资源(CPU 和内存)的使用,它主要实现如下功能:

  • 接收并处理来自 ApplicationMaster 的 Container 启动、停止等请求;
  • NodeManager 管理着本节点上 Container 的使用(Container 的分配、启动、停止等操作);
  • NodeManager 定时向 ResourceManager 汇报本节点上的资源使用情况以及各个 Container 的运行状态(CPU 和内存等资源)。

注意:NodeManager只负责管理自身的container,不会关注container中运行的任务

    4)container

  container是Yarn资源管理器中最底层的计算单元,是执行计算任务的基本单位。比如Map task、reduce task都在container中执行

  一个节点根据资源的不同,可以运行多个container,一个container就是一组分配的系统资源。现阶段container的系统资源只包含CPU和内存两种,未来可能增加次磁盘、网络等资源。

  在 Yarn 中,ApplicationMaster 会跟 ResourceManager 申请系统资源,而 ResourceManager 只会告诉 ApplicationMaster 哪些 Containers 可以用。若要使用这些资源,ApplicationMaster 还需要去找 NodeManager 请求分配具体的 Container。任何一个 job 或 application 最终都是在一个或多个 Container 中完成分析计算任务的。

  4、YARN的特性

  • 资源双层调度
  • 容错性:各个组件均有考虑容错性
  • 扩展性:可扩展到上万个节点

  4、YARN的容错性

  • ResourceManager
  • 存在单点故障
  • 基于zookeeper的HA
  • NodeManager
  • 失败后,RM将失败的任务告诉对应的AM
  • AM决定如何处理失败的任务
  • ApplicationMaster
  • 失败后,由RM负责重启
  • AM需处理内部任务的容错问题
  • RMAppsMaster会保存已经运行完成的task

  三)YARN配置(手撕Hadoop)

  hadoop的程序根目录:/app/3rd/hadoop-3.3.1

  1、配置文件——yarn-site.xml

  文件位置:${HADOOP_HOME}//etc/hadoop/yarn-site.xml

  内容主要分类:

  • 通信地址类
  • 目录类
  • 资源类
  • 安全类
  • 节点健康状态监控类
    1、YARN配置文件参数——通信地址类

   

YARN分布式资源管理器_xml_05

    2、YARN配置文件参数——目录类

  

YARN分布式资源管理器_应用程序_06

    3、YARN配置文件参数——资源类

   

YARN分布式资源管理器_xml_07

    4、YARN配置文件参数——安全类
    5、YARN配置文件参数——节点健康状态监控类

   

YARN分布式资源管理器_xml_08

  2、修改配置文件

    1、配置core-site.xml

  添加如下的内容

  

YARN分布式资源管理器_应用程序_09

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<!--
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License. See accompanying LICENSE file.
-->

<!-- Put site-specific property overrides in this file. -->

<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://dev-hadoop-cluster</value>
</property>

<!-- 指定hadoop运行时产生文件的存储目录 -->
<property>
<name>hadoop.tmp.dir</name>
<value>/app/data/hadoop-3.3.1/tmp</value>
</property>
</configuration>

core-site.xml

 

  2、配置yarn-site.xml

  

YARN分布式资源管理器_xml_10

yarn-site.xml

 

    3、配置mapred-site.xml

  

YARN分布式资源管理器_应用程序_11

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<!--
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License. See accompanying LICENSE file.
-->

<!-- Put site-specific property overrides in this file. -->

<configuration>

</configuration>

mapred-site.xml

 

    4、配置slaves

  将各个datanode的主机IP填入,若配置了hosts文件,可以直接填写主机名

  最后将前述各个文件都拷贝到slave机器上

  四)YARN的调度

  • 双层调度
  • ResourceManager将资源分配给ApplicationMaster
  • ApplicationMaster将资源分配给各个Task
  • 基于资源预留的调度策略
  • 当资源不够时,会给Task预留,直到资源满足
  • 异步的分配
  • 可调度资源
  • CPU:yarn.nodemanager.resource.cpu-vcores
  • 内存:yarn.nodemanager.resource.memory-mb和yarn.nodemanager.vmem-pmem-ratio
  • 调度算法:Dominant Resource Fairness
  • 资源管理器
  • FIFO
  • Capacity Scheduler
  • Fair Scheduler
  • 也可以自己实现
  • YARN支持调度语义
  • 请求某个节点上的特定资源量
  • 请求某个机架上的特定资源量
  • 将某些节点加入(或移除)黑名单,不再为自己分配这些节点上的资源
  • 请求归还某些资源
  • 不支持的调度语义
  • 请求任意节点上的特定资源量
  • 请求任意机架上的特定资源量
  • 请求一组或几组符合某种特质的的资源
  • 超细粒度资源,比如CPU性能要求、绑定CPU等
  • 动态调整container资源,允许你根据需要动态调整container资源量

   YARN Capacity Scheduler

  • 设置yarn.resourcemanager.scheduler.class = CapacityScheduler
  • yarn rmadmin -refreshQueues
  • 树形结构:叶子(leaf)队列和父(parent)队列,由管理员指定容量
  • 设定调度队列树形结构capacity.xml
  • yarn的调度配置
  • yarn.scheduler.capacity.root.queue = eda, crm
  • yarn.scheduler.capacity.eda.queue = dpi, serv_bus
  • yarn.scheduler.capacity.crm.queue = eda, oip
  • 父队列用于组织层级之间的管理,他们可以包含更多的父队列和叶子队列,他们自己不会直接接受应用的提交
  • 叶子队列是居于父队列之下并接受应用。叶子队列不会包含其他子队列,因此不会有任务配置属性以.queues结尾
  • 顶层的父队列root不属于任何组织,它代表了集群自身


 

  五)YARN部署

  

YARN分布式资源管理器_xml_12

  

YARN分布式资源管理器_应用程序_13

  

YARN分布式资源管理器_应用程序_14

  

YARN分布式资源管理器_xml_15

  

YARN分布式资源管理器_应用程序_16

  

YARN分布式资源管理器_应用程序_17

  六)YARN的操作命令

  1、yarn命令概述

]# yarn -help 
Usage: yarn [--config confdir] COMMAND
where COMMAND is one of:
resourcemanager -format-state-store deletes the RMStateStore
resourcemanager run the ResourceManager
Use -format-state-store for deleting the RMStateStore.
Use -remove-application-from-state-store <appId> for
removing application from RMStateStore.
nodemanager run a nodemanager on each slave
timelineserver run the timeline server
rmadmin admin tools
version print the version
jar <jar> run a jar file
application prints application(s)
report/kill application
applicationattempt prints applicationattempt(s)
report
container prints container(s) report
node prints node report(s)
queue prints queue information
logs dump container logs
classpath prints the class path needed to
get the Hadoop jar and the
required libraries
daemonlog get/set the log level for each
daemon
top run cluster usage tool
or
CLASSNAME run the class named CLASSNAME

  使用语法:

yarn [--config confdir] COMMAND [--loglevel loglevel] [GENERIC_OPTIONS] [COMMAND_OPTIONS]

--config confdir #覆盖默认的配置目录,默认为${HADOOP_PREFIX}/conf.
--loglevel loglevel #覆盖日志级别。有效的日志级别为FATAL,ERROR,WARN,INFO,DEBUG和TRACE。默认值为INFO。
GENERIC_OPTIONS #多个命令支持的一组通用选项
COMMAND COMMAND_OPTIONS #以下各节介绍了各种命令及其选项

  2、命令详解

  application
使用语法:yarn application [options] #打印报告,申请和停止任务

-appStates <States> #与-list一起使用,可根据输入的逗号分隔的应用程序状态列表来过滤应用程序。有效的应用程序状态可以是以下之一:ALL,NEW,NEW_SAVING,SUBMITTED,ACCEPTED,RUNNING,FINISHED,FAILED,KILLED
-appTypes <Types> #与-list一起使用,可以根据输入的逗号分隔的应用程序类型列表来过滤应用程序。
-list #列出RM中的应用程序。支持使用-appTypes来根据应用程序类型过滤应用程序,并支持使用-appStates来根据应用程序状态过滤应用程序。
-kill <ApplicationId> #终止应用程序。
-status <ApplicationId> #打印应用程序的状态。

 

  applicationattempt
使用语法:yarn applicationattempt [options] #打印应用程序尝试的报告

-help #帮助
-list <ApplicationId> #获取到应用程序尝试的列表,其返回值ApplicationAttempt-Id 等于 <Application Attempt Id>
-status <Application Attempt Id> #打印应用程序尝试的状态。

 

  classpath
使用语法:yarn classpath #打印需要得到Hadoop的jar和所需要的lib包路径

 

  container
使用语法:yarn container [options] #打印container(s)的报告

-help #帮助
-list <Application Attempt Id> #应用程序尝试的Containers列表
-status <ContainerId> #打印Container的状态

 

  jar
使用语法:yarn jar <jar> [mainClass] args… #运行jar文件,用户可以将写好的 YARN 代码打包成jar文件,用这个命令去运行它。

 

  logs
使用语法:yarn logs -applicationId <application ID> [options]  #转存 container 的日志。

-applicationId <application ID> #指定应用程序ID,应用程序的ID可以在yarn.resourcemanager.webapp.address配置的路径查看(即:ID)
-appOwner <AppOwner> #应用的所有者(如果没有指定就是当前用户)应用程序的ID可以在yarn.resourcemanager.webapp.address配置的路径查看(即:User)
-containerId <ContainerId> #Container Id
-help #帮助
-nodeAddress <NodeAddress> #节点地址的格式:nodename:port (端口是配置文件中:yarn.nodemanager.webapp.address参数指定)

 

  node
使用语法:yarn node [options] #打印节点报告

-all #所有的节点,不管是什么状态的。
-list #列出所有RUNNING状态的节点。支持-states选项过滤指定的状态,节点的状态包含:NEW,RUNNING,UNHEALTHY,DECOMMISSIONED,LOST,REBOOTED。支持--all显示所有的节点。
-states <States> #和-list配合使用,用逗号分隔节点状态,只显示这些状态的节点信息。
-status <NodeId> #打印指定节点的状态。

 

  queue
使用语法:yarn queue [options] #打印队列信息

-help #帮助
-status #<QueueName> 打印队列的状态

 

  daemonlog
使用语法:
yarn daemonlog -getlevel <host:httpport> <classname>
yarn daemonlog -setlevel <host:httpport> <classname> <level>

-getlevel <host:httpport> <classname> #打印运行在<host:port>的守护进程的日志级别。这个命令内部会连接http://<host:port>/logLevel?log=<name>
-setlevel <host:httpport> <classname> <level> #设置运行在<host:port>的守护进程的日志级别。这个命令内部会连接http://<host:port>/logLevel?log=<name>

 

  nodemanager
使用语法:yarn nodemanager #启动nodemanager

 

  proxyserver
使用语法:yarn proxyserver #启动web proxy server

 

  resourcemanager
使用语法:yarn resourcemanager [-format-state-store] #启动ResourceManager

-format-state-store # RMStateStore的格式. 如果过去的应用程序不再需要,则清理RMStateStore, RMStateStore仅仅在ResourceManager没有运行的时候,才运行RMStateStore

 

  rmadmin
使用语法:#运行Resourcemanager管理客户端

yarn rmadmin [-refreshQueues]
[-refreshNodes]
[-refreshUserToGroupsMapping]
[-refreshSuperUserGroupsConfiguration]
[-refreshAdminAcls]
[-refreshServiceAcl]
[-getGroups [username]]
[-transitionToActive [--forceactive] [--forcemanual] <serviceId>]
[-transitionToStandby [--forcemanual] <serviceId>]
[-failover [--forcefence] [--forceactive] <serviceId1> <serviceId2>]
[-getServiceState <serviceId>]
[-checkHealth <serviceId>]
[-help [cmd]]


-refreshQueues #重载队列的ACL,状态和调度器特定的属性,ResourceManager将重载mapred-queues配置文件
-refreshNodes #动态刷新dfs.hosts和dfs.hosts.exclude配置,无需重启NameNode。
#dfs.hosts:列出了允许连入NameNode的datanode清单(IP或者机器名)
#dfs.hosts.exclude:列出了禁止连入NameNode的datanode清单(IP或者机器名)
#重新读取hosts和exclude文件,更新允许连到Namenode的或那些需要退出或入编的Datanode的集合。
-refreshUserToGroupsMappings #刷新用户到组的映射。
-refreshSuperUserGroupsConfiguration #刷新用户组的配置
-refreshAdminAcls #刷新ResourceManager的ACL管理
-refreshServiceAcl #ResourceManager重载服务级别的授权文件。
-getGroups [username] #获取指定用户所属的组。
-transitionToActive [–forceactive] [–forcemanual] <serviceId> #尝试将目标服务转为 Active 状态。如果使用了–forceactive选项,不需要核对非Active节点。如果采用了自动故障转移,这个命令不能使用。虽然你可以重写–forcemanual选项,你需要谨慎。
-transitionToStandby [–forcemanual] <serviceId> #将服务转为 Standby 状态. 如果采用了自动故障转移,这个命令不能使用。虽然你可以重写–forcemanual选项,你需要谨慎。
-failover [–forceactive] <serviceId1> <serviceId2> #启动从serviceId1 到 serviceId2的故障转移。如果使用了-forceactive选项,即使服务没有准备,也会尝试故障转移到目标服务。如果采用了自动故障转移,这个命令不能使用。
-getServiceState <serviceId> #返回服务的状态。(注:ResourceManager不是HA的时候,时不能运行该命令的)
-checkHealth <serviceId> #请求服务器执行健康检查,如果检查失败,RMAdmin将用一个非零标示退出。(注:ResourceManager不是HA的时候,时不能运行该命令的)
-help [cmd] #显示指定命令的帮助,如果没有指定,则显示命令的帮助。

 

  scmadmin
使用语法:yarn scmadmin [options] #运行共享缓存管理客户端

-help #查看帮助
-runCleanerTask #运行清理任务

 

  sharedcachemanager
使用语法:yarn sharedcachemanager #启动共享缓存管理器

 

  timelineserver
使用语法:yarn timelineserver  #启动timelineserver

 

 

  七)YARN的资源管理

  在YARN中,资源管理由RescoueceManager和NodeManager共同完成,其中,Resourcemanager中的调度器负责资源分配,而NodeManager则负责资源的供给和隔离。

  ResourceManager将某个Nodemanager上资源分配给任务(这就是所谓的资源调度)后,NodeManager需按照要求为任务提供相应的资源,甚至保证这些资源应具有独占性,为任务运行提供基础保证,这就是所谓的资源隔离。

  

YARN分布式资源管理器_应用程序_18

   图解:容器是内存和vcore的抽象概念。容器运行在nm节点

  基于以上考虑,YARN允许用户配置每、个节点上可用的物理内存资源,注意,这里是“可用的”,因为一个节点上的内存会被若干个服务共享,比如一部分给YARN,一部分给HDFS,一部分给HBase等,YARN配置的只是自己可以使用的,配置参数如下:

  (1)yarn.nodemanager.resource.memory-mb 

  表示该节点上YARN可使用的物理内存总量,默认是8192MB,注意,如果你的节点内存资源不够8G,则需要调减小这个值,而YARN不会智能的探测节点的物理内存总量。

  

YARN分布式资源管理器_hadoop_19

  

YARN分布式资源管理器_xml_20

yarn.nodemanager.resource.detect-hardware-capabilities 为true并且yarn.nodemanager.resource.memory-mb 为-1,那么

  yarn.nodemanager.resource.memory-mb是自动计算,如果不是则yarn.nodemanager.resource.memory-mb=8G(默认)

  (2)yarn.scheduler.minimum-allocation-mb 

        单个任务可申请的最少内存,默认时1024M,如果一个任务申请的物理内存量少于该值,则该对应的值减少位这个数

  (3)yarn.scheduler.maximum-allocation-mb

         单个任务可申请的最大内存,默认时8192M

  

YARN分布式资源管理器_hadoop_21

  (4)yarn.nodemanager.pmem-check-enabled      true

         是否启动一个线程检查每个任务正在使用的物理内存量,如果任务超出分配值,直接将他杀掉,默认是True

  (5)yarn.nodemanager.vmem-check-enabled     true

         是否启动一个线程检查每个任务正在使用的虚拟内存量,如果任务超出分配值,直接将他杀掉,默认是True

  (6)yarn.nodemanager.vmem-pmem-ratio           2.1

  任务每使用1M的物理内存,最多可使用的虚拟内存量

 

  目前的CPU被划分成虚拟CPU(CPU virtual Core),这里的虚拟CPU是YARN自己引入的概念,初衷是,考虑到不同节点的CPU性能可能不同,每个CPU具有的计算能力也是不一样的,比如某个物理CPU的计算能力可能是另外一个物理CPU的2倍,这时候,你可以通过为第一个物理CPU多配置几个虚拟CPU弥补这种差异。用户提交作业的时候,可以指定每个任务需要的虚拟CPU个数。在YARN中,CPU相关配置参数如下:

  (7)yarn.nodemanager.resource.cpu-vcores    12 

      表示该节点上YARN可使用的虚拟CPU个数,默认是8,目前推荐将该值设置位与物理CPU核数数目相同。如果物理CPU核数不够8,则需要调小这个值,而YARN不       会智能的探测物理CPU总数。
  (8) yarn.scheduler.minimum-allocation-vcores   1

      单个任务可申请的最小CPU个数,默认是1,如果一个任务申请的CPU个数小于该数,则将该数改为这个数。
  (9)yarn.scheduler.maximum-allocation-vcores   4

      单个任务可申请的最大CPU个数,默认是4

   container: 容器个数的判别标准有两个维度

   一个是物理内存,一个是CPU

  memory 16c~4c
  vcores 12c~3c

yarn的在调优时候要综合考虑CPU和内存的分配,尽量保证不要空出多余的资源,假如container总内存30,container最小2G,总vcore8 container 最小1c

  那么我们内存可以启动最多15个container,cpu最多启动8个container,最终可以启动8个container,会有相当多的内存没有用到。所以生产上的调优配置需要综合考量内存和 CPU的配比。

  八)YARN的调度管理器

简单对比下三种调度器:

  • FIFO - Allocates resources based on arrival time. 在当前强调多租户和资源利用率的大环境下,几乎已经没有集群采用 fifo调度器了;
  • Fair - Allocates resources to weighted pools, with fair sharing within each pool. When configuring the scheduling policy of a pool, Domain Resource Fairness (DRF) is a type of fair scheduler;Cloudera 在 cdh 中推荐使用的即是该 Fair 调度器。(不过在 cloudera 的 cdp中,目前官方推荐且唯一支持的却是 capacity 调度器)
  • Capacity - Allocates resources to pools, with FIFO scheduling within each pool. hadoop yarn 默认配置的调度器即是该 Capacity调度器 ;星环的 Tdh 中默认配置的也是该 capacity scheduler.

  2、可以看到,Fair 和 Capacity 调度器的核心理念是类似的:

  • 两个调度器都是把整个集群资源划分到若干个资源池 pool 中,而应用是提交到具体的资源池中并从中申请资源的,两个调取器都是基于这种机制,来做资源的隔离进而满足各种 sla 需求;
  • 两个调度器的 pool 都是支持层次 即 Hierarchical 的;
  • 两个调度器,都支持多租户;
  • 两个调度器,都支持提交应用时指定具体的资源池;
  • 当应用没有指定具体的资源池时,两个调度器都可以根据配置的规则,根据应用提交者的身份,决定实际使用的是哪个;
  • 两个调度器,都支持根据应用提交者的身份,动态创建资源池;

  3、两个调度器的对比如下:

  • 两个调度器的核心区别,在于提交到一个具体的资源池中的所有任务,是采用 fair 公平调度还是 fifo 先进先出的调度;
  • fair 公平调度器,综合考量了提交到 pool 中的各种大小任务的差异,能避免因长时间运行的大任务占用了大量集群资源,造成小任务长时间得不到资源无法执行,影响用户体验;
  • Capacity 调度器,初看似乎没有像 fair 公平调取器那样,综合考量提交到 pool 中的任务大小的差异,但细想之下,管理员可以对大小任务/批流任务创建不同的 pool,由任务提交者根据任务的特点,提交到不同的 pool 中,一样能达到和 fair 调度器一样的效果和用户体验;
  • Capacity 调度器,配置更为简单,可能是因为这种原因,cloudera 的 cdp 中目前推荐且唯一支持的是 Capacity 调度器;

  由于当前大部分客户使用的都是 cloudera 的 cdh 集群推荐的 Fair 调度器,所以这里我们重点看下该公平调度器。