Hadoop YARN的发展史与详细解析

带有 MapReduce 的 Apache Hadoop 是分布式数据处理的骨干力量。借助其独特的横向扩展物理集群架构和由 Google 最初开发的精细处理框架，Hadoop 在大数据处理的全新领域迎来了爆炸式增长。Hadoop 还开发了一个丰富多样的应用程序生态系统，包括 Apache Pig（一种强大的脚本语言）和 Apache Hive（一个具有类似 SQL 界面的数据仓库解决方案）。

不幸的是，这个生态系统构建于一种编程模式之上，无法解决大数据中的所有问题。MapReduce 提供了一种特定的编程模型，尽管已通过 Pig 和 Hive 等工具得到了简化，但它不是大数据的灵丹妙药。我们首先介绍一下 MapReduce 2.0 (MRv2) — 或 Yet Another Resource Negotiator (YARN) — 并快速回顾一下 YARN 之前的 Hadoop 架构。

Hadoop 和 MRv1 简单介绍

Hadoop 集群可从单一节点（其中所有 Hadoop 实体都在同一个节点上运行）扩展到数千个节点（其中的功能分散在各个节点之间，以增加并行处理活动）。图 1 演示了一个 Hadoop 集群的高级组件。

一个 Hadoop 集群可分解为两个抽象实体：MapReduce 引擎和分布式文件系统。MapReduce 引擎能够在整个集群上执行 Map 和 Reduce 任务并报告结果，其中分布式文件系统提供了一种存储模式，可跨节点复制数据以进行处理。Hadoop 分布式文件系统 (HDFS) 通过定义来支持大型文件（其中每个文件通常为 64 MB 的倍数）。

当一个客户端向一个 Hadoop 集群发出一个请求时，此请求由 JobTracker 管理。JobTracker 与 NameNode 联合将工作分发到离它所处理的数据尽可能近的位置。NameNode 是文件系统的主系统，提供元数据服务来执行数据分发和复制。JobTracker 将 Map 和 Reduce 任务安排到一个或多个 TaskTracker 上的可用插槽中。TaskTracker 与 DataNode（分布式文件系统）一起对来自 DataNode 的数据执行 Map 和 Reduce 任务。当 Map 和 Reduce 任务完成时，TaskTracker 会告知 JobTracker，后者确定所有任务何时完成并最终告知客户作业已完成。

从 图 1 中可以看到，MRv1 实现了一个相对简单的集群管理器来执行 MapReduce 处理。MRv1 提供了一种分层的集群管理模式，其中大数据作业以单个 Map 和 Reduce 任务的形式渗入一个集群，并最后聚合成作业来报告给用户。但这种简单性有一些隐秘，不过也不是很隐秘的问题。 

MRv1 的缺陷

• JobTracker是集群事务的集中处理点，存在单点故障
• JobTracker需要完成的任务太多，既要维护job的状态又要维护job的task的状态，造成过多的资源消耗
• 在taskTracker端，用map/reduce task作为资源的表示过于简单，没有考虑到CPU、内存等资源情况，当把两个需要消耗大内存的task调度到一起，很容易出现OOM
• 把资源强制划分为map/reduce slot,当只有map task时，reduce slot不能用；当只有reduce task时，map slot不能用，容易造成资源利用不足。

YARN (MRv2) 简介

为了实现一个 Hadoop 集群的集群共享、可伸缩性和可靠性。设计人员采用了一种分层的集群框架方法。具体来讲，特定于 MapReduce 的功能已替换为一组新的守护程序，将该框架向新的处理模型开放。 

回想一下，由于限制了扩展以及网络开销所导致的某些故障模式，MRv1 JobTracker 和 TaskTracker 方法曾是一个重要的缺陷。这些守护程序也是 MapReduce 处理模型所独有的。为了消除这一限制，JobTracker 和 TaskTracker 已从 YARN 中删除，取而代之的是一组对应用程序不可知的新守护程序。 

Yarn/MRv2最基本的想法是将原JobTracker主要的资源管理和job调度/监视功能分开作为两个单独的守护进程。有一个全局的ResourceManager(RM)和每个Application有一个ApplicationMaster(AM)，Application相当于map-reduce job或者DAG jobs。ResourceManager和NodeManager(NM)组成了基本的数据计算框架。ResourceManager协调集群的资源利用，任何client或者运行着的applicatitonMaster想要运行job或者task都得向RM申请一定的资源。ApplicatonMaster是一个框架特殊的库，对于MapReduce框架而言有它自己的AM实现，用户也可以实现自己的AM，在运行的时候，AM会与NM一起来启动和监视tasks。 

ResourceManager

ResourceManager作为资源的协调者有两个主要的组件：Scheduler和ApplicationsManager(AsM)。

Scheduler负责分配最少但满足application运行所需的资源量给Application。Scheduler只是基于资源的使用情况进行调度，并不负责监视/跟踪application的状态，当然也不会处理失败的task。RM使用resource container概念来管理集群的资源，resource container是资源的抽象，每个container包括一定的内存、IO、网络等资源，不过目前的实现只包括内存一种资源。

ApplicationsManager负责处理client提交的job以及协商第一个container以供applicationMaster运行，并且在applicationMaster失败的时候会重新启动applicationMaster。下面阐述RM具体完成的一些功能。

1. 资源调度：Scheduler从所有运行着的application收到资源请求后构建一个全局的资源分配计划，然后根据application特殊的限制以及全局的一些限制条件分配资源。
2. 资源监视：Scheduler会周期性的接收来自NM的资源使用率的监控信息，另外applicationMaster可以从Scheduler得到属于它的已完成的container的状态信息。
3. Application提交：
   • client向AsM获得一个applicationIDclient将application定义以及需要的jar包
   • client将application定义以及需要的jar包文件等上传到hdfs的指定目录，由yarn-site.xml的yarn.app.mapreduce.am.staging-dir指定
   • client构造资源请求的对象以及application的提交上下文发送给AsM
   • AsM接收application的提交上下文
   • AsM根据application的信息向Scheduler协商一个Container供applicationMaster运行，然后启动applicationMaster
   • 向该container所属的NM发送launchContainer信息启动该container,也即启动applicationMaster、AsM向client提供运行着的AM的状态信息。
4. AM的生命周期：AsM负责系统中所有AM的生命周期的管理。AsM负责AM的启动，当AM启动后，AM会周期性的向AsM发送heartbeat，默认是1s，AsM据此了解AM的存活情况，并且在AM失败时负责重启AM，若是一定时间过后(默认10分钟)没有收到AM的heartbeat，AsM就认为该AM失败了。

关于ResourceManager的可用性目前还没有很好的实现，不过Cloudera公司的CDH4.4以后的版本实现了一个简单的高可用性，使用了Hadoop-common项目中HA部分的代码，采用了类似hdfs namenode高可用性的设计，给RM引入了active和standby状态，不过没有与journalnode相对应的角色，只是由zookeeper来负责维护RM的状态，这样的设计只是一个最简单的方案，避免了手动重启RM，离真正的生产可用还有一段距离。

NodeManager

NM主要负责启动RM分配给AM的container以及代表AM的container，并且会监视container的运行情况。在启动container的时候，NM会设置一些必要的环境变量以及将container运行所需的jar包、文件等从hdfs下载到本地，也就是所谓的资源本地化；当所有准备工作做好后，才会启动代表该container的脚本将程序启动起来。启动起来后，NM会周期性的监视该container运行占用的资源情况，若是超过了该container所声明的资源量，则会kill掉该container所代表的进程。

另外，NM还提供了一个简单的服务以管理它所在机器的本地目录。Applications可以继续访问本地目录即使那台机器上已经没有了属于它的container在运行。例如，Map-Reduce应用程序使用这个服务存储map output并且shuffle它们给相应的reduce task。

在NM上还可以扩展自己的服务，yarn提供了一个yarn.nodemanager.aux-services的配置项，通过该配置，用户可以自定义一些服务，例如Map-Reduce的shuffle功能就是采用这种方式实现的。

NM在本地为每个运行着的application生成如下的目录结构：

Container目录下的目录结构如下：

在启动一个container的时候，NM就执行该container的default_container_executor.sh，该脚本内部会执行launch_container.sh。launch_container.sh会先设置一些环境变量，最后启动执行程序的命令。对于MapReduce而言，启动AM就执行org.apache.hadoop.mapreduce.v2.app.MRAppMaster；启动map/reduce task就执行org.apache.hadoop.mapred.YarnChild。 

ApplicationMaster

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

MRv2运行流程：

1. MR JobClient向resourceManager(AsM)提交一个job
2. AsM向Scheduler请求一个供MR AM运行的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一起对每一个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退出。

在Yarn上写应用程序

在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所在的机器上。

参考资料：   将 Hadoop YARN 发扬广大   和    Yarn详解