Hadoop_YARN资源管理系统源码解析

目录

一、YARN产生的背景(MRv1的局限性)

二、YARN源代码结构

三、YARN基本架构

四、YARN各模块详细分析

五、MRAppMaster-MapReduce On YARN实现

六、YarnChild-MR引擎启动入口

七、总结

 

一、YARN产生的背景(MRv1的局限性)

YARN 是在 MRv1 基础上演化而来的，它克服了 MRv1 中的各种局限性。在正式介绍 YARN 之前，我们先要了解 MRv1 的一些局限性，这可概括为以下几个方面:

❑ 扩展性差。在 MRv1 中，JobTracker 同时兼备了资源管理和作业控制两个功能，这成为系统的一个最大瓶颈，严重制约了Hadoop集群扩展性。

❑ 可靠性差。MRv1 采用了Master/Slave结构，其中，Master(JobTracker)存在单点故障问题，一旦它出现故障将导致整个集群不可用。

❑ 资源利用率低。MRv1 采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源 划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空 闲资源。此外，Hadoop 将槽位分为 Map Slot 和 Reduce Slot 两种，且不允许它们之 间共享，常常会导致一种槽位资源紧张而另外一种闲置(比如一个作业刚刚提交时， 只会运行Map Task，此时Reduce Slot 会闲置)。

❑ 无法支持多种计算框架。随着互联网高速发展，MapReduce这种基于磁盘的离线计算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、 流式计算框架和迭代式计算框架等，而这些新的计算框架是无法运行在MRv1上的。

为了克服以上几个缺点，Apache开始尝试对Hadoop进行升级改造，进而诞生了更加先进的下一代MapReduce计算框架 MRv2。正是由于MRv2将资源管理功能抽象成了一个独立的通用系统YARN，直接导致下一代MapReduce的核心从单一的计算框架MapReduce转移为通用的资源管理系统YARN。为了进一步理解以YARN为核心的软件栈， 我们将之与以MapReduce为核心的软件栈进行对比，在以MapReduce为核心的软件栈中，资源管理系统 YARN 是可插拔替换的，比如选择 Mesos替换YARN，一旦MapReduce接口改变，所有的资源管理系统的实现均需要跟着改变 ;但以 YARN 为核心的 软件栈则不同，所有框架都需要实现 YARN 定义的对外接口以运行在YARN之上，这意味着Hadoop 2.0可以打造一个以YARN为核心的生态系统。

                         

                图1 MRV1的基本架构                                                 图2 YARN作为通用资源管理系统的的基本架构

 

MRv1主要由两类服务组成，分别是 JobTracker 和TaskTracker。其中，JobTracker负责集群资源资源和作业管理，TaskTracker负责单个节点的资源管理和任务管理。MRv1将资源管理和作业管理两部分混杂在一 起，使得它在扩展性、容错性和多框架支持等方面存在明显缺陷。而 MRv2 则通过将资源管理和作业管理两部分剥离开，分别由YARN和ApplicationMaster负责，其中，YARN专管资源管理和调度，而ApplicationMaster则负责应用程序的生命周期。总结：MRv2将MRv1中JobTracker的集群资源管理功能抽出来变成YARN中的ResourceManager，将MRv1中的TaskTracker的节点资源管理抽出来变成YARN中的NodeManager，将MRv1中JobTracker的作业管理及TaskTracker的任务管理抽出来变成YARN中的ApplicationMaster，使得YARN在扩展性、容错性和多框架支持等方面相比MRv1都有明显的改进。

 

二、YARN源代码结构

在 Hadoop 的JAR压缩包解压后的目录 hadoop-{VERSION} 中包含了 Hadoop 全部的 管理脚本和JAR包，下面简单对这些文件或目录进行介绍。

❑ bin：Hadoop 最基本的管理脚本和使用脚本所在目录，这些脚本是 sbin 目录下管理 脚本的基础实现，用户可以直接使用这些脚本管理和使用 Hadoop。

❑ etc：Hadoop 配置文件所在的目录，包括 core-site.xml、hdfs-site.xml、mapred-site. xml 等从 Hadoop 1.0 继承而来的配置文件和 yarn-site.xml 等 Hadoop 2.0 新增的配置 文件。

❑ include：对外提供的编程库头文件(具体动态库和静态库在 lib 目录中)，这些头文 件均是用 C++ 定义的，通常用于 C++ 语言访问 HDFS 或者编写 MapReduce 程序。

❑ lib：该目录包含了 Hadoop 对外提供的编程动态库和静态库，与 include 目录中的头 文件结合使用。

❑ libexec：各个服务对应的 Shell 配置文件所在目录，可用于配置日志输出目录、启 动参数(比如 JVM 参数)等基本信息。

❑ sbin：Hadoop 管理脚本所在目录，主要包含 HDFS 和 YARN 中各类服务的启动/关闭脚本。

❑ share：Hadoop 各个模块编译后的 JAR 包所在目录。

在 Hadoop 源代码压缩包解压后的目录 hadoop-{VERSION}-src 中，可看到如图1

示的目录结构，其中，比较重要的目录有 :hadoop-common-project、hadoop-mapreduce- project、hadoop-hdfs-project 和 hadoop-yarn-project 等，下面分别介绍这几个目录的作用。

❑ hadoop-common-project：Hadoop 基础库所在目录，该目录中包含了其他所有模块可 能会用到的基础库，包括 RPC、Metrics、Counter 等。  

                                                                     

                                                                       图3 Hadoop源码目录结构

❑ hadoop-mapreduce-project :MapReduce 框架的实现，在 MRv1 中，MapReduce 由编程模 型(map/reduce)、调度系统(JobTracker 和 TaskTracker)和数据处理引擎(MapTask 和 ReduceTask)等模块组成，而此处的 MapReduce 则不同于 MRv1 中的实现，它的资 源调度功能由新增的 YARN 完成(编程模型和数据处理引擎不变)，自身仅包含非 常简单的任务分配功能。

❑ hadoop-hdfs-project :Hadoop 分布式文件系统实现，不同于 Hadoop 1.0 中单 NameNode 实现，Hadoop 2.0 支持多 NameNode，同时解决了 NameNode 单点故障问题。

❑ hadoop-yarn-project :Hadoop 资源管理系统 YARN 实现。这是 Hadoop 2.0 新引入的 分支，该系统能够统一管理系统中的资源，并按照一定的策略分配给各个应用程序。

下面就对Hadoop YARN源代码组织结构进行介绍。

总体上看，Hadoop YARN 分为 5 部分 :API、Common、Applications、Client 和 Server， 它们的内容具体如下:

❑ YARN API(hadoop-yarn-api 目录):给出了 YARN 内部涉及的 4 个主要 RPC 协议的 Java 声明和 Protocol Buffers 定义，这 4 个 RPC 协议分别是 ApplicationClientProtocol、 ApplicationMasterProtocol、ContainerManagementProtocol 和 ResourceManagerAdministrationProtocol。

❑ YARN Common(hadoop-yarn-common 目录):该部分包含了 YARN 底层库实现， 包括事件库、服务库、状态机库、Web 界面库等。

❑ YARN Applications(hadoop-yarn-applications 目录):该部分包含了两个 Application 编程实例，分别是 distributedshell 和 Unmanaged AM。

❑ YARN Client(hadoop-yarn-client 目录):该部分封装了几个与 YARN RPC 协议交互 相关的库，方便用户开发应用程序。

❑ YARN Server(hadoop-yarn-server 目录):该部分给出了 YARN 的核心实现，包括ResourceManager、NodeManager、资源管理器等核心组件的实现。

                                                               

                                                                图4 Hadoop YARN目录组织结构

 

三、YARN基本架构

        YARN是Hadoop 2.0 中的资源管理系统，它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务 :一个全局的资源管理器ResourceManager和每个应用程序特有的     ApplicationMaster。其中ResourceManager负责全局的资源管理及调度，而 ApplicationMaster负责单个应用程序的生命周期管理。

 

3.1、YARN基本组成结构

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

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

                                                        

1. ResourceManager(RM)

RM是一个全局的资源管理器，负责整个集群的资源管理与调度（个人理解类似于MRv1时的JobTracker，只是把JobTracker作业管理相关的这块移到了ApplicationMaster中，只负责纯粹通用的资源管理与调度，做到了计算框架无关）。主要功能是包括资源管理与调度、ApplicationMaster管理(启动应用程序的AM)、NodeManager管理等。

❑ 与客户端进行交互，处理来自于客户端的请求，如提交应用程序、查询应用的运行情况等。

❑ 启动和管理各个应用程序的ApplicationMaster，并且为ApplicationMaster申请第一个Container用于启动和在它运行失败时将它重新启动。

❑ 管理NodeManager，接收来自NodeManager的资源和节点健康情况汇报，并向NodeManager下达资源管理命令，例如kill掉某个container。

❑ 资源管理与调度，接收来自ApplicationMaster的资源申请请求，并为之分配资源。这个是它最重要的职能。YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler。

2. ApplicationMaster(AM)

AM是一个应用程序管理器，负责一个应用程序的生命周期管理（管理Job中的各个task，申请资源并管理Job内的资源分配）。用户提交的每个应用程序均包含一个 AM，主要功能包括: 

❑ 与 RM 调度器协商以获取资源(用 Container 表示);

❑ 将得到的资源进一步分配给内部的任务;

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

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

当 前 YARN 自 带 了 两 个 AM 实 现， 一 个 是 用 于 演 示 AM 编 写 方 法 的 实 例 程 序

distributedshell，它可以申请一定数目的 Container 以并行运行一个 Shell 命令或者 Shell 脚本 ; 另一个是运行 MapReduce 应用程序的 AM— MRAppMaster。此外，一些其他的计算框架对应的 AM 正在开发中，比如 Open MPI、Spark 等  。

3. NodeManager(NM)

NM 是单个节点上的资源管理器（个人理解类似于MRv1时的TaskTracker，只是把TaskTracker任务管理这块移到了ApplicationMaster中，只负责纯粹通用的资源管理与调度，做到了计算框架无关），一方面，它会定时地向 RM 汇报本节点上的 资源使用情况和各个 Container 的运行状态;另一方面，它接收并处理来自 AM 的 Container 启动 / 停止等各种请求。

4. Container

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

 

3.2、YARN通信协议

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

❑ JobClient(作业提交客户端)与 RM 之间的协议 — ApplicationClientProtocol : JobClient 通过该 RPC 协议向RM提交应用程序、查询应用程序状态等。

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

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

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

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

                                                 

                                                                            图5 Hadoop YARN的RPC协议

为了提高 Hadoop 的向后兼容性和不同版本之间的兼容性，YARN 中的序列化框架采用 了 Google 开源的 Protocol Buffers。

3.3、YARN工作流程

       运行在 YARN 上的应用程序主要分为两类 :短应用程序和长应用程序，其中，短应用程序是指一定时间内(可能是秒级、分钟级或小时级，尽管天级别或者更长时间的也存在，但非常少)可运行完成并正常退出的应用程序，比如 MapReduce 作业、Tez DAG 作业等，长应用程序是指不出意外，永不终止运行的应用程序，通常是一些服务，比如 Storm Service(主要包括 Nimbus 和 Supervisor 两类服务)，HBase Service(包括 Hmaster 和 RegionServer 两类服务)   等，而它们本身作为一个框架提供了编程接口供用户使用。尽管这两类应用程序作用不同，一类直接运行数据处理程序，一类用于部署服务(服务之上再运行数据处理程序)，但运行在 YARN 上的流程是相 同的。当用户向 YARN 中提交一个应用程序后，YARN 将分两个阶段运行该应用程序 :第一 个阶段是启动 ApplicationMaster ;第二个阶段是由 ApplicationMaster 创建应用程序，为它 申请资源，并监控它的整个运行过程，直到运行完成。如图 2-11 所示，YARN 的工作流程 分为以下几个步骤:

                                                   

                                                                          图6 Hadoop YARN的工作流程

步骤 1 用户向 YARN 中提交应用程序，其中包括 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序等。

步骤 2 ResourceManager 为该应用程序分配第一个 Container，并与对应的 Node- Manager 通信，要求它在这个 Container 中启动应用程序的 ApplicationMaster。

步骤 3 ApplicationMaster 首先向 ResourceManager 注册，这样用户可以直接通过 ResourceManage 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运 行状态，直到运行结束，即重复步骤 4~7。

步骤 4 ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和 领取资源。

步骤 5 一旦 ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求 它启动任务。

步骤 6 NodeManager 为任务设置好运行环境(包括环境变量、JAR 包、二进制程序 等)后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。

步骤 7 各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以 让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。

在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当 前运行状态。

步骤 8 应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己。

 

四、YARN各模块详细分析

接下来将分析各个重要模块，ResourceManager、NodeManager、MRAppMaster、YarnChild。如下如所示：

                                  

                                                                                    图7 Hadoop YARN详细模块

4.1、ResourceManager

        同MRv1一样，YARN也采用了Master/Slave结构，其中，Master实现为ResourceManager，负责整个集群的资源管理与调度；Slave实现为NodeManager，负责单个节点的资源管理与调度及任务启动。ResourceManager是整个YARN集群中最重要的组件之一，主要功能是包括资源管理与调度、ApplicationMaster管理(启动应用程序的AM)、Application管理等、NodeManager管理等。在YARN中，ResourceManager负责集群中所有资源的统一管理和分配（个人理解类似于MRv1时的JobTracker，只是把JobTracker作业管理这块移到了ApplicationMaster中，只负责纯粹通用的资源管理与调度，做到了计算框架无关），它接收来自各个节点（NodeManager）的资源汇报信息，并把这些信息按照一定的策略分配给各个应用程序（ApplicationMaster）。接下来就来分析下RM内部组成的各个功能组件和他们相互的交互方式。

 一、ResourceManager的交互协议与基本职能

 1、ResourceManager交互协议

    在整个Yarn框架中主要涉及到7个协议，分别是ApplicationClientProtocol、MRClientProtocol、ContainerManagementProtocol、ApplicationMasterProtocol、ResourceTracker、LocalizationProtocol、TaskUmbilicalProtocol，这些协议封装了各个组件交互的信息。ResourceManager现实功能需要和NodeManager以及ApplicationMaster进行信息交互，其中涉及到的RPC协议有ResourceTrackerProtocol、ApplicationMasterProtocol和ResourceTrackerProtocol。

• ResourceTracker

    NodeManager通过该协议向ResourceManager中注册、汇报节点健康情况以及Container的运行状态，并且领取ResourceManager下达的重新初始化、清理Container等命令。NodeManager和ResourceManager这种RPC通信采用了和MRv1类似的“pull模型”（ResourceManager充当RPC server角色，NodeManager充当RPC client角色），NodeManager周期性主动地向ResourceManager发起请求，并且领取下达给自己的命令。

• ApplicationMasterProtocol

  应用程序的ApplicationMaster同过该协议向ResourceManager注册、申请和释放资源。该协议和上面协议同样也是采用了“pull模型”，其中在RPC机制中，ApplicationMaster充当RPC client角色，ResourceManager充当RPC server角色。

• ApplicationClientProtocol

          客户端通过该协议向ResourceManager提交应用程序、控制应用程序（如杀死job）以及查询应用程序的运行状态等。在该RPC 协议中应用程序客户端充当RPC client角色，                                ResourceManager充当RPC server角色。

整理一下ResourceManager与NodeManager、ApplicationMaster和客户端RPC协议交互的信息：

                                                  

                                                                         图8 ResourceManager相关的RPC协议

上图中的ResourceTrackeService、ApplicationMasterService 、ClientRMService是ResourceManager中处理上述功能的组件，充当RPC_Servser。

2、ResourceManager基本职能

ResourceManager基本职能概括起来就以下几方面：

• 与客户端进行交互，处理来自于客户端的请求，如提交应用程序、查询应用的运行情况等。

• 启动和管理各个应用程序的ApplicationMaster，并且为ApplicationMaster申请第一个Container用于启动和在它运行失败时将它重新启动。

• 管理NodeManager，接收来自NodeManager的资源和节点健康情况汇报，并向NodeManager下达资源管理命令，例如kill掉某个container。

• 资源管理与调度，接收来自ApplicationMaster的资源申请请求，并为之分配资源。这个是它最重要的职能。

二、ResourceManager内部组成架构分析

ResourceManager在底层代码实现上将各个功能模块分的比较细，各个模块功能具有很强的独立性。下图所示的是ResourceManager中的大概的功能模块组成：

                                            

                                                                                   图9 ResourceManager内部架构图

ResourceManager内部架构代码概况如下：

public class ResourceManager extends CompositeService implements Recoverable {
  /**
   * Priority of the ResourceManager shutdown hook.
   */
  public static final int SHUTDOWN_HOOK_PRIORITY = 30;
  private static final Log LOG = LogFactory.getLog(ResourceManager.class);
  public static final long clusterTimeStamp = System.currentTimeMillis();
 
  // ApplicationClientProtocol协议的RPC_Server
  private ClientRMService clientRM;
  
  // ContainerManagementProtocol协议的RPC_Client，以启动应用程序的ApplicationMaster
  private ApplicationMasterLauncher applicationMasterLauncher;
  
  // ResourceTracker协议的RPC_Server
  protected ResourceTrackerService resourceTracker;

  // ApplicationMasterProtocol协议的RPC_Server
  protected ApplicationMasterService masterService;
  
  // 资源管理器
  protected ResourceScheduler scheduler;
  
  private Dispatcher rmDispatcher;
  ...
}

1、用户交互模块