12.3　Apache YARN

YARN是Apache的下一代MapReduce框架。它的基本设计思想是将JobTracker拆分成两个独立的服务：一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中，ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster则负责单个应用程序的管理。

12.3.1　Apache YARN基本框架

YARN总体上仍然是master/slave结构。在整个资源管理框架中，ResourceManager为master, NodeManager为slave, ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用于跟踪和管理这个程序的ApplicationMaster。它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定资源的任务。由于不同的ApplicationMaster分布在不同的节点上，因此它们之间不会相互影响。在本小节中，我们将从基本组成结构和RPC框架两方面对YARN进行介绍。

1.YARN的基本组成结构

图12-5描述了YARN的基本组成结构。YARN主要由ResourceManager、NodeManager、ApplicationMaster（图中给出了MapReduce和MPI两种计算框架的ApplicationMaster，分别为MR AppMstr和MPI AppMstr）和Container等几个组件构成。

图　12-5　Apache YARN的基本架构

（1）ResourceManager（RM）

RM是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用管理器（Applications Manager, ASM）。

调度器

调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。需要注意的是，该调度器是一个“纯调度器”，它从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。调度器仅根据各个应用的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示。Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler等。

应用程序管理器

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

为了保证高可用性，ResourceManager将所有状态信息保存到了Zookeeper^[1]中，它可以通过保存在Zookeeper中的状态快速重启。

（2）ApplicationMaster（AM）

用户提交的每个应用程序均包含一个AM。它实际上是一个简化版的JobTracker，主要功能包括：

❑与RM调度器协商以获取资源。

❑与NM通信以启动/停止任务。

❑监控所有任务的运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

当前YARN自带了两个AM实现：一个是用于演示AM编写方法的实例程序distributedshell，它可以申请一定数目的Container运行一个shell命令或者shell脚本；另一个是运行MapReduce应用程序的AM——MRAppMaster，我们将在12.3.4节对其进行介绍。此外，一些其他的计算框架对应的AM正在开发中，比如Open MPI、Spark等^[2]。

（3）NodeManager（NM）

NM是每个节点上的资源和任务管理器。一方面，它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，它接收并处理来自AM的任务启动/停止等各种请求。

（4）Container

Container是YARN中的资源分配单位，它封装了多维度的资源，如内存、CPU、磁盘、网络等。当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN中每个任务均会对应一个Container，且该任务只能在该Container中执行，并仅能使用该容器代表的资源量。需要注意的是，Container不同于MRv 1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。截至完成此书时，YARN仅支持CPU和内存两种资源，且使用了Linux Container进行资源隔离^[3]。

2.YARN的RPC协议与序列化框架

RPC协议是连接各个组件的“大动脉”，了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。在YARN中，任何两个需相互通信的组件之间仅有一个RPC协议，而对于任何一个RPC协议，通信双方有一端是Client，另一端为Server，且Client总是主动连接Server，因此，YARN实际上采用的是拉式（pull-based）通信模型。如图12-6所示，YARN主要由以下几个RPC协议组成。

图　12-6　Apache YARN的RPC协议

❑Job Client（作业提交客户端）与RM之间的协议——ClientRMProtocol：Client通过该RPC协议提交应用程序，查询应用程序状态等。

❑Administrator（管理员）与RM之间的通信协议——RMAdminProtocol：Administrator通过该RPC协议更新系统配置文件，比如节点黑白名单、用户队列权限等。

❑AM与RM之间的协议——AMRMProtocol：Job AM通过该RPC协议向RM注册和撤销自己，并为各个任务申请资源。

❑AM与NM之间的协议——ContainerManager：AM通过该RPC协议要求NM启动或者停止Container，获取各个Container的使用状态等信息。

❑NM与RM之间的协议——ResourceTracker：NM通过该RPC协议向RM注册，并定时发送心跳信息汇报当前节点的资源使用情况和Container运行情况。

为了提高Hadoop的向后兼容性和不同版本之间的兼容性，YARN中的序列化框架采用了Google开源的Protocol Buffers。Protocol Buffers的引入使得YARN（与MRv 1相比）在兼容性方面向前迈进了一大步。

[1]http://zookeeper. apache.org/

[2]http://wiki. apache.org/hadoop/PoweredByYarn

[3]https://issues. apache.org/jira/browse/YARN-3