Hadoop 中 YARN和MV2以及ApplicationMaster

ApplicationMaster是什么？

ApplicationMaster 是一个框架特殊的库，对于 Map-Reduce 计算模型而言有它自己的 ApplicationMaster 实现，对于其他的想要运行在 yarn上的计算模型而言，必须得实现针对该计算模型的 ApplicationMaster 用以向 ResourceManager 申请资源运行 task。比如运行在 yarn上的spark 框架也有对应的 ApplicationMaster 实现，归根结底，yarn是一个资源管理的框架，并不是一个计算框架，要想在 yarn 上运行应用程序，还得有特定的计算框架的实现。yarn 是伴随着 MR2 一起出现的。

我们知道，在MRv1中，JobTracker存在诸多问题，包括存在单点故障，扩展受限等，为了解决这些问题，Apache对MRv1进行了改进，提出了YARN。
YARN将JobTracker中的作业控制和资源管理两个功能分开，分别由两个不同的进程处理，进而解决了原有JobTracker存在的问题。经过架构调整之后，YARN已经完全不同于MRv1，它已经变成了一个资源管理平台，或者说应用程序管理框架。运行于YARN之上的计算框架不只限于MapReduce 一种，也可以是其他流行计算框架，比如流式计算、迭代式计算等类型的计算框架。为了将一个计算框架运行于 YARN 之上，用户需要开发一个组件— ApplicationMaster。作为一个开始，YARN 首先支持的计算框架是 MapReduce，YARN 为用户实现好了 MapReduce 的ApplicationMaster，也就是要介绍的 MRAppMaster。

MRv2运行流程是什么？

MRv2运行流程：

1. MR JobClient 向 ResourceManager(AsM) 提交一个 job；
2. AsM（ApplicationsManager） 向 Scheduler 请求一个供 MR AM （ApplicationMaster） 运行的 container，然后启动它；
3. MR AM 启动起来后向 AsM 注册；
4. MR JobClient 向 AsM 获取到 MR AM 相关的信息，然后直接与 MR AM 进行通信；
5. MR AM 计算 splits 并为所有的 map 构造资源请求；
6. MR AM 做一些必要的 MR OutputCommitter 的准备工作；
7. MR AM 向 RM(Scheduler) 发起资源请求，得到一组供 map/reduce task 运行的 container，然后与 NM（NodeManager） 一起对每一个container 执行一些必要的任务，包括资源本地化等；
8. MR AM 监视运行着的 task 直到完成，当 task 失败时，申请新的container 运行失败的 task；
9. 当每个 map/reduce task 完成后，MR AM 运行 MR OutputCommitter 的 cleanup 代码，也就是进行一些收尾工作；
10. 当所有的 map/reduce 完成后，MR AM 运行 OutputCommitter 的必要的 job commit 或者 abort APIs；
11. MR AM 退出。

注：这里的 MR AM（ApplicationMaster），指的就是 ApplicationMaster，因为这里讲的就是 Yarn 上的 MapReduce 计算框架。

Yarn是一个资源管理框架还是计算框架？

RM是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）

在 yarn 上写应用程序并不同于我们熟知的 MapReduce 应用程序，必须牢记 yarn 只是一个资源管理的框架，并不是一个计算框架，计算框架可以运行在yarn上。

我们所能做的就是向 RM 申请 container ，然后配合 NM 一起来启动container。就像 MRv2 一样，jobclient 请求用于 MR AM 运行的container，设置环境变量和启动命令，然后交由 NM 去启动 MR AM，随后 map/reduce task 就由 MR AM 全权负责，当然 task 的启动也是由 MR AM 向 RM 申请container，然后配合 NM 一起来启动的。所以要想在 yarn 上运行非特定计算框架的程序，我们就得实现自己的 client和 ApplicationMaster。另外我们自定义的 AM 需要放在各个 NM 的classpath 下，因为 AM 可能运行在任何 NM 所在的机器上。

相比于JobTracker，MRAppMaster有什么不同？

既然 MRAppMaster 是由 JobTracker 衍化而来的，那么是否将JobTracker 的代码稍加修改，就变成了 MRAppMaster 呢，答案是否定的。事实上，YARN 仅重用了 MRv1 中的少许代码，基本可看做重写了 MRAppMaster。

YARN 采用了新的软件设计思想，包括对象服务化、事件驱动的异步编程模型的。作为 YARN 的一部分，MRAppMaster 的实现也采用了这些设计思想。

MRAppMaster的实现细节

在正式介绍 MRAppMaster 之前，我们先回顾一下 MRv1 的实现。我们都知道，MRv1 主要由两种服务组成，即：JobTracker 和 TaskTracker，而在 YARN 中，TaskTracker 已经由 NodeManager 代替，因此，我们在此重点分析 JobTracker。JobTracker 包含资源管理和作业控制两个功能，在 YARN 中，作业管理由 ResourceManager 实现，因此，只剩下作业控制这一个功能（由 MRAppMaster 实现）。

MRv1 中每个作业由一个 JobInProgress 控制，每个任务由一个TaskInProgress 控制，由于每个任务可能有多个运行实例，因此，TaskInProgress 实际管理了多个运行实例 Task Attempt，对于每个运行实例，可能运行了一个 MapTask 或者 ReduceTask，另外，每个 Map Task 或者 Reduce Task 会通过 RPC 协议将状态汇报给 TaskTracker，再由 TaskTracker 进一步汇报给 JobTracker。

在 MRAppMaster 中，它只负责管理一个作业，包括该作业的资源申请、作业运行过程监控和作业容错等。MRAppMaster 使用服务模型和事件驱动的异步编程模型对 JobInProgress 和 TaskInProgress 进行了重写（分别对应 JobImpl 和 TaskImpl），并让 Map Task 和 Reduce Task（Map Task 和 Reduce Task 重用了 MRv1 中的代码）直接通过RPC 将信息汇报给 MRAppMaster。此外，为了能够运行于 YARN 之上，MRAppMaster 还要与 ResourceManager 和 NodeManager 两个新的服务通信（用到两个新的 RPC 协议），以申请资源和启动任务，这些都使得 MRAppMaster 完全不同于 JobTracker。

---

参考

参考与《Hadoop 技术内幕—深入解析YARN架构设计与实现原理》
作者的博客地址：
http://dongxicheng.org/mapreduce-nextgen/nextgen-mapreduce-introduction/