Yarn设计思想

一. Yarn 产生背景

1.YARN 是在 MRv1 基础上演化而来的，它克服了 MRv1 中的各种局限性。MRv1 主要有以下缺点：

• 扩展性差。在 MRv1 中，JobTracker同时兼备了资源管理和作业控制两个功能，这成为系统的一个最大瓶颈，严重制约了 Hadoop 集群扩展性。
• 可靠性差。MRv1 采用了 master/slave 结构，其中，master 存在单点故障问题，一旦它出现故障将导致整个集群不可用。
• 资源利用率低。MRv1 采用了基于槽位的资源分配模型。Hadoop 将槽位分为Map Slot 和 Reduce Slot两种，且不允许它们之间共享，常常会导致一种槽位资源紧张而另外一种闲置（比如一个作业刚刚提交时，只会运行 Map Task，此时 Reduce Slot 闲置）。
• 无法支持多种计算框架。MapReduce 这种基于磁盘的离线计算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、流式计算框架和迭代式计算框架等，而 MRv1 不能支持多种计算框架并存。

2. YARN 实际上是一个弹性计算平台，可对多种框架进行统一管理。具有以下优势：

• 资源利用率高。共享集群模式则通过多种框架共享资源，使得集群中的资源得到更加充分的利用。 
• 运维成本低。
• 数据共享。跨集群间的数据移动不仅需花费更长的时间，且硬件成本也会大大增加，而共享集群模式可让多种框架共享数据和硬件资源，将大大减小数据移动带来的成本。

二. Yarn设计思想

在 Hadoop 1.0 中，JobTracker 由资源管理（由 TaskScheduler 模块实现）和作业控制（由JobTracker 中多个模块共同实现）两部分组成，当前 Hadoop MapReduce之所以在可扩展性、资源利用率和多框架支持等方面存在不足，正是由于 Hadoop 对JobTracker 赋予的功能过多而造成负载过重。此外，从设计角度上看，Hadoop 未能够将资源管理相关的功能与应用程序相关的功能分开，造成 Hadoop 难以支持多种计算框架。

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

MRv1 主要由编程模型（由新旧 API 组成）、数据处理引擎（由 MapTask 和ReduceTask 组成）和运行时环境（由一个 JobTracker 和若干个 TaskTracker 组成）三部分组成。

•    编程模型和数据处理引擎。MRv2 重用了 MRv1 中的编程模型和数据处理引擎。
  
•    运行时环境。MRv1 的运行时环境主要由两类服务组成，分别是 JobTracker 和TaskTracker。其中，JobTracker 负责资源和任务的管理与调度，TaskTracker 负责单个节点的资源管理和任务执行。而 MRv2 则通过将资源管理和应用程序管理两部分剥离开，分别由 YARN 和 ApplicationMaster 负责，其中，YARN 专管资源管理和调度，而 ApplicationMaster 则负责与具体应用程序相关的任务切分、任务调度和容错等。
  

三. YARN架构

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

1. 整体架构

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

2. YARN 组件

2.1 ResourceManager

YARN ResourceManager 是一个全局的资源管理器，负责整个系统的资源管理和分配。

它主要由两个组件
构成：调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）。

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

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

2.2 ApplicationMaster

负责与 ResourceManger 协商资源，并和 NodeManager 协同工作来执行和监控 Container 以及它们的资源消耗。它有责任与 ResourceManager 协商并获取合适的资源Container，跟踪它们的状态，以及监控其进展。

2.3 NodeManager

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

2.4 资源模型

YARN 提供了非常通用的应用资源模型。一个应用（通过 ApplicationMaster）可以请求非常具体的资源，如下所示：
■  资源名称（包括主机名称，机架名称，以及可能的复杂的网络拓扑）
■  内存量
■  CPU（核数 / 类型）
■  其他资源，如 disk/network I/O、GPU 等资源

2.5 ResourceRequest 和 Container

一个应用程序可以通过 ApplicationMaster 请求特定的资源需求来满足它的资源需要。Scheduler 会分配一个 Container 来响应资源需求，用于满足由 ApplicationMaster 在
ResourceRequest 中提出的需求。

ResourceRequest 具有以下形式：
< 资源名称，优先级，资源需求，Contaienr 数 >
这些组成描述如下：
■  资源名称是资源期望所在的主机名，机架名，用 * 表示没有特殊要求。未来可能支持更加复杂的拓扑，比如一个主机上的多个虚拟机，更复杂的网络拓扑等。
■  优先级是应用程序内部请求的优先级（而不是多个应用程序之间）。优先级会调整应用程序内部各个 ResourceRequest 的次序。
■  资源需求是需要的资源量，如内存量，CPU 时间（目前 YARN 仅支持内存和 CPU 两种资源维度）。
■  Container 数表示需要这样的 Container 的数量，它限制了用该 ResourceRequest 指定的 Container 总数。

Container 是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量，是 ResourceManager 为 ResourceRequest 成功分配资源的结果。Container 为应用程序授予在特定主机上使用资源（如内存，CPU）的权利。ApplicationMaster 必须取走 Container，并且交给 NodeManager，NM 会利用相应的资源来启动 Container 的任务进程。