Hadoop学习笔记 — YARN资源管理器

By timebusker on June 5, 2018

Hadoop学习笔记—YARN资源管理器

Hadoop1.0架构回顾

  • Hadoop是Apache的一个开源分布式计算平台,以分布式文件系统HDFS,和MapReduce为核心的Hadoop为用户提供了系统底层细节透明的分布式基础架构。HDFS的高容错性、高伸缩性等优点形成分布式系统;MapReduce分布式编程模型让我们开发并行应用程序。
  • Hadoop为包含多个子项目的集合,其核心内容是MapReduce和HDFS。主要是通过HDFS来实现对分布式存储的底层支持,并且它会通过MapReduce来实现对分布式并行任务处理。
  • MapReduce是一种编程模型,用于大规模数据集的并行运算。它的主要思想是从函数式编程中借来的,它使得我们在不了解分布式并行 编程的情况下也能方便地将程序运行在分布式系统上。MapReduce在执行时先指定一个Map函数,把输入键值对映射成一组新的键值对,经过一定的处理后交给Reduce,它对相同的Key下的所有Value进行处理后再输出键值对作为最终的结果。 image
    1. JobTracker接收Job请求(接受JOB请求
    2. JobTracker根据Job的输入参数向NameNode请求包含这些文件数据块的DataNode节点列表(根据计算分配资源
    3. JobTracker确定Job的执行计划:确定执行此job的Map、Reduce的task数量,并且分配这些task到离数据块最近的节点上(指定执行计划并分配计算
    4. JobTracker提交所有task到每个TaskTracker节点。TaskTracker会定时的向JobTracker发送心跳,若一定时间内没有收到心跳,JobTracker就认为这个TaskTracker节点失败,然后JobTracker就会把此节点上的task重新分配到其它节点上
    5. 一旦所有的task执行完成,JobTracker会更新job状态为完成,若一定数量的task总数执行失败,这个job就会被标记为失败
    6. JobTracker发送job运行状态信息给Client端
Hadoop1.0架构总结
  • 数据分布存储:HDFS由一个NameNode和N个DataNode组成,但HDFS底层把文件切成Block,然后这些Block分散在存储于不同的DataNode上,每个Block还可以复制数份数据存储于不同的DataNode上,达到容灾的目的。NameNode是整个HDFS的核心,它通过维护一些数据结构来记录每一个文件被切割了多少个Block、这些Block可以从哪些DataNode中获取,及各个DataNode的状态等重要信息。
  • 分布式并行计算:Hadoop中有一个作为主控的JobTracker,用于调度和管理TaskTracker,JobTracker可以运行于集群中的任意一台计算机上,TaskTracker则负责执行任务,它运行于DataNode上,DataNode既是数据存储节点,也是计算节点。JobTracker将map任务和reduce任务分发给空闲的TaskTracker,并负责监控任务的运行情况。如某一TaskTracker出了故障,JobTracker会将其负责的任务转交给另一个空闲的TaskTracker重新运行。
  • 本地计算:数据存储在哪一个计算机上,就在那台计算机上进行这部分数据的计算,这样可以减少数据在网络上的传输。移动计算比移动数据更经济。
  • 任务粒度:把原始大数据集切割成小数据时,通常让小数据集小于或等于HDFS中一个Block的大小,这样能够保证一个小数据集是位于一台计算机上,便于本地计算。有M个小数据集待处理,就启动M个map任务,这里的M个map任务分布于N台计算机上,reduce任务的数量R则可由用户指定。
  • 数据分割(Partition):把map任务输出的中间结果按key的范围划分成R份,划分时通常使用hash函数,这样可以保证某一范围内的Key一定是由一个reduce任务来处理,可以简化Reduce的过程。
  • 数据合并(Combine):在数据分割前,还可以先对中间结果进行数据合并,将中间结果中有相同key的键值对合并成一对。Combine的过程与Reduce的过程类似,很多情况下直接使用Reduce函数,Combine作为Map任务的一部分,在执行完Map函数后立刻执行。Combine能够减少中间结果的键值对的数据,从而降低网络流量。
  • Reduce:Map任务的中间结果在完成Combine和Partition后,以文件形式存在本地磁盘上。中间结果文件的位置会通知主控JobTracker,JobTracker再通知Reduce任务到哪一个DataNode上取中间结果。所有的map任务生产的中间结果均按Key用同一个Hash函数划分成R份,R个Reduce任务各自负责一段key区间。每个Reduce需要向许多个Map任务节点取得落在其负责的key区间内的中间结果,然后执行reduce函数,开成一个最终的结果文件。
  • 任务管道:有R个reduce任务,就会有R个最终结果,很多情况下R个最终结果并不需要合并成一个最终结果,因为这R个结果又可以作为另一个计算任务的输入,开始另一个并行计算任务,这也就形成了任务管道。
MapReduce V1.X存在的问题
  • 可扩展性
    jobtracker则同时管理资源和处理job的功能,还要存储已完成作业历史,更包含了timeline server的功能,当集群运算任务量大时,有扩展局限性;
  • 可用性
    jobtracker多功能导致复杂的内存状态,难以实现高可用。特别各个任务状态管理,所有任务状态存在于内存中,即使实现主备切换,不能保证整体恢复
  • 利用率
    每个tasktracker有若干固定长度的slot(服务器内核计算资源),可能过大或者过小,导致资源利用率不均衡;
  • 多租户
    难以支持除MapReduce之外的框架,如Spark、Storm等

Yarn简介

Apache Hadoop Yarn(Yet Another Resource Negotiator,另一种资源协调者)是一种新的Hadoop资源管理器,它是一个通用资源管理系统, 可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

基本思想

Yarn的基本思想是将JobTracker的两个主要功能(资源管理和作业调度/监控)分离,主要方法是创建一个全局的ResourceManager(RM)和 若干个针对应用程序的ApplicationMaster(AM)。这里的应用程序是指传统的MapReduce作业或作业的DAG(有向无环图)。

MR-V1 Yarn
JobTracker ResourceManager、ApplicationMaster、timeline server(时间轴服务:记录历史任务信息)
TaskTracker NodeManager
Slot Container

需要注意的是,在Yarn中我们把job的概念换成了application,因为在新的Hadoop2.x中,运行的应用不只是MapReduce了, 还有可能是其它应用如一个DAG(有向无环图Directed Acyclic Graph,例如storm应用)。Yarn的另一个目标就是拓展Hadoop, 使得它不仅仅可以支持MapReduce计算,还能很方便的管理诸如Hive、Hbase、Pig、Spark/Shark等应用。 这种新的架构设计能够使得各种类型的应用运行在Hadoop上面,并通过Yarn从系统层面进行统一的管理,也就是说,有了Yarn, 各种应用就可以互不干扰的运行在同一个Hadoop系统中,共享整个集群资源,如下图所示:
image

Yarn的组件及架构

  • ResourceManager:Global(全局)的进程
  • NodeManager:运行在每个节点上的进程
  • ApplicationMaster:Application-specific(应用级别)的进程,是对运行在Yarn中某个应用的抽象,它其实就是某个类型应用的实例,ApplicationMaster是应用级别的,它的主要功能就是向ResourceManager(全局的)申请计算资源(Containers)并且和NodeManager交互来执行和监控具体的task。
  • Scheduler:是ResourceManager的一个组件,是ResourceManager专门进行资源管理的一个组件,负责分配NodeManager上的Container资源,NodeManager也会不断发送自己Container使用情况给ResourceManager。
  • Container:节点上一组CPU和内存资源,是Yarn对计算机计算资源的抽象,它其实就是一组CPU和内存资源,所有的应用都会运行在Container中。
  • ResourceManager和NodeManager两个进程主要负责系统管理方面的任务。ResourceManager有一个Scheduler,负责各个集群中应用的资源分配。对于每种类型的每个应用,都会对应一个ApplicationMaster实例, ApplicationMaster通过和ResourceManager沟通获得Container资源来运行具体的job,并跟踪这个job的运行状态、监控运行进度。 image

Yarn的组件详解

ResourceManager

ResourceManager主要有两个组件:SchedulerApplicationManager

  • Scheduler是一个资源调度器,它主要负责协调集群中各个应用的资源分配,保障整个集群的运行效率。Scheduler的角色是一个纯调度器,它只负责调度Containers, 不会关心应用程序监控及其运行状态等信息。同样,它也不能重启因应用失败或者硬件错误而运行失败的任务。 Scheduler是一个可插拔的插件,它可以调度集群中的各种队列、应用等。在Hadoop的MapReduce框架中主要有两种Scheduler:Capacity Scheduler和Fair Scheduler。

  • ApplicationManager主要负责接收job的提交请求,为应用分配第一个Container来运行ApplicationMaster,还有就是负责监控ApplicationMaster,在遇到失败时重启ApplicationMaster运行的Container。 ① 接收提交的作业 ② negotiating the first container for executing the application specific ApplicationMaster ③ restarting the ApplicationMaster container on failure

NodeManager

NodeManager进程运行在集群中的节点上,每个节点都会有自己的NodeManager。NodeManager是一个slave服务: 它负责接收ResourceManager的资源分配请求,分配具体的Container给应用。同时,它还负责监控并报告Container使用信息给ResourceManager。 通过和ResourceManager配合,NodeManager负责整个Hadoop集群中的资源分配工作。ResourceManager是一个全局的进程,而NodeManager只是每个节点上的进程, 管理这个节点上的资源分配和监控运行节点的健康状态。下面是NodeManager的具体任务列表:

  • 接收ResourceManager的请求,分配Container给应用的某个任务
  • 和ResourceManager交换信息以确保整个集群平稳运行。ResourceManager就是通过收集每个NodeManager的报告信息来追踪整个集群健康状态的,而NodeManager负责监控自身的健康状态。
  • 管理每个Container的生命周期
  • 管理每个节点上的日志
  • 执行Yarn上面应用的一些额外的服务,比如MapReduce的shuffle过程 当一个节点启动时,它会向ResourceManager进行注册并告知ResourceManager自己有多少资源可用。在运行期,通过NodeManager和ResourceManager协同工作, 这些信息会不断被更新并保障整个集群发挥出最佳状态。 NodeManager只负责管理自身的Container,它并不知道运行在它上面应用的信息。负责管理应用信息的组件是ApplicationMaster,在后面会讲到。
ApplicationMaster

ApplicationMaster属于应用级别,每个应用对应一个AM,不同的计算矿建的AM的实现也是不同的。 它负责向RM申请资源,在对应的NodeManager上启动Container来执行任务,并在应用中不断监控这些Container的状态。 其作用是向ResourceManager申请资源并和NodeManager协同工作来运行应用的各个任务然后跟踪它们状态及监控各个任务的执行,遇到失败的任务还负责重启它。

在MR_v1中,JobTracker即负责job的监控,又负责系统资源的分配。而在MR_v2(Yarn)中,资源的调度分配由ResourceManager专门进行管理, 而每个job或应用的管理、监控交由相应的分布在集群中的ApplicationMaster,如果某个ApplicationMaster失败,ResourceManager还可以重启它, 这大大提高了集群的拓展性。

在MR_v1中,Hadoop架构只支持MapReduce类型的job,所以它不是一个通用的框架,因为Hadoop的JobTracker和TaskTracker组件都是专门针对MapReduce开发的, 它们之间是深度耦合的。Yarn的出现解决了这个问题,关于Job或应用的管理都是由ApplicationMaster进程负责的,Yarn允许我们自己开发ApplicationMaster, 我们可以为自己的应用开发自己的ApplicationMaster。这样每一个类型的应用都会对应一个ApplicationMaster,一个ApplicationMaster其实就是一个类库。 这里要区分ApplicationMaster类库和ApplicationMaster实例,一个ApplicationMaster类库何以对应多个实例,就行java语言中的类和类的实例关系一样。 总结来说就是,每种类型的应用都会对应着一个ApplicationMaster,每个类型的应用都可以启动多个ApplicationMaster实例。 所以,在yarn中,是每个job都会对应一个ApplicationMaster而不是每类。

Container

Container是Yarn框架的计算单元,是具体执行应用task(如map task、reduce task)的基本单位。Container和集群节点的关系是:一个节点会运行多个Container,但一个Container不会跨节点。
一个Container就是一组分配的系统资源,现阶段只包含两种系统资源(之后可能会增加磁盘、网络等资源):

  • CPU core
  • Memory in MB
    既然一个Container指的是具体节点上的计算资源,这就意味着Container中必定含有计算资源的位置信息:计算资源位于哪个机架的哪台机器上。所以我们在请求某个Container时, 其实是向某台机器发起的请求,请求的是这台机器上的CPU和内存资源。

任何一个job或application必须运行在一个或多个Container中,在Yarn框架中,ResourceManager只负责告诉ApplicationMaster哪些Containers可以用, ApplicationMaster还需要去找NodeManager请求分配具体的Container。

Yarn 框架相对于老的 MapReduce 框架什么优势呢?
  • 这个设计大大减小了 ResourceManager 的资源消耗,并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了,更安全、更优美。
  • 在新的 Yarn 中,ApplicationMaster 是一个可变更的部分,用户可以对不同的编程模型写自己的 AppMst,让更多类型的编程模型能够跑在 Hadoop 集群中,可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
  • 对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中,没有考虑 cpu 的占用 ),比之前以剩余 slot 数目更合理。
  • 老的框架中,JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况,现在,这个部分就扔给 ApplicationMaster 做了,而 ResourceManager 中有一个模块叫做 ApplicationsManager,它是监测 ApplicationMaster 的运行状况,如果出问题,会将其在其他机器上重启。
  • Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作,目前是一个框架,仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量,那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。

Yarn 资源请求分析

应用提交过程分析

用户向YARN中提交JOB,当在配置文件中设置mapreduce.framework.name为yarn时候,MapReduce2.0继承接口ClientProtocol的模式就激活了。

Application在Yarn中的执行过程,整个执行过程可以总结为三步: 1. 应用程序提交 2. 启动应用的ApplicationMaster实例 3. ApplicationMaster实例管理应用程序的执行 image
image

作业提交
  • 客户端程序调用job.waitForCompletionjob.submit方法,向整个集群提交Job/Application(可以是MR,Java/Scala应用,spark的DAGs作业等)作业时,在客户端创建了一个RunJar的进程,RunJar向Yarn的资源管理Resource Manager(RM)申请一个Job,过程中使用的是远程过程控制协议RPC和RM进行通信的。
  • ResourceManager返回相关资源的提交路径staging-dir和这次job的job-ID
  • 客户端提交 jar 包、切片信息和配置文件到指定的资源提交路径
  • 向RM汇报资源提交结果,用submitApplication函数提交JOB给RM
    作业初始化
  • ResourceManager接受submitApplication方法提交的JOB,将该JOB添加到容量调度器中
  • NodeManager从RM中领取任务(NM时刻和RM保持通讯),某一个空闲的 NM 领取到该 JOB;
  • RM在该NM中分配运行资源容器Container,并产生 MRAppmaster,并向MP注册信息
    MRAppMatser会初始化一定数量的记录对象(bookkeeping)来跟踪JOB的运行进度, 并收集每个TASK的进度和完成情况, 接着MRAppMaster收集计算后的输入分片情况,如果应用程序很小,能在同一个JVM上运行,则用uber模式。
    如果不在uber模式下运行,则Application Master会为所有的Map和Reducer task向RM请求Container,所有的请求都通过heartbeat(心跳)传递, 心跳也传递其他信息,例如关于map数据本地化的信息,分片所在的主机和机架地址信息,这些信息帮助调度器来做出调度的决策, 调度器尽可能遵循数据本地化或者机架本地化的原则分配Container。

  • MRAppMaster下载客户端提交的资源到本地
任务分配
  • MrAppMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和领取资源运行多个 maptask 任务资源(根据resource-request协议向ResourceManager发送resource-request请求)
  •  一旦 ApplicationMaster 申请到资源后,便与对应的 NodeManager 通信,要求它启动任务,NodeManager分别领取任务并创建容器
任务运行
  • MrAppMaster向接收到任务的NodeManager发送程序启动脚本,NodeManager分别启动map task(任务由org.apache.hadoop.mapred.YarnChild的main类执行,YarnChild是一个(dedicated)的JVM
  • MrAppMaster 等待所有 map task 运行完毕后,向 RM 申请容器,运行 reduce task
  • reduce task 向 map task 获取相应分区的数据
  • 程序运行完毕后,MrAppMaster 会向 RM 申请注销自己,用到所有的Container也归还给系统
进度和状态更新

YARN 中的任务将其进度和状态(包括 counter)返回给应用管理器, 客户端每秒(通过 mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。

作业完成

除了向应用管理器请求作业进度外, 客户端每5秒钟都会通过调用 waitForCompletion() 来检查作业是否完成。时间间隔可以通过 mapreduce.client.completion.pollinterval 来设置。作 业完成之后, 应用管理器和 container 会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。

Resource Request和Container

Yarn的设计目标就是允许我们的各种应用以共享、安全、多租户的形式使用整个集群。并且,为了保证集群资源调度和数据访问的高效性, Yarn还必须能够感知整个集群拓扑结构。为了实现这些目标,ResourceManager的调度器Scheduler为应用程序的资源请求定义了一些灵活的协议, 通过它就可以对运行在集群中的各个应用做更好的调度,因此,这就诞生了Resource RequestContainer

具体来讲,一个应用先向ApplicationMaster发送一个满足自己需求的资源请求,然后ApplicationMaster把这个资源请求 以resource-request的形式发送给ResourceManager的Scheduler,Scheduler再在这个原始的resource-request中返回分配到的资源描述Container。 每个ResourceRequest可看做一个可序列化Java对象,包含的字段信息如下:

<resource-name, priority, resource-requirement, number-of-containers>   

# resource-name:资源名称,现阶段指的是资源所在的host和rack,后期可能还会支持虚拟机或者更复杂的网络结构
# priority:资源的优先级
# resource-requirement:资源的具体需求,现阶段指内存和cpu需求的数量
# number-of-containers:满足需求的Container的集合

number-of-containers中的Containers就是ResourceManager给ApplicationMaster分配资源的结果。Container就是授权给应用程序可以使用某个节点机器上CPU和内存的数量。

ApplicationMaster在得到这些Containers后,还需要与分配Container所在机器上的NodeManager交互来启动Container并运行相关任务。当然Container的分配是需要认证的,以防止ApplicationMaster自己去请求集群资源。

Yarn中的调度

理想情况下,我们应用对Yarn资源的请求应该立刻得到满足,但现实情况资源往往是有限的,特别是在一个很繁忙的集群,一个应用资源的请求经常需要等待一段时间才能的到相应的资源。 在Yarn中,负责给应用分配资源的就是Scheduler。其实调度本身就是一个难题,很难找到一个完美的策略可以解决所有的应用场景。为此,Yarn提供了多种调度器和可配置的策略供我们选择。

调度选项

在Yarn中有三种调度器可以选择:FIFO Scheduler(先进先出)Capacity Scheduler(计算能力调度器/容器调度器)FairS cheduler(公平调度器)

  • FIFO Scheduler:把应用按提交的顺序排成一个队列,这是一个先进先出队列,先进先出
  • Capacity Scheduler:支持多个队列,每个队列可配置一定的资源量,每个队列采用FIFO调度策略,为了防止同一个用户的作业独占队列中的资源,该调度器会对同一用户提交的作业所占资源量进行限定,选择占用最小、优先级高的先执行
  • Fair Scheduler:是一种赋予作业(job)资源的方法,它的目的是让所有的作业随着时间的推移,都能平均的获取等同的共享资源,所有的 job 具有相同的资源 FIFO Scheduler是最简单也是最容易理解的调度器,也不需要任何配置,但它并不适用于共享集群。大的应用可能会占用所有集群资源,这就导致其它应用被阻塞。 在共享集群中,更适合采用Capacity SchedulerFair Scheduler,这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。 image
Capacity Scheduler

Capacity 调度器允许多个组织共享整个集群,每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列,然后再为每个队列分配一定的集群资源, 这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外,队列内部又可以垂直划分,这样一个组织内部的多个成员就可以共享这个队列资源了, 在一个队列内部,资源的调度是采用的是先进先出(FIFO)策略。

如果一个队列的资源够用,那么就分配给这些job,如果这个队列的资源不够用了呢?其实Capacity调度器仍可能分配额外的资源给这个队列,这就是“弹性队列”(queue elasticity)的概念。

在正常的操作中,Capacity调度器不会强制释放Container,当一个队列资源不够用时,这个队列只能获得其它队列释放后的Container资源。 当然,我们可以为队列设置一个最大资源使用量,以免这个队列过多的占用空闲资源,导致其它队列无法使用这些空闲资源,这就是”弹性队列”需要权衡的地方。

容器调度的配置
root
├── prod
└── dev
    ├── eng
    └── science
队列的设置

关于队列的设置,这取决于我们具体的应用。比如,在MapReduce中,我们可以通过mapreduce.job.queuename属性指定要用的队列。如果队列不存在,我们在提交任务时就会收到错误。 如果我们没有定义任何队列,所有的应用将会放在一个default队列中。

注意:对于Capacity调度器,我们的队列名必须是队列树中的最后一部分,如果我们使用队列树则不会被识别。比如,在上面配置中, 我们使用prod和eng作为队列名是可以的,但是如果我们用root.dev.eng或者dev.eng是无效的。

Fair Scheduler

Fair调度器的设计目标是为所有的应用分配公平的资源(对公平的定义可以通过参数来设置)。 举个例子,假设有两个用户A和B,他们分别拥有一个队列。当A启动一个job而B没有任务时,A会获得全部集群资源;当B启动一个job后,A的job会继续运行,不过一会儿之后两个任务会各自获得一半的集群资源。 如果此时B再启动第二个job并且其它job还在运行,则它将会和B的第一个job共享B这个队列的资源,也就是B的两个job会分别用于四分之一的集群资源,而A的job仍然用于集群一半的资源,结果就是资源最终在两个用户之间平等的共享。

启用Fair Scheduler

调度器的使用是通过yarn-site.xml配置文件中的yarn.resourcemanager.scheduler.class参数进行配置的,默认采用Capacity Scheduler调度器。 如果我们要使用Fair调度器,需要在这个参数上配置FairScheduler类的全限定名: org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler

抢占(Preemption)

当一个job提交到一个繁忙集群中的空队列时,job并不会马上执行,而是阻塞直到正在运行的job释放系统资源。为了使提交job的执行时间更具预测性(可以设置等待的超时时间),Fair调度器支持抢占。

抢占就是允许调度器杀掉占用超过其应占份额资源队列的containers,这些containers资源便可被分配到应该享有这些份额资源的队列中。需要注意抢占会降低集群的执行效率,因为被终止的containers需要被重新执行。

可以通过设置一个全局的参数yarn.scheduler.fair.preemption=true来启用抢占功能。此外,还有两个参数用来控制抢占的过期时间(这两个参数默认没有配置,需要至少配置一个来允许抢占Container):

- minimum share preemption timeout
- fair share preemption timeout

如果队列在minimum share preemption timeout指定的时间内未获得最小的资源保障,调度器就会抢占containers。 我们可以通过配置文件中的顶级元素<defaultMinSharePreemptionTimeout>为所有队列配置这个超时时间;我们还可以在元素内配置``元素来为某个队列指定超时时间。

与之类似,如果队列在fair share preemption timeout指定时间内未获得平等的资源的一半(这个比例可以配置),调度器则会进行抢占containers。这个超时时间可以通过顶级元素 <defaultFairSharePreemptionTimeout>和元素级元素<fairSharePreemptionTimeout>分别配置所有队列和某个队列的超时时间。上面提到的比例可以 通过<defaultFairSharePreemptionThreshold>(配置所有队列)和<fairSharePreemptionThreshold>(配置某个队列)进行配置,默认是0.5。

Yarn相关的其它文章: