走向云计算之Hadoop YARN的基本原理和运行流程

一、概述

Yarn是Hadoop集群的资源管理系统。Hadoop2.0对MapReduce框架做了彻底的设计重构，我们称Hadoop2.0中的MapReduce为MRv2或者Yarn。我们先回头看一下Hadoop1.x的MapReduce模型。

Yarn的产生直接源于MRv1在几个方面的缺陷

• 扩展性受限
• 单点故障
• 难以支持MR之外的计算
• 多计算框架各自为战，数据共享困难
  MR：离线计算框架
  Storm：实时计算框架
  Spark：内存计算框架

到了Hadoop2.x也就是Yarn，它的目标是将功能分开，也就是分别用两个进程来管理这两个任务：

• ResourceManger
• ApplicationMaster

需要注意的是，在Yarn中我们把job的概念换成了application，因为在新的Hadoop2.x中，运行的应用不只是MapReduce了，还有可能是其它应用如一个DAG（有向无环图Directed Acyclic Graph，例如storm应用）。Yarn的另一个目标就是拓展hadoop，使得它不仅仅可以支持MapReduce计算，还能很方便的管理诸如Hive、Hbase、Pig、Spark/Shark等应用。这种新的架构设计能够使得各种类型的应用运行在Hadoop上面，并通过Yarn从系统层面进行统一的管理，也就是说，有了Yarn，各种应用就可以互不干扰的运行在同一个Hadoop系统中，共享整个集群资源，如下图所示：

二、Yarn的基本架构

YARN总体上仍然是Master/Slave结构，在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。基本架构如下图：

1、ResourceManager

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

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

2、NodeManager

NodeManager整个集群有多个，负责单节点资源管理和使用。详细功能如下：

• 单个节点上的资源管理和任务管理
• 处理来自ResourceManager的命令
• 处理来自ApplicationMaster的命令

3、ApplicationMaster

用户提交的每个应用程序均包含1个ApplicationMaster，主要功能包括：

• 与ResourceManager调度器协商以获取资源（用Container表示）；
• 将得到的任务进一步分配给内部的任务；
• 与NodeManager通信以启动/停止任务；
• 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

存在一些其他的计算框架对应的ApplicationMaster，比如Open MPI、Spark等。

4、Container

Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当ApplicationMaster向ResourceManager申请资源时，ResourceManager为ApplicationMaster返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。
需要注意的是，Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。目前，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制Cgroups进行资源隔离。

三、YARN运行和容错

1、基本运行流程

当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：
第一个阶段是启动ApplicationMaster；
第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。
其运行基本流程如下：

1、用户向YARN（ResourceManager）中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
2、ResourceManager为该应用程序分配第一个Container，并与对应的NodeManager通信。
3、NodeManager按照要求在这个Container中启动应用程序的ApplicationMaster。
4、ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~6。ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
5、一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。
6、NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
7、应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。

2、YARN的容错性

1、ResourceManager

• 因为集群中只有一个，所以存在单点故障；
• 正在基于ZooKeeper实现HA。

2、NodeManager

• 任务失败后，ResourceManager将失败任务告诉对应的ApplicationMaster。
• ApplicationMaster决定如何处理失败的任务。

3、ApplicationMaster

• 任务失败后，由ResourceManager负责重启；
• ApplicationMaster需处理内部任务的容错问题；
• RMAppMaster会保存已经运行完成的Task，重启后无需重新运行。

四、MapReduce 2.0与YARN的关系

MapReduce2.0由YARN(整个集群只有一个)和MRAppMaster（一个应用程序一个）以及用户代码（Mapper、Reducer…）共同组成。MapReduce 1.0和MapReduce 2.0区别如下：

• MapReduce 1.0是一个独立的系统，直接运行在Linux之上。
• MapReduce 2.0则是运行YARN上的框架，且可与多种框架一起运行在YARN上。

MapReduce 2.0和YARN关系如下：

• YARN是一个资源管理系统，负责资源管理和调度
• MapReduce只是运行在YARN上的一个应用程序，如果把YARN看做“android”，则MapReduce只是一个“app”。