Yarn应用程序运行流程剖析

Yarn（Yet Another Resource Negotiator）是一个Hadoop集群资源管理系统，Hadoop2时被引入，旨在提高MapReduce的性能，但YARN已足够通用，使得它可以支持其它的分布式应用。

 

Yarn本身提供了一系列API用于用户应用程序与集群资源进行交互，这些API复杂且晦涩难懂，用户通常不会直接使用。用户编制应用程序时，通常使用的是分布式计算框架（MapReduce、Spark）提供的高层次API，这些API构建在Yarn之上且隐藏资源管理细节，如下图所示：

 

 

MapReduce、Spark、Tez这样的计算框架均以Yarn应用程序的形式运行于集群计算层（Yarn）和集群存储层（HDFS或HBase）之上，而Pig、Hive、Crunch则运行于MapReduce、Spark或Tez之上，并没有与Yarn直接交互。

 

Yarn的核心服务由两个组件提供：

 

Resource Manager：每个集群一个实例，用于管理整个集群的资源使用；

 

Node Manager：每个集群多个实例，用于自身Container的启动和监测（每个Node Manager上可能有多个Container）。

 

注：根据Yarn配置的不同，Container可能是一个Unix进程或者一个Linux cgroup实例，在受限的资源范围内（如内存、CPU等）执行特定应用程序的代码。

 

运行流程

 

 

（1）Client请求Resource Manager运行一个Application Master实例（step 1）；

（2）Resource Manager选择一个Node Manager，启动一个Container并运行Application Master实例（step 2a、step 2b）；

（3）Application Master根据实际需要向Resource Manager请求更多的Container资源（step 3）；

（4）Application Master通过获取到的Container资源执行分布式计算（step 4a、step 4b）。

 

Application Master的具体逻辑与特定的应用相关，也许直接向Client返回计算结果，也可能请求更多的资源执行分布式计算（如step 3）。此外，Yarn本身并没有提供应用程序组件之间（Client、Master、Process）的通信实现，需要特定的应用程序自己提供，如使用Hadoop RPC。

 

资源请求

 

Yarn在资源请求方面拥有一个可扩展的模型，亦即可表述复杂的请求信息，如某个Container需要的计算资源量（内存或CPU），并可带有数据本地性约束需求。

 

数据本地性约束可以很大程度上节约分布式计算处理时的集群带宽消耗，可以表现为以下三种形式：

 

（1）请求位于集群特定节点上的Container；

（2）请求位于集群特定机架节点上的Container；

（3）请求位于集群任意节点上的Container。

 

数据本地性约束并不一定能够恰好满足，如果指定的节点无法启动新的Container（正在运行的Container已将资源耗尽），则尝试同一个机架的其它节点；如果也失败，则尝试集群中的其它节点。MapReduce场景下Map Container的分配就是这样的一种情况，通常可以粗略地认为每一个Map任务负责处理一个Block的数据，为了避免网络传输数据，应该尽可能的满足数据本地性约束，优先在存有Block Replica的节点上启动Container，次之在存有Block Replica的机架节点上启动Contaier，末之在集群中的其余节点上启动Container。

 

一个处于运行状态的Yarn应用程序可以在任何时候发起资源请求，比如应用启动时一次性请求所有资源（Spark），或者以动态的方式不断请求更多的资源满足应用的需要（MapReduce，首先请求全部的Map资源，稍后请求Reduce资源，如果某些Task失败，还会申请更多的资源用于失败恢复）。

 

应用程序生存期

 

Yarn应用程序的生存期跨度比较大：从运行几秒钟的短任务应用到运行几天甚至几月的长任务应用。相对于运行时间而言，一种更有效的方式是根据Application与Job的映射关系划分，常见以下三种情况：

 

（1）一个Application对应一个Job（MapReduce）；

（2）一个Application对应一个Workflow（Session）的所有Jobs，这种方式可以在多个Jobs之间重用Containers并有效缓存中间数据（Spark）；

（3）一个Long-Running  Application被多个用户共享，这种应用多数充当“Coordination”角色（Slider、Impala）。

 

构建Yarn应用程序

 

我们自己动手从头到尾构建一个Yarn应用程序是比较复杂的，很多时候也是不必要的，可以根据需要的不同选择一个优秀的分布式计算框架帮助我们构建应用程序，如需要DAG计算，则选择Spark、Tez；需要流式处理，则选择Spark、Samza或Storm。

 

也有一些开源项目帮助我们简化Yarn应用程序的构建，如Slider、Twill，目前均处于孵化器状态，暂时不讨论。Yarn本身也自带了一个例子“Distributed Shell Application”，向我们展示了如果通过Yarn Client API完成Client、Application Master与Yarn Daemons之间的交互。