深入MapReduce——从MRv1到Yarn

引入

我们前面篇章有提到，和MapReduce的论文不太一样。在Hadoop1.0实现里，每一个MapReduce的任务并没有一个独立的master进程，而是直接让调度系统承担了所有的worker 的master 的角色，这就是Hadoop1.0里的 JobTracker。在Hadoop1.0里，MapReduce论文里面的worker就是TaskTracker，用来执行map 和 reduce的任务。而分配任务，以及和TaskTracker沟通任务的执行情况，都由单一的JobTracker 来负责。

这样实现的好处是比较简单，相对的，导致了JobTracker的负载过重，成为了整个Hadoop 系统“瓶颈”。在Hadoop 2.0，Hadoop社区把JobTracker的角色，拆分成了进行任务调度的Resource Mananger，以及监控单个MapReduce任务执行的Application Master，回到了和MapReduce论文相同的架构。

Hadoop 能有今天这个地位，Yarn可以说是功不可没。因为有了 Yarn ，更多计算框架可以接入到 HDFS 中，而不单单是 MapReduce，MapReduce 早已经被 Spark 等计算框架赶超，而 HDFS 却依然屹立不倒。究其原因，正式因为 Yarn 的包容，使得其他计算框架能专注于计算性能的提升。HDFS 可能不是最优秀的大数据存储系统，但却是应用最广泛的大数据存储系统，Yarn 功不可没。

今天我们来看看关于Yarn的涉及与实现。

Yarn

Yarn是“Yet Another Resource Negotiator”的缩写，字面意思就是“另一种资源调度器”。

事实上，在Hadoop社区决定将资源管理从Hadoop 1中分离出来，独立开发Yarn的时候，业界已经有一些大数据资源管理产品了，比如Mesos等，所以Yarn的开发者索性管自己的产品叫“另一种资源调度器”。这种命名方法并不鲜见，曾经名噪一时的Java项目编译工具Ant就是“Another Neat Tool”的缩写，意思是“另一种整理工具”。

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

架构设计

YARN总体上仍然是master/slave结构。在整个资源管理框架中，ResourceManager为master，NodeManager为slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。

当用户提交一个应用程序时，需要提供一个用于跟踪和管理这个程序的ApplicationMaster。它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定资源的任务。由于不同的ApplicationMaster分布在不同的节点上，因此它们之间不会相互影响。

核心组件

ResourceManager

整个系统有且只有一个 ResourceManager ，它是基于应用程序对集群资源的需求进行调度的 Yarn 集群主控节点，负责协调和管理整个集群的资源，处理客户端请求、启动/监控ApplicationMaster、监控NodeManager、资源分配与调度。

它包含了两个主要的组件：调用器(Scheduler)以及应用管理器(ApplicationsManager，ASM)。

调度器(Scheduler)

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

从本质上来说，定时调度器就是一个资源分配算法（或者说是一种策略）。当 Client 提交一个任务的时候，它会根据所需要的资源以及当前集群的资源状况进行分配。

注意：

它只负责向应用程序分配资源，并不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务。

调度器被设计成一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler等。

应用管理器(ApplicationsManager)

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

具