Yarn的一些整理

一、 Yarn 简介
1、Yarn 是什么
 Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）
 一种新的 Hadoop 资源管理器，一个通用资源管理系统
 为上层提供统一的资源管理与任务调度及监控，提高了集群管理效率、资源使用率、数据共享效率
2、产生背景
在 Hadoop1.x 中 MapReduce 是 Master/Slave 结构，在集群中的表现形式为：1 个 JobTracker 带多个 TaskTracker，我们称之为 MRv1。
Master：是整个集群的唯一全局管理者，功能包括：作业管理、状态监控和任务调度等即MapReduce 中的 JobTracker。
Slave：负责任务的执行和任务状态的汇报，即 MapReduce 中的 TaskTracker。

MRv1 包括三个部分：运行时环境(JobTracker 和 TaskTracker)、编程模型(MapReduce)和数据处理引擎(Map 任务和 Reduce 任务)。
JobTracker 主要功能：
 资源管理，协调平衡集群中的计算节点，合理分配。
 任务调度，一个作业对应多个任务，负责任务调度、状态监控、容错管理等。
TaskTracker 主要功能：
 执行任务，响应 JobTracker 命令，如启动、停止任务等
 汇报心跳：汇报节点健康状况、资源使用情况等。汇报任务执行进度、任务运行状态等。
MRv1 存在的主要问题：
 JobTracker 单点故障，如果它挂掉，整个系统无法运转
 JobTracker 负载过重，限制了集群扩展，随着节点规模的增大，称为集群的瓶颈
 仅支持 MR 计算框架，适合批处理、基于磁盘的计算
 资源与计算没有很好的解耦设计，一个集群只能使用一个计算框架，如 Hadoop&MapReduce 集群、Spark 集群、Tez 集群等。造成管理复杂、资源利用率低的难题
综上所述 MRv1 有以上缺陷：扩展性受限、单点故障、难以支持 MR 之外的计算框架。多计算框架各自为战，数据共享困难，资源利用率低。这些因素催生了 Yarn 的产生。
3、Yarn 特点
 资源管理与计算框架解耦设计，一个集群资源共享给上层各个计算框架，按需分配，大幅度提高资源利用率
 运维成本显著下降，只需运维一个集群，同时运行满足多种业务需求的计算框架
 集群内数据共享一致，数据不再需要集群间拷贝转移，达到共享互用
 避免单点故障、集群资源扩展得到合理解决
4、Yarn 应用
需要统一资源管理和任务调度的平台均可以使用，已成为大数据集群的必备组件之一。
二、Yarn 架构设计
1、架构设计图
Yarn 设计的核心思想是将 JobTracker 的两个主要职责：资源管理和任务调度管理，分别交给两个角色负责。
一个是全局的 ResourceManager，一个是每个应用中唯一的 ApplicationMaster。
ResourceManager 以及每个节点一个的 NodeManager 构成了新的通用系统，实现以分布式方式管理应用。

2、基本组成
YARN 总体上仍然是 Master/Slave 结构，在整个资源管理框架中，ResourceManager 为 Master，NodeManager 为 Slave。YARN 主要由 ResourceManager、NodeManager、ApplicationMaster 和 Container等几个组件构成。
2.1 概略介绍
 Master/Slave 结构，1 个 ResourceManager 和多个 NodeManager
 Yarn 由 Client、ResourceManager、NodeManager、ApplicationMaster 组成
 Client 向 ResourceManager 提交启动任务、杀死任务等命令请求
 ApplicationMaster 由对应的计算框架编写的应用程序完成。每个应用程序对应一个
ApplicationMaster，ApplicationMaster 向 ResourceManager 申请资源用于在 NodeManager上启动相应的 Task
 NodeManager 向 ResourceManager 通过心跳信息汇报 NodeManager 监控状况、任务执行状况、领取任务等
2.2 详细介绍
 Client：面向用户提交的 Driver 代码，作为用户编程的接口，与 ResourceManager 交互。
 ResourceManager：整个集群只有一个是存活(active)的，负责集群资源的统一管理和调度
 负责整个集群的资源分配和调度
 处理来自客户端的请求，启动、杀死应用程序
 启动、监控 ApplicationMaster，一旦一个 AM 挂了之后，RM 将会在另一个 NodeManager上启动该 AM
 监控 NodeManager，接收 NM 的心跳汇报信息，获取 NM 的资源使用情况和 Container 运行状态
 NodeManager：整个集群中有多个，负责单节点资源管理和使用。
 负责单个节点上的资源管理和任务调度
 处理来自 ApplicationMaster 的命令
 接收并处理来自 ResourceManager 的 Container 启动、停止的各种命令
 周期性向 ResourceManager 汇报本节点上的资源使用情况和 Container 的运行状态
 ApplicationMaster：每个应用程序特有，负责应用程序的管理
 数据切分
 为应用程序/作业向 ResourceManager 申请资源(Container)，并分配给内部任务
 与 NodeManager 通信以启动、停止任务
 任务监控和容错(在任务执行失败时重新为该任务申请资源以重启任务)
 处理 ResourceManager 发来的命令，让 NodeManager 重启任务、杀死 Container 等
 Container：对任务运行环境的抽象
 任务运行资源的抽象，封装了某个节点上的多维度资源，如内存、cpu、磁盘、网络等
 任务命令启动、停止的执行单元
 任 务 运 行 环 境 ， 任 务 运 行 在 Container 中 ， 一 个 Container 中 既 可 以 运 行
ApplicationMaster 也可以运行具体的 MapReduce、MPI、Spark 等任务
3、运行流程
3.1 运行流程图：

3.2 运行流程详解：

1. 用户向 YARN 中提交应用程序/作业，其中包括 ApplicationMaster 程序、启动
   ApplicationMaster 的命令、用户程序等。
2. ResourceManager 为作业分配第一个 Container，并与对应的 NodeManager 通信，要求它在这
   个 Container 中启动该作业的 ApplicationMaster。
3. NodeManager 启动一个 Container 运行 ApplicationMaster。
4. ApplicationMaster 首先向 ResourceManager 注册，这样用户可以直接通过 ResourceManager查询该作业的运行状态；然后它将为各个任务申请资源并监控任务的运行状态。
   如果 Container 没有完全申请到位，则会先使用已经分配到位的部分 Container 资源进行后续的第 5、6、7 步骤，其余 Container 部分由 ApplicationMaster 采用轮询的方式通过 RPC 请求向ResourceManager 申请和领取资源，直到全部资源分配到位。
5. 一旦 ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求它启动任务。
6. NodeManager 执行 ApplicationMaster 发送的命令，启动 Container 任务。
7. 各 个 Container 通 过 RPC 向 ApplicationMaster 汇 报 自 己 的 状 态 和 进 度 ， 以 让ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在作业运行过程中，用户可以随时通过 RPC 向 ApplicationMaster 查询作业当前运行状态。
8. 作业完成后，ApplicationMaster 向 ResourceManager 申请注销并关闭自己。

三、Yarn 调度策略**
1、MRv1 的调度方式
集中式调度器，资源调度和应用程序的管理功能集中到单一进程完成，扩展性差。
 集群规模受限，集群达到一定规模(4000 个节点)后，JobTracker 压力过大容易发生单点故障
 新的调度策略难以融入到现有代码中，之前仅支持 MapReduce 作业，现在要支持 Spark 等作业，而将新的作业的调度策略加入到集中式调度中是极难的工作
2、Yarn 双层调度架构
为了克服集中式调度器的不足，双层调度器是一种很容易被想到的解决之道，它可看作是一种分而治之的机制或者是策略下放机制：双层调度器仍保留一个经简化的集中式资源调度器，但具体任务相关的调度策略则下放到各个应用程序调度器完成。
 将传统的集中式调度器一分为二，即资源调度器(ResourceManager)和应用程序调度器(ApplicationMaster)
 ResourceManager 即简化了的集中式资源调度器，具体作业的资源调度和管理由应用程序调度器 ApplicationMaster 负责

3、常用调度策略
理想情况下，我们应用对 Yarn 资源的请求应该立刻得到满足，但现实情况资源往往是有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到相应的资源。在Yarn 中，负责给应用分配资源的就是 Scheduler。其实调度本身就是一个难题，很难找到一个完美的策略可以解决所有的应用场景。为此，Yarn 提供了多种调度器和可配置的策略供我们选择。
3.1 FIFO Scheduler(First In First Out，先进先出)
默认的调度策略，把用户提交的作业顺序排成一个队列，所有用户共享，是一个先进先出的队列。
无法控制用户的资源使用，大的应用可能会占用所有集群资源，导致其他应用被阻塞，造成集群的可用性差，所以不适用于共享集群。一般不在生产环境中使用。

3.2 Capacity Scheduler(容器调度器)
允许多用户共享整个集群，每个用户或组织分配专门的队列，不支持抢占式。队列内部默认使用FIFO，也支持 Fair 调度。

3.3 Fair Scheduler(公平调度器)
目标是为所有用户分配公平的资源。也支持多用户共享集群，也可划分多队列。队列内部不是FIFO，而是采用公平分配的方式。

3.4 总结
调度名称和特点

FIFO Scheduler
默认的队列内部调度器，只有一个队列，所有用户共享 ,简单好理解，无法控制用户的资源使用，造成集群的可用性很差。一般不在生产环境使用。

Capacity Scheduler
多用户、分队列、ACL 控制、不支持抢占式，队列内部依然是 FIFO,也可以采用 Fair 。

Fair Scheduler
多用户、分队列、ACL 控制、支持抢占式，队列内部不是 FIFO，而是公平分配的方式。