Hadoop_YARN资源管理系统源码解析

最新推荐文章于 2024-06-28 10:39:35 发布

原创

最新推荐文章于 2024-06-28 10:39:35 发布 · 2.5k 阅读

14 ·

CC 4.0 BY-SA版权

一、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、用户交互模块