Spark on YARN框架部署与管理

1.YARN框架解析

YARN是Hadoop 2.0系统上的资源统一管理平台，其主要作用是实现集群资源的统一管理和调度，它的基本设计思想是将MRv1中的JobTracker拆分成两个独立的服务：一个全局的资源管理器ResourceManager（RM）和每个应用程序特有的ApplicationMaster（AM）。

通常，当集群中存在多种计算框架时，使用YARN统一管理资源要比SparkStandalone更合适，更利于资源的合理调度与充分利用。

说明：在集群中只需启动YARN服务，通常底层也使用HDFS存储系统，因此对应也启动HDFS服务。此外，Spark Standalone部署时的Master和Worker在逻辑上的对应组件已经由YARN框架提供，因此不

图3-7 Hadoop YARN框架的基本结构

下面参考《Hadoop技术内幕：深入解析YARN的架构设计和实现原理》一书，简单描述框架中的主要组件。

（1）ResourceManager（RM）

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

1）调度器。调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。

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

2）应用程序管理器。应用程序管理器负责管理整个系统中所有的应用程序，包括应用

需要再启动，也就是说，Spark on YARN部署时，只需要提供可以提交Spark应用的客户端即可，之后提交的应用程序由YARN框架负责调度、执行及监控等。

和Spark Standalone集群一样，在资源管理调度上，YARN也采用Master/Slave结构，在整个资源管理框架中，ResourceManager对应Master，NodeManager对应Slave。其中，Re-sourceManager负责各个NodeManager资源的统一管理和调度，NodeManager则负责启动任务，以及各个任务间的具体资源的隔离。YARN框架如图3-7所示。程序提交、与调度器协商资源以启动ApplicationMaster，以及监控ApplicationMaster的运行状态并在失败时重新启动它等。

（2）ApplicationMaster（AM）

用户提交的每个应用程序均包含1个AM，主要功能包括以下几个。

·与RM调度器协商以获取资源（用Container表示）。

·将得到的任务进一步分配给内部任务。

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

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

当前YARN自带了两个AM实现，一个是用于演示AM编写方法的实例程序distributed-shell，它可以申请一定数目的Container，以并行运行一个Shell命令或者Shell脚本；另一个是运行MapReduce应用程序的AM-MRAppMaster，此外，一些其他的计算框架对应的AM正在开发中，如Open MPI、Spark等。

（3）NodeManager（NM）(www.xing528.com)

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

（4）Container

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

需要注意的是，Container不同于MRv1中的Slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。目前，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制Cgroups来进行资源隔离。

2.YARN上应用程序开发解析

当使用Spark on YARN方式提交Spark应用程序时，Spark需要实现YARN应用程序接入的接口要求。关于在YARN上开发应用程序的相关内容，可以参考《Hadoop技术内幕：深入解析YARN的架构设计和实现原理》一书的相关章节，这里仅给出简单的分析，以便后续对Spark on YARN相关部分进行解析。

用户在YARN上开发应用时，需要实现以下3个模块。

1）Application Client：负责将应用程序提交到YARN上，同时，监控应用的运行状态，控制应用的运行。

2）Application Master（AM）：负责整个应用的运行控制，包括向YARN注册应用、申请资源和启动容器等，其中，容器是抽象的资源分配单位。

3）Application Worker：负责应用的实际工作，并不是所有的应用都需要编写Worker。NodeManager启动AM发送过来的容器，容器内部封装了该应用Worker运行所需的资源和启动的命令。

要实现上述模块，涉及以下3个RPC协议。

1）ApplicationClientProtocol：Client-RM之间的协议，主要用于应用的提交。

2）ApplicationMasterProtocol：AM-RM之间的协议，AM通过该协议向RM注册并申请资源。

3）ContainerManagementProtocol：AM-NM之间的协议，AM通过该协议控制NM启动容器。

3.Spark on YARN框架解析

Spark on YARN部署框架的解析，实际上大部分已经由YARN框架本身决定了，因此对应的部署框架仅需要关注如何将Spark应用程序提交到YARN框架上。

通过比较Spark Standalone与YARN框架上应用程序本身的组成结构，可以看到两者都是采用类似集群Master/Slave部署的这种结构。即，无论是YARN还是Spark Standalone集群，应用程序本身也带有Master/Slave形式的组成结构，对应为应用程序的驱动程序和应用程序被拆分的各个逻辑执行单位（可以抽象对应到Task或Executor），其中驱动程序部分对应Master，而各个逻辑执行单位对应Slave。将计算与资源拆分开，两者可以对等比较，如图3-8所示。

图3-8 Spark on YARN框架解析

图3-8包含了两种层面上的Master/Slave框架，左边对应的是应用层面的，有作为Mas-ter角色的AppMstr和作为Slave角色的Container（具体运行时）。右边对应的是资源层面，同样有作为Master角色的ResourceMstr和作为Slave角色的Node Manager。如果继续扩展的话，计算、资源和存储等各个层面，甚至于在计算层面上也可以由计算时调度对象的粒度不同而进一步分层，这些层面都可以采用这种中心化的Master/Slave框架来实现分布式的计算、资源管理与分配和存储管理等等。中间的Request/Response是计算的应用与资源管理间的资源申请与分配，对应可以理解为计算与资源两个解耦之后的组件间的交互。