Yarn结构

Yarn是将JobTracker的两个主要功能(资源管理和作业调度/监控)分离,主要方法是创建一个全局的ResourceManager(RM)和若干个针对应用程序的ApplicationMaster(AM)。

Yarn分层结构的本质是ResourceManager。这个实体控制整个集群并管理应用程序向基础计算资源的分配。ResourceManager将各个资源部分(计算、内存、带宽等)精心安排给基础NodeManager(YARN的每节点代理)。ResourceManager还与Application Master一起分配资源,与NodeManager一起启动和监视它们的基础应用程序。在此上下文中,Application Master承担了以前的TaskTracker的一些角色,ResourceManager 承担了JobTracker的角色。

Application Master管理一个在Yarn内运行的应用程序的每个实例。Application Master负责协调来自ResourceManager的资源,并通过NodeManager监视容器的执行和资源使用(CPU、内存等的资源分配)。

NodeManager管理一个Yarn集群中的每个节点。NodeManager提供针对集群中每个节点的服务,从监督对一个容器的终生管理到监视资源和跟踪节点健康。MRv1通过插槽管理Map和Reduce任务的执行,而NodeManager管理抽象容器,这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。

图中各部分的功能如下表所示。

在Yarn中,资源调度器是以层级队列方式组织资源的,这种组织方式有利于资源在不同队列间分配和共享,进而提高集群资源利用率。Superior Scheduler和Capacity Scheduler的核心资源分配模型相同。

调度器会维护队列的信息。用户可以向一个或者多个队列提交应用。每次NM心跳的时候,调度器会根据一定规则选择一个队列,再选择队列上的一个应用,并尝试在这个应用上分配资源。若因参数限制导致分配失败,将选择下一个应用。选择一个应用后,调度器会处理此应用的资源申请。其优先级从高到低依次为:本地资源的申请、同机架的申请,任意机器的申请。

名称
描述

Client

Yarn Application客户端,用户可以通过客户端向ResourceManager提交任务,查询Application运行状态等。

ResourceManager(RM)

负责集群中所有资源的统一管理和分配。接收来自各个节点(NodeManager)的资源汇报信息,并根据收集的资源按照一定的策略分配给各个应用程序。

NodeManager(NM)

NodeManager(NM)是Yarn中每个节点上的代理,管理Hadoop集群中单个计算节点,包括与ResourceManger保持通信,监督Container的生命周期管理,监控每个Container的资源使用(内存、CPU等)情况、节点健康状况,管理日志和不同应用程序用到的附属服务(auxiliary service)。

ApplicationMaster(AM)

即图中的App Mstr,负责一个Application生命周期内的所有工作。包括:与RM调度器协商以获取资源;将得到的资源进一步分配给内部任务(资源的二次分配);与NM通信以启动/停止任务;监控所有任务运行状态,并在任务运行失败时重新为任务申请资源以重启任务。

Container

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

在Yarn中,资源调度器是以层级队列方式组织资源的,这种组织方式有利于资源在不同队列间分配和共享,进而提高集群资源利用率。Superior Scheduler和Capacity Scheduler的核心资源分配模型相同。

调度器会维护队列的信息。用户可以向一个或者多个队列提交应用。每次NM心跳的时候,调度器会根据一定规则选择一个队列,再选择队列上的一个应用,并尝试在这个应用上分配资源。若因参数限制导致分配失败,将选择下一个应用。选择一个应用后,调度器会处理此应用的资源申请。其优先级从高到低依次为:本地资源的申请、同机架的申请,任意机器的申请。

Yarn原理

新的Hadoop MapReduce框架被命名为MRv2或Yarn。Yarn主要包括ResourceManager、ApplicationMaster与NodeManager三个部分。

  • ResourceManager:RM是一个全局的资源管理器,负责整个系统的资源管理和分配。主要由两个组件构成:调度器(Scheduler)和应用程序管理器(Applications Manager)。

(1)调度器根据容量、队列等限制条件(如每个队列分配一定的资源,最多执行一定数量的作业等),将系统中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配,而资源分配单位用一个抽象概念Container表示。Container是一个动态资源分配单位,将内存、CPU、磁盘、网络等资源封装在一起,从而限定每个任务使用的资源量。此外,该调度器是一个可插拔的组件,用户可根据自己的需要设计新的调度器,Yarn提供了多种直接可用的调度器,比如Fair Scheduler和Capacity Scheduler等。

(2)应用程序管理器负责管理整个系统中所有应用程序,包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等。

  • NodeManager:NM是每个节点上的资源和任务管理器,一方面,会定时向RM汇报本节点上的资源使用情况和各个Container的运行状态;另一方面,接收并处理来自AM的Container启动/停止等请求。
  • ApplicationMaster:AM负责一个Application生命周期内的所有工作。包括:

(1)与RM调度器协商以获取资源。

(2)将得到的资源进一步分配给内部的任务(资源的二次分配)。

(3)与NM通信以启动/停止任务。

(4)监控所有任务运行状态,并在任务运行失败时重新为任务申请资源以重启任务。

Yarn HA方案介绍

Yarn高可用性方案通过引入冗余的ResourceManager节点的方式,解决了该基础服务的可靠性和容错性问题。

ResourceManager的高可用性方案是通过设置一组Active/Standby的ResourceManager节点来实现的(如图)。与HDFS的高可用性方案类似,任何时间点上都只能有一个ResourceManager处于Active状态。当Active状态的ResourceManager发生故障时,可通过自动或手动的方式触发故障转移,进行Active/Standby状态切换。

在未开启自动故障转移时,Yarn集群启动后,MRS集群管理员需要在命令行中使用yarn rmadmin命令手动将其中一个ResourceManager切换为Active状态。当需要执行计划性维护或故障发生时,则需要先手动将Active状态的ResourceManager切换为Standby状态,再将另一个ResourceManager切换为Active状态。

开启自动故障转移后,ResourceManager会通过内置的基于ZooKeeper实现的ActiveStandbyElector来决定哪一个ResourceManager应该成为Active节点。当Active状态的ResourceManager发生故障时,另一个ResourceManager将自动被选举为Active状态以接替故障节点。

备RM升主后,能够恢复故障发生时上层应用运行的状态。当启用ResourceManager Restart时,重启后的ResourceManager就可以通过加载之前Active的ResourceManager的状态信息,并通过接收所有NodeManager上container的状态信息重构运行状态继续执行。这样应用程序通过定期执行检查点操作保存当前状态信息,就可以避免工作内容的丢失。状态信息需要让Active/Standby的ResourceManager都能访问。

Yarn与其他组件的关系

  • Yarn和Spark组件的关系

    Spark的计算调度方式,可以通过Yarn的模式实现。Spark共享Yarn集群提供丰富的计算资源,将任务分布式的运行起来。Spark on Yarn分两种模式:Yarn Cluster和Yarn Client。

    Spark on yarn-cluster实现流程:

    1、首先由客户端生成Application信息,提交给ResourceManager。

    2、ResourceManager为Spark Application分配第一个Container(ApplicationMaster),并在该Container上启动Driver。

    3、ApplicationMaster向ResourceManager申请资源以运行Container。

    4、ResourceManager分配Container给ApplicationMaster,ApplicationMaster和相关的NodeManager通讯,在获得的Container上启动Executor,Executor启动后,开始向Driver注册并申请Task。

    5、Driver分配Task给Executor执行。

    6、Executor执行Task并向Driver汇报运行状况。

    Spark on yarn-client实现流程:

    1、客户端向ResourceManager发送Spark应用提交请求,ResourceManager为其返回应答,该应答中包含多种信息(如ApplicationId、可用资源使用上限和下限等)。Client端将启动ApplicationMaster所需的所有信息打包,提交给ResourceManager上。

    2、ResourceManager收到请求后,会为ApplicationMaster寻找合适的节点,并在该节点上启动它。ApplicationMaster是Yarn中的角色,在Spark中进程名字是ExecutorLauncher。

    3、根据每个任务的资源需求,ApplicationMaster可向ResourceManager申请一系列用于运行任务的Container。

    4、当ApplicationMaster(从ResourceManager端)收到新分配的Container列表后,会向对应的NodeManager发送信息以启动Container。

    5、ResourceManager分配Container给ApplicationMaster,ApplicationMaster和相关的NodeManager通讯,在获得的Container上启动Executor,Executor启动后,开始向Driver注册并申请Task。

    6、Driver分配Task给Executor执行。Executor执行Task并向Driver汇报运行状况。

    Spark的计算调度方式,可以通过Yarn的模式实现。Spark共享Yarn集群提供丰富的计算资源,将任务分布式的运行起来。Spark on Yarn分两种模式:Yarn Cluster和Yarn Client。

    Spark on yarn-cluster实现流程:

    1、首先由客户端生成Application信息,提交给ResourceManager。

    2、ResourceManager为Spark Application分配第一个Container(ApplicationMaster),并在该Container上启动Driver。

    3、ApplicationMaster向ResourceManager申请资源以运行Container。

    4、ResourceManager分配Container给ApplicationMaster,ApplicationMaster和相关的NodeManager通讯,在获得的Container上启动Executor,Executor启动后,开始向Driver注册并申请Task。

    5、Driver分配Task给Executor执行。

    6、Executor执行Task并向Driver汇报运行状况。

    Spark on yarn-client实现流程:

    1、客户端向ResourceManager发送Spark应用提交请求,ResourceManager为其返回应答,该应答中包含多种信息(如ApplicationId、可用资源使用上限和下限等)。Client端将启动ApplicationMaster所需的所有信息打包,提交给ResourceManager上。

    2、ResourceManager收到请求后,会为ApplicationMaster寻找合适的节点,并在该节点上启动它。ApplicationMaster是Yarn中的角色,在Spark中进程名字是ExecutorLauncher。

    3、根据每个任务的资源需求,ApplicationMaster可向ResourceManager申请一系列用于运行任务的Container。

    4、当ApplicationMaster(从ResourceManager端)收到新分配的Container列表后,会向对应的NodeManager发送信息以启动Container。

    5、ResourceManager分配Container给ApplicationMaster,ApplicationMaster和相关的NodeManager通讯,在获得的Container上启动Executor,Executor启动后,开始向Driver注册并申请Task。

    6、Driver分配Task给Executor执行。Executor执行Task并向Driver汇报运行状况。

  • Yarn和MapReduce的关系

    MapReduce是运行在Yarn之上的一个批处理的计算框架。MRv1是Hadoop 1.0中的MapReduce实现,它由编程模型(新旧编程接口)、运行时环境(由JobTracker和TaskTracker组成)和数据处理引擎(MapTask和ReduceTask)三部分组成。该框架在扩展性、容错性(JobTracker单点)和多框架支持(仅支持MapReduce一种计算框架)等方面存在不足。MRv2是Hadoop 2.0中的MapReduce实现,它在源码级重用了MRv1的编程模型和数据处理引擎实现,但运行时环境由Yarn的ResourceManager和ApplicationMaster组成。其中ResourceManager是一个全新的资源管理系统,而ApplicationMaster则负责MapReduce作业的数据切分、任务划分、资源申请和任务调度与容错等工作。

    MapReduce是运行在Yarn之上的一个批处理的计算框架。MRv1是Hadoop 1.0中的MapReduce实现,它由编程模型(新旧编程接口)、运行时环境(由JobTracker和TaskTracker组成)和数据处理引擎(MapTask和ReduceTask)三部分组成。该框架在扩展性、容错性(JobTracker单点)和多框架支持(仅支持MapReduce一种计算框架)等方面存在不足。MRv2是Hadoop 2.0中的MapReduce实现,它在源码级重用了MRv1的编程模型和数据处理引擎实现,但运行时环境由Yarn的ResourceManager和ApplicationMaster组成。其中ResourceManager是一个全新的资源管理系统,而ApplicationMaster则负责MapReduce作业的数据切分、任务划分、资源申请和任务调度与容错等工作。

  • Yarn和ZooKeeper的关系

    ZooKeeper与Yarn的关系如图所示。

    1、在系统启动时,ResourceManager会尝试把选举信息写入ZooKeeper,第一个成功写入ZooKeeper的ResourceManager被选举为Active ResourceManager,另一个为Standby ResourceManager。Standby ResourceManager定时去ZooKeeper监控Active ResourceManager选举信息。

    2、Active ResourceManager还会在ZooKeeper中创建Statestore目录,存储Application相关信息。当Active ResourceManager产生故障时,Standby ResourceManager会从Statestore目录获取Application相关信息,恢复数据。

    ZooKeeper与Yarn的关系如图所示。

    1、在系统启动时,ResourceManager会尝试把选举信息写入ZooKeeper,第一个成功写入ZooKeeper的ResourceManager被选举为Active ResourceManager,另一个为Standby ResourceManager。Standby ResourceManager定时去ZooKeeper监控Active ResourceManager选举信息。

    2、Active ResourceManager还会在ZooKeeper中创建Statestore目录,存储Application相关信息。当Active ResourceManager产生故障时,Standby ResourceManager会从Statestore目录获取Application相关信息,恢复数据。

  • Yarn和Tez的关系

    Hive on Tez作业信息需要Yarn提供TimeLine Server能力,以支持Hive任务展示应用程序的当前和历史状态,便于存储和检索。

    Hive on Tez作业信息需要Yarn提供TimeLine Server能力,以支持Hive任务展示应用程序的当前和历史状态,便于存储和检索。

Yarn基于开源组件做了哪些特性增强?

Yarn基于开源组件做了哪些特性增强?

  • 任务优先级调度

    在原生的YARN资源调度机制中,如果先提交的MapReduce Job长时间地占据整个Hadoop集群的资源,会使得后提交的Job一直处于等待状态,直到Running中的Job执行完并释放资源。

    MRS集群提供了任务优先级调度机制。此机制允许用户定义不同优先级的Job,后启动的高优先级Job能够获取运行中的低优先级Job释放的资源;低优先级Job未启动的计算容器被挂起,直到高优先级Job完成并释放资源后,才被继续启动。

    该特性使得业务能够更加灵活地控制自己的计算任务,从而达到更佳的集群资源利用率。

  • YARN的权限控制

    Hadoop YARN的权限机制是通过访问控制列表(ACL)实现的。按照不同用户授予不同权限控制,主要介绍下面两个部分:

    集群运维管理员控制列表(Admin Acl)

    该功能主要用于指定YARN集群的运维管理员,其中,MRS集群管理员列表由参数“yarn.admin.acl”指定。集群运维管理员可以访问ResourceManager WebUI,还能操作NodeManager节点、队列、NodeLabel等,但不能提交任务。

    队列访问控制列表(Queue Acl)

    为了方便管理集群中的用户,YARN将用户/用户组分成若干队列,并指定每个用户/用户组所属的队列。每个队列包含两种权限:提交应用程序权限和管理应用程序权限(比如终止任意应用程序)。


    开源功能:

    虽然目前YARN服务的用户层面上支持如下三种角色:

    集群运维管理员

    队列管理员

    普通用户

    但是当前开源YARN提供的WebUI/RestAPI/JavaAPI等接口上不会根据用户角色进行权限控制,任何用户都有权限访问应用和集群的信息,无法满足多租户场景下的隔离要求。

    增强特性:

    安全模式下,对开源YARN提供的WebUI/RestAPI/JavaAPI等接口上进行了权限管理上的增强,支持根据不同的用户角色,进行相应的权限控制。

    各个角色对应的权限如下:

    集群运维管理员:拥有在YARN集群上执行管理操作(如访问ResourceManager WebUI、刷新队列、设置NodeLabel、主备倒换等)的权限。

    队列管理员:拥有在YARN集群上所管理队列的修改和查看权限。

    普通用户:拥有在YARN集群上对自己提交应用的修改和查看权限。

  • 自研超级调度器Superior Scheduler原理

    Superior Scheduler是一个专门为Hadoop YARN分布式资源管理系统设计的调度引擎,是针对企业客户融合资源池,多租户的业务诉求而设计的高性能企业级调度器。

    Superior Scheduler可实现开源调度器、Fair Scheduler以及Capacity Scheduler的所有功能。另外,相较于开源调度器,Superior Scheduler在企业级多租户调度策略、租户内多用户资源隔离和共享、调度性能、系统资源利用率和支持大集群扩展性方面都做了针对性的增强。设计的目标是让Superior Scheduler直接替代开源调度器。

    类似于开源Fair Scheduler和Capacity Scheduler,Superior Scheduler通过YARN调度器插件接口与YARN Resource Manager组件进行交互,以提供资源调度功能。下图为其整体系统图。

    图1 Superior Scheduler内部架构

    图中,Superior Scheduler的主要模块如下:

    (1)Superior Scheduler Engine:具有丰富调度策略的高性能调度器引擎。

    (2)Superior YARN Scheduler Plugin:YARN Resource Manager和Superior Scheduler Engine之间的桥梁,负责同YARN Resource Manager交互。

    在调度原理上,开源的调度器都是基于计算节点心跳驱动的资源反向匹配作业的调度机制。具体来讲,每个计算节点定期发送心跳到YARN的Resource Manager通知该节点状态并同时启动调度器为这个节点分配作业。这种调度机制把调度的周期同心跳结合在一起,当集群规模增大时,会遇到系统扩展性以及调度性能瓶颈。另外,因为采用了资源反向匹配作业的调度机制,开源调度器在调度精度上也有局限性,例如数据亲和性偏于随机,另外系统也无法支持基于负载的调度策略等。主要原因是调度器在选择作业时,缺乏全局的资源视图,很难做到好的选择。

    Superior Scheduler内部采用了不同的调度机制。Superior Scheduler的调度器引入了专门的调度线程,把调度同心跳剥离开,避免了系统心跳风暴问题。另外,Superior Scheduler调度流程采用了从作业到资源的正向匹配方法,这样每个调度的作业都有全局的资源视图,可以很大的提到调度的精度。相比开源调度器,Superior Scheduler在系统吞吐量、利用率、数据亲和性等方面都有很大提升。

    图2 Superior Scheduler性能对比


  • 支持CPU硬隔离

    YARN无法严格控制每个container使用的CPU资源。在使用CPU子系统时,container可能会超额占用资源。此时使用CPUset控制资源分配。

    为了解决这个问题,CPU将会被严格按照虚拟核和物理核的比例分配至各个container。如果container需要一整个物理核,则分配给它一整个物理核。若container只需要部分物理核,则可能发生几个container共享同一个物理核的情况。下图为CPU配额示例,假定虚拟核和物理核的比例为2:1。

  • 重启性能优化

    一般情况下,RM恢复会获取正在运行和已完成的应用。而大量的已完成的应用可能导致RM启动过慢、HA切换/重启耗时过长等问题。

    为了加速RM的启动,现在优先获取未完成的应用列表,再启动RM。此时,已完成的应用会在一个后台异步线程中继续恢复。下图展示了RM的启动恢复流程。