YARN基础概念

YARN基础概念

概述

Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
可以把 yarn 理解为相当于一个分布式的操作系统平台，而 mapreduce 等运算程序则相当于运行于操作系统之上的应用程序，Yarn 为这些程序提供运算所需的资源（内存、cpu）。

特性

1. yarn 并不清楚用户提交的程序的运行机制
2. yarn 只提供运算资源的调度（用户程序向 yarn 申请资源，yarn 就负责分配资源）
3. yarn 中的主管角色叫 ResourceManager
4. yarn 中具体提供运算资源的角色叫 NodeManager
5. yarn 与运行的用户程序完全解耦，意味着 yarn 上可以运行各种类型的分布式运算程序，比如 mapreduce、storm，spark，tez ……
6. spark、storm 等运算框架都可以整合在 yarn 上运行，只要他们各自的框架中有符合 yarn 规范的资源请求机制即可
7. yarn 成为一个通用的资源调度平台.企业中以前存在的各种运算集群都可以整合在一个物理集群上，提高资源利用率，方便数据共享

基本架构

YARN 是一个资源管理、任务调度的框架，主要包含三大模块：ResourceManager（RM）、
NodeManager（NM）、ApplicationMaster（AM）。

• ResourceManager 负责所有资源的监控、分配和管理；
• ApplicationMaster 负责每一个具体应用程序的调度和协调；
• NodeManager 负责每一个节点的维护。

对于所有的 applications，RM 拥有绝对的控制权和对资源的分配权。而每个 AM 则会和RM 协商资源，同时和 NodeManager 通信来执行和监控 task。

三大组件

ResourceManager

• ResourceManager 负责整个集群的资源管理和分配，是一个全局的资源管理系统。
• NodeManager 以心跳的方式向 ResourceManager 汇报资源使用情况（目前主要是 CPU 和内存的使用情况）。RM 只接受 NM 的资源回报信息，对于具体的资源处理则交给 NM 自己处理。
• YARN Scheduler 根据 application 的请求为其分配资源，不负责 application job 的监控、追踪、运行状态反馈、启动等工作。

NodeManager

• NodeManager 是每个节点上的资源和任务管理器，它是管理这台机器的代理，负责该节点程序的运行，以及该节点资源的管理和监控。YARN 集群每个节点都运行一个NodeManager。
• NodeManager 定时向 ResourceManager 汇报本节点资源（CPU、内存）的使用情况和 Container 的运行状态。当 ResourceManager 宕机时 NodeManager 自动连接 RM 备用节点。
• NodeManager 接收并处理来自 ApplicationMaster 的 Container 启动、停止等各种请求。

ApplicationMaster

• 用 户 提 交 的 每 个 应 用 程 序 均 包 含 一 个 ApplicationMaster ， 它 可 以 运 行 在ResourceManager 以外的机器上。
• 负责与 RM 调度器协商以获取资源（用 Container 表示）。
• 将得到的任务进一步分配给内部的任务(资源的二次分配)。
• 与 NM 通信以启动/停止任务。
• 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
• 当前 YARN 自带了两个 ApplicationMaster 实现，一个是用于演示 AM 编写方法的实例程序DistributedShell，它可以申请一定数目的 Container 以并行运行一个 Shell 命令或者 Shell 脚本；另一个是运行 MapReduce 应用程序的 AM—MRAppMaster。
  注：RM 只负责监控 AM，并在 AM 运行失败时候启动它。RM 不负责 AM 内部任务的容错，任务的容错由 AM 完成。

运行流程

• client 向 RM 提交应用程序，其中包括启动该应用的 ApplicationMaster 的必须信息，例如 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序等。
• ResourceManager 启动一个 container 用于运行 ApplicationMaster。
• 启动中的 ApplicationMaster 向 ResourceManager 注册自己，启动成功后与 RM 保持心跳。
• ApplicationMaster 向 ResourceManager 发送请求，申请相应数目的 container。
• ResourceManager 返回 ApplicationMaster 的申请的 containers 信息。申请成功的 container，由 ApplicationMaster 进行初始化。container 的启动信息初始化后，AM与对应的 NodeManager 通信，要求 NM 启动 container。AM 与 NM 保持心跳，从而对 NM上运行的任务进行监控和管理。
• container 运行期间，ApplicationMaster 对 container 进行监控。container 通过 RPC协议向对应的 AM 汇报自己的进度和状态等信息。
• 应用运行期间，client 直接与 AM 通信获取应用的状态、进度更新等信息。
• 应用运行结束后，ApplicationMaster 向 ResourceManager 注销自己，并允许属于它的 container 被收回。

调度器 Scheduler

理想情况下，我们应用对 Yarn 资源的请求应该立刻得到满足，但现实情况资源往往是有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到相应的资源。在 Yarn 中，负责给应用分配资源的就是 Scheduler。其实调度本身就是一个难题，很难找到一个完美的策略可以解决所有的应用场景。为此，Yarn 提供了多种调度器和可配置的策略供我们选择。
在 Yarn 中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，Fair Scheduler。

FIFO Scheduler

FIFO Scheduler 把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。

FIFO Scheduler 是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用 Capacity Scheduler 或 Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。

Capacity Scheduler

Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。

Fair Scheduler

在 Fair 调度器中，我们不需要预先占用一定的系统资源，Fair 调度器会为所有运行的 job 动态的调整系统资源。如下图所示，当第一个大 job 提交时，只有这一个 job 在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair 调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
需要注意的是，在下图 Fair 调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的 Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终效果就是 Fair 调度器即得到了高的资源利用率又能保证小任务及时完成。

调度器的抢占和延迟调度

所谓抢占，就是允许调度器终止那些占用资源超过了其公平共享份额的队列的容器，这些容器资源释放后可以分配给资源数量低于应得份额的队列。注意，抢占会降低整个集群的效率，因为被终止的containers需要重新执行。
通过将 yarn.scheduler.fair.preemption 设置为true，可以全面启用抢占功能。有两个相关的抢占超时设置：一个用于最小共享（minimum share preemptiontimeout），另一个用于公平共享（fair share preemption timeout），两者设定时间均为秒级。默认情况下，两个超时参数均不设置。所以为了允许抢占容器，需要至少设置其中一个超时参数。

所有的YARN调度器都试图以本地请求为重。在一个繁忙的集群上，如果一个应用请求某个节点，那么极有可能此时有其他容器正在该节点上运行。显而易见的处理是，立刻放宽本地性需求，在同一机架中分配一个容器。然而，通过实践发现，此时如果等待一小段时间（不超过几秒），能够戏剧性的增加在所请求的节点上分配到一个容器的机会，从而可以提高集群的效率。这个特性称之为延迟调度（delay scheduling）。容量调度器和公平调度器都支持延迟调度。

YARN应用的生命周期

YARN应用的生命期差异性很大：有几秒的短期应用，也有连续运行几天甚至几个月的长期应用。与其关注应用运行多长时间，不如按照应用到用户运行的作业之间的映射关系对应用进行分类更有意义。最简单的模型是一个用户作业对应一个应用，这也是MapReduce采取的方式。
第二种模型是，作业的每个工作流或每个用户对话（可能并无关联性）对应一个应用。这种方法要比第一种情况效率更高，因为容器可以在作业之间重用，并且有可能缓存作业之间的中间数据。Spark采取的是这种模型。
第三种模型是，多个用户共享一个长期运行的应用。这种应用通常是作为一种协调者的角色在运行。例如，Apache Slider（网址为htp://sliderincubatorapache.org/）有一个长期运行的application master，主要用于启动集群上的其他应用。
Impala 也使用这种模型提供了一个代理应用，Impala守护进程通过该代理请求集群资源。由于避免了启动新application master带来的开销，一个总是开启（always on）的application master意味着用户将获得非常低延迟的查询响应。

附：apache slider、apache twil、apache helix 类似，在不对程序进行修改的情况下，在YARN上快速部署应用程序。