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之间的交互。