HDFS学习笔记（五）：Yarn架构原理

1、Yarn 产生背景

    Apache Yarn（Yet Another Resource Negotiator）是 Hadoop 集群资源管理器系统，Yarn 从 Hadoop 2 引入，最初是为了改善 MapReduce 的实现，但是它具有通用性，同样适用于其他分布式计算模型中。

1.1 MapReduce1 的局限性

MapReduce1 中，具有以下局限性：

1）扩展性差：在 MapReduce1 中 JobTracker 同时兼备资源管理和作业控制两个功能，这成为系统的最大瓶颈，严重制约了 Hadoop 集群扩展性（任务多时内存开销大，上限4000节点）。
2）可靠性差：MapReduce1 采用了 master/salve 结构，其中，master 存在单点故障问题，一旦它出现故障将导致整个集群不可用。
3）资源利用率低：MapReduce1 采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲的资源。Hadoop1 将槽位分为 Map Slot 和 Redue Slot 两种，且不允许他们之间共享，常常会导致一种槽位资源紧张而另外一种闲置（比如一个作业刚刚提交时，只会运行 Map Slot，此时 Reduce Slot 闲置）。
4）不支持多种计算框架：不支持包括内存计算框架、流式计算框架、迭代式计算框架等。

1.2 Yarn 设计思想

Yarn 的基本设计思想：将 JobTracker 的两个主要功能，即资源管理和作业控制（包括作业监控容错等），分拆成两独立的进程。
    资源管理进程与具体应用程序无关，它负责整个集群的资源（内存、CPU、磁盘等）管理，而作业控制进程则直接与应用程序相关的模块，且每隔作业控制进程只负责管理一个作业。这样，通过将原有 JobTracker 中与应用程序相关和无关的模块分开，不仅减轻了 JobTracker 负载，也使得 Hadoop 支持更多的计算框架。

yarn 有以下特点：
1）通用资源管理系统和调度平台，支持多计算框架
2）可扩展性强
3）提高资源利用率
4）可通过搭建为HA

Hadoop1.x 和 Hadoop2.x 的区别：

2、Yarn 基本组成架构

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

Yarn 由以下几个组件构成：
1）ResourceManager
2）NodeManager
3）ApplicationMaster（下图给出了 MapReduce 和MPI 两种计算框架的 ApplicationMaster，分别为 MR APPMstr 和 MPI AppMstr）
4）Container

2.1、ResourceManager（RM）

    RM 是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：

• 调度器（Scheduler）
• 应用管理器（Application Manager，AM）

2.1.1、调度器（Scheduler）

    调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。

    调度器不在从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用执行状态等，也不负责启动因应用执行失败或者硬件故障而产生的的失败任务，这些均由应用程序相关的 ApplicationMaster 完成。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resouce Container，简称 Container）标识，Container 是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
    调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，Yarn 提供了多种直接可用的调度器。

FIFO Scheduler：先进先出，不考虑作业优先级和范围，适合低负载集群。
Capacity Scheduler：将资源分为多个队列，允许共享集群，有保证每个队列最小资源的使用。
Fair Scheduler：公平的将资源分给应用的方式，使得所有应用在平均情况下随着时间得到相同的资源份额。

2.1.2、应用管理器（ApplicationManager）

    应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。

2.2、ApplicationMaster（AM）

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

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

2.3、NodeManager（NM）

    NM 是每个节点上的资源和任务管理器，一方面，它会定时地向 RM 汇报本节点上的资源使用情况和各个 Container 的运行状态；另一方面，它接收并处理来自 AM 的 Container 启动/停止等各种请求。

2.4、Container

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

3、Yarn 通信机制

    RPC 协议是连接各个组件的主要协议，任何两个需要互通的组件之间仅有一个 RPC 协议，RPC 协议分为 Client 和 Server端，Client 总是主动连接 Server 端。Yarn 采用的是（pull-based）通信模型。

• JobClient（作业提交客户端）与 RM 之间的协议 —ApplicationClientProtocol ： JobClient 通过该 RPC 协议提交应用程序、查询应用程序状态等。
• 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 运行情况

4、Yarn 工作流程

Yarn 将分两个阶段运行该应用程序 ：
第一个阶段：启动 ApplicationMaster
第二个阶段：由 ApplicationMaster 创建应用程序，为它 申请资源，并监控它的整个运行过程，直到运行完成

步骤：

1. 用户向 Yarn 中提交应用程序， 其中包括 MRAppMaster 程序、 启动 MRAppMaster 的命令、用户程序等。(MRAppMstr 程序在客户端生成，这一步已经将应用程序先行程序提交到RM的Application Manager模块进行处理，但此时运行程序所需的jar包、环境变量、切片信息等提交到HDFS之上，需要等MRAPPMstr返回一个可用的Container的时候在节点提交执行。可以理解为惰性处理，减少资源占用，做到需要什么提交什么)
2. ResourceManager 为该应用程序分配第一个 Container，并与对应的 Node-Manager 通信，要求它在这个 Container 中启动应用程序的MRAppMaster。（APPMaster就是先头兵，这时的操作是RM的ApplicationManager来进行处理）
3. MRAppMaster 首先向 ResourceManager 注册， 这样用户可以直接通过ResourceManage 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到整个应用运行结束。
4. MRAppMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和 领取资源。
5. 一旦 MRAppMaster 申请到资源后，便与对应的 NodeManager 通信，要求 它启动任务。(理解集群中不同节点的资源动态变动，可用Container以及不同的Task可以在不同的节点运行)
6. NodeManager 为任务设置好运行环境（包括环境变量、JAR 包、二进制程序 等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。（此时，客户端才真正上传具体Task需要的Jar包等等运行资源，同时NodeManager通过调用资源运行对应的Task任务）；
7. 各个任务通过某个 RPC 协议向 MRAppMaster 汇报自己的状态和进度，以 让 MRApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。 在应用程序运行过程中，用户可随时通过 RPC 向 MRAppMaster 查询应用程序的当 前运行状态。步骤4~7是重复执行的。
8. 应用程序运行完成后，MRAppMaster 向 ResourceManager 注销并关闭自己。

小结：
可将 Yarn 看做一个云操作系统，它负责为应用程序启 动 ApplicationMaster（相当于主线程），然后再由 ApplicationMaster 负责数据切分、任务分配、 启动和监控等工作，而由 ApplicationMaster 启动的各个 Task（相当于子线程）仅负责自己的计 算任务。当所有任务计算完成后，ApplicationMaster 认为应用程序运行完成，然后退出。

5、Yarn 实例运行

• step1：客户端程序提交，获取一个 YarnRunner 向 RM 申请一个 Application。
• step2：RM 将该应用程序的资源路径等信息返回给 YARNRunner。
• step3：RM 将该应用程序的资源路径返回给 YarnRunner。
• step4：客户端程序将运行所需的资源提交到 Yarn 上，提交的内容包括：MRAppMaster 运行程序、MRAppMaster 启动脚本程序、用户程序(真正的 MapReduce 处理程序)等。RM 内部分别管理 ApplicationManage r和 ResourceManager 管理对象，分别负责和 MRAppMaster 交互与 Resource 资源的管理。
• step5：资源提交完毕，并将应用程序作为一个 Task 放置在调度器中。
• step6：RM 为提交的程序选择一个空闲的 NodeManager (简称 NM )分配第一个 Container ，并与对应的 NM 通信，要求 NM 在当前容器中运行 MRAppMaster。（ MRAppMaste r负责这个程序的运行状态及进度监控调度等等）
• step7：MRAppMaster 启动之后先向 RM 注册自己。
• step8：然后通过轮询方式通过 RPC 协议向 RM 为自己内部的任务申请资源和领取资源，通过 HDFS 复制一份 Job 需要的相关信息，并依据信息向 RM 申请运行任务的资源。
• step9：MRAppMaster 向 RM 申请 MapTask 需要的资源，RM分配对应的NM信息给MRAppMaster，MRAppMaster 与对应的 NM 通信，将对应的程序脚本发送给 NM。
• step10：RM 分配对应的NM信息给 MRAppMaster。
• step11：MRAppMaster 与对应的 NM 通信，将对应的程序脚本发送给 NM。（NM 会为任务设置好对应的运行环境，包括环境变量、JAR 包、二进制程序等）。NM 接受此脚本并开始启动对应的任务。开启对应的 MapTask 任务，MapTask 会对数据进行分区排序。
• step12：MRAppMaster 在所有 MapTask 任务结束，MRAppMaster 向RM申请资源并运行 ReduceTask。
• step13：RM 分配对应的资源给 ReduceTask ，Reduce 阶段获取 Map 阶段数据
• step14：执行 ReduceTask 任务
• step15：程序运行结束，MRAppmaster 向 RM 注销并关闭自己。