YARN（一）-- 产生原因及概述

本文内容如下：

• 介绍为什么会产生YARN（同时介绍原MapReduce框架的不足）
• YARN的基本原理

首先说一下YARN是什么吧：

Apache Hadoop YARN (Yet Another Resource Negotiator，另一种资源协调者)。

YARN是一个分布式的资源管理系统，用以提高分布式的集群环境下的资源利用率，这些资源包括内存、IO、网络、磁盘等。其产生的原因是为了解决旧MapReduce框架的不足。

一、旧MapReduce框架的不足

下图是旧MapReduce框架的Hadoop集群架构：

一个 Hadoop 集群可分解为两个抽象实体：MapReduce 计算引擎和分布式文件系统。当一个客户端向一个 Hadoop 集群发出一个请求时，此请求由 JobTracker 管理。JobTracker 与 NameNode 联合将任务分发到离它所处理的数据尽可能近的位置。然后JobTracker 将 Map 和 Reduce 任务安排到一个或多个 TaskTracker 上的可用插槽中。TaskTracker 与 DataNode一起对来自 DataNode 的数据执行 Map 和 Reduce 任务。当 Map 和 Reduce 任务完成时，TaskTracker 会告知 JobTracker，后者确定所有任务何时完成并最终告知客户作业已完成。

缺点：

• 由于只有一个JobTracker和NameNode，单一Namenode，单一JobTracker的设计严重制约了整个Hadoop 1.0可扩展 性和可靠性。首先，Namenode和JobTracker是整个系统中明显的单点故障源（SPOF）。再次单一Namenode的内存容量有限，使得Hadoop集群的节点数量被限制到4000个左右，能支持的文件系统大小被限制在10-50PB, 最多能支持的文件数量大约为1.5亿 左右（注，实际数量取决于 Namenode的内存大小）。

• JobTracker完成了过多的任务，造成了过多的资源消耗：当MapReduce job非常多的时候，会造成很大的内存开销，也就增加了JobTracker fail的风险

• 在TaskTracker端，以MapReduce task的数目为资源的表示过于简单，没有考虑到cpu/内存的占用情况，如果两个大内存消耗的task被调度在一起，很容易发生内存溢出错误。

二、YARN的基本原理

为了解决旧框架的问题，YARN将资源管理和作业监控/调度这两个功能拆分开来，交由不同的守护进程完成。具体来说就是有一个全局的资源管理者（ResourceManager or RM）和负责每一个应用的应用管理者（ApplicationMaster or AM）。

下图是官网上的YARN架构图：

ResourceManager 和每个slave节点的NodeManager (NM)构成一个计算框架。ResourceManager 对在系统中所有应用的资源分配拥有最终的最高级别仲裁权。NodeManager负责管理contrainer、监控资源使用情况（cpu、内存、磁盘、网络等），并向ResourceManager/Scheduler上报。

每个应用的ApplicationMaster(AM)被用来和ResourceManager 进行资源谈判，并且和NodeManager一起执行和监控tasks。

其中ResourceManager 拥有两个主要的组件：调度器（Scheduler） 和资源管理器（ApplicationsManager）

Scheduler主要负责对整个集群（CPU，内存）的资源进行分配和调度，分配资源以Container(可以理解为节点上的一组CPU和内存资源)的形式分发到各个应用程序中（如MapReduce作业），应用程序与资源所在节点的NodeManager协作利用Container完成具体的任务（如Reduce Task）。注意：Scheduler是个纯粹的调度器，意思是他不参与任何监控跟踪应用状态的工作，也不会保证在任务失败后重新启动任务。

Scheduler以可插拔的形式来配置，框架默认提供了三种Scheduler：
①FIFO Scheduler
②Capacity Scheduler
③Fair Scheduler
由于本文只是初步介绍YARN，所以这些细节后面的文章再搞定。

Container
Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。Container和集群节点的关系是：一个节点会运行多个Container，但一个Container不会跨节点。

既然一个Container指的是具体节点上的计算资源，这就意味着Container中必定含有计算资源的位置信息：计算资源位于哪个机架的哪台机器上。所以我们在请求某个Container时，其实是向某台机器发起的请求，请求的是这台机器上的CPU和内存资源。

下面说RM的另一个组成部分：ApplicationsManager。
注意不要把它和ApplicationMaster搞混了。

ApplicationsManager主要负责接收job的提交请求，为应用分配第一个Container来运行ApplicationMaster，还有就是负责监控ApplicationMaster，在遇到失败时重启ApplicationMaster运行的Container。

找到了一个Stack Overflow上介绍ApplicationsManager的回答。可以扩展阅读以下。

三、总结

3.1 YARN相对于旧的MapReduce框架的优势：

这个设计大大减小了 ResourceManager 的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。

• 在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
• 对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。
• 老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsManager，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。
• Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。

3.2 Yarn基本原理总结

客户端向ResourceManager提交应用并请求一个ApplicationMaster实例，一个应用只有一个ApplicationMaster实例。ResourceManager找到可以运行一个Container的NodeManager，并启动ApplicationMaster实例。NodeManager会上报资源的状态给RM。客户端的任务在Container中执行，直到程序结束，ApplicationMaster关闭，并把Container归还给系统。

参考资料
[Apache Hadoop YARN](Apache Hadoop YARN)