在说Hadoop Yarn的原理之前，我们先来看看Yarn是怎样出现的。在古老的Hadoop1.0中，MapReduce的JobTracker负责了太多的工作，包括资源调度，管理众多的TaskTracker等工作。这自然就会产生一个问题，那就是JobTracker负载太多，有点“忙不过来”。于是Hadoop在1.0到2.0的升级过程中，便将JobTracker的资源调度工作独立了出来，而这一改动，直接让Hadoop成为大数据中最稳固的那一块基石。，而这个独立出来的资源管理框架，就是Hadoop Yarn框架 。
一. Hadoop Yarn是什么
在详细介绍Yarn之前，我们先简单聊聊Yarn，Yarn的全称是Yet Another Resource Negotiator，意思是“另一种资源调度器”，这种命名和“有间客栈”这种可谓是异曲同工之妙。这里多说一句，以前Java有一个项目编译工具，叫做Ant，他的命名也是类似的，叫做“Another Neat Tool”的缩写，翻译过来是”另一种整理工具“。
既然都叫做资源调度器了，那么自然，它的功能也是负责资源管理和调度的，接下来，我们就深入到Yarn框架内部一探究竟吧。
二. Hadoop Yarn架构原理剖析
这张图可以说是Yarn的全景图，我们主要围绕上面这张图展开，介绍图中的每一个细节部分。首先，我们会介绍里面的Container的概念以及相关知识内容，然后会介绍图中一个个组件，最后看看提交一个程序的流程。
2.1 Container
容器（Container）这个东西是Yarn对资源做的一层抽象。就像我们平时开发过程中，经常需要对底层一些东西进行封装，只提供给上层一个调用接口一样，Yarn对资源的管理也是用到了这种思想。
如上所示，Yarn将CPU核数，内存这些计算资源都封装成为一个个的容器（Container）。需要注意两点：
- 容器由NodeManager启动和管理，并被它所监控。
- 容器被ResourceManager进行调度。
其中NodeManager和ResourceManager这两个组件会在下面讲到。
2.2 Yarn的三个主要组件
再看最上面的图，我们能直观发现的两个主要的组件是ResourceManager和NodeManager，但其实还有一个ApplicationMaster在图中没有直观显示（其实就是图中的App Mstr，图里用了简写）。三个组件构成了Yarn的全景，这三个组件的主要工作是什么，Yarn 框架又是如何让他们相互配合的呢，我们分别来看这三个组件。
ResourceManager
我们先来说说上图中最*的那个ResourceManager（RM）。从名字上我们就能知道这个组件是负责资源管理的，在运行过程中，整个系统有且只有一个RM，系统的资源正是由RM来负责调度管理的。RM包含了两个主要的组件：定时调用器(Scheduler)以及应用管理器(ApplicationManager)，我们分别来看看它们的主要工作。
定时调度器(Scheduler)：从本质上来说，定时调度器就是一种策略，或者说一种算法。当Client提交一个任务的时候，它会根据所需要的资源以及当前集群的资源状况进行分配。注意，它只负责向应用程序分配资源，并不做监控以及应用程序的状态跟踪。
应用管理器(ApplicationManager)：同样，听名字就能大概知道它是干嘛的。应用管理器就是负责管理Client用户提交的应用。上面不是说到定时调度器（Scheduler）不对用户提交的程序监控嘛，其实啊，监控应用的工作正是由应用管理器（ApplicationManager）完成的。
OK，明白了资源管理器ResourceManager，那么应用程序如何申请资源，用完如何释放？这就是ApplicationMaster的责任了。
ApplicationMaster
每当Client（用户）提交一个Application（应用程序）时候，就会新建一个ApplicationMaster。由这个ApplicationMaster去与ResourceManager申请容器资源，获得资源后会将要运行的程序发送到容器上启动，然后进行分布式计算。
这里可能有些难以理解，为什么是把运行程序发送到容器上去运行？如果以传统的思路来看，是程序运行着不动，然后数据进进出出不停流转。但当数据量大的时候就没法这么玩了，因为海量数据移动成本太大，时间太长。但是中国有一句老话山不过来，我就过去。大数据分布式计算就是这种思想，既然大数据难以移动，那我就把容易移动的应用程序发布到各个节点进行计算呗，这就是大数据分布式计算的思路。
那么最后，资源有了，应用程序也有了，那么该怎么管理应用程序在每个节点上的计算呢？别急，我们还有一个NodeManager。
NodeManager
相比起上面两个组件的掌控全局，NodeManager就显得比较细微了。NodeManager是ResourceManager在每台机器的上代理，主要工作是负责容器的管理，并监控他们的资源使用情况（cpu，内存，磁盘及网络等），并且它会定期向ResourceManager/Scheduler提供这些资源使用报告，再由ResourceManager决定对节点的资源进行何种操作（分配，回收等）。
三. 提交一个Application到Yarn的流程
这张图简单地标明了提交一个程序所经历的流程，接下来我们来具体说说每一步的过程。
Client向Yarn提交Application，这里我们假设是一个MapReduce作业。
ResourceManager向NodeManager通信，为该Application分配第一个容器。并在这个容器中运行这个应用程序对应的ApplicationMaster。
ApplicationMaster启动以后，对作业（也就是Application）进行拆分，拆分task出来，这些task可以运行在一个或多个容器中。然后向ResourceManager申请要运行程序的容器，并定时向ResourceManager发送心跳。
申请到容器后，ApplicationMaster会去和容器对应的NodeManager通信，而后将作业分发到对应的NodeManager中的容器去运行，这里会将拆分后的MapReduce进行分发，对应容器中运行的可能是Map任务，也可能是Reduce任务。
容器中运行的任务会向ApplicationMaster发送心跳，汇报自身情况。当程序运行完成后，ApplicationMaster再向ResourceManager注销并释放容器资源。
以上就是一个作业的大体运行流程。
小结：这次我们介绍了Hadoop yarn的主要架构原理以及yarn上任务的运行流程。我们说了yarn的几个主要的组件，各自的责任，以及如何与其他组件协作调和。最后我们再来说说为什么会有Yarn这么个框架的出现吧~~
为什么会有Hadoop Yarn框架的出现？
上面说了这么多，最后我们来聊聊为什么会有Yarn吧。
直接的原因呢，就是因为Hadoop1.0中架构的缺陷，在MapReduce中，jobTracker担负起了太多的责任了，接收任务是它，资源调度是它，监控TaskTracker运行情况还是它。这样实现的好处是比较简单，但相对的，就容易出现一些问题，比如常见的单点故障问题。
要解决这些问题，只能将jobTracker进行拆分，将其中部分功能拆解出来。彼时业内已经有了一部分的资源管理框架，比如mesos，于是照着这个思路，就开发出了Yarn。这里多说个冷知识，其实Spark早期是为了推广mesos而产生的，这也是它名字的由来，不过后来反正是Spark火起来了。。。
闲话不多说，其实Hadoop能有今天这个地位，Yarn可以说是功不可没。因为有了Yarn，更多计算框架可以接入到Hdfs中，而不单单是MapReduce，到现在我们都知道，MapReduce早已经被Spark等计算框架赶超，而Hdfs却依然屹立不倒。究其原因，正式因为Yarn的包容，使得其他计算框架能专注于计算性能的提升。Hdfs可能不是最优秀的大数据存储系统，但却是应用最广泛的大数据存储系统，Yarn功不可没。
推荐阅读 ：
从分治算法到 MapReduce
一个故事告诉你什么才是好的程序员
大数据存储的进化史 --从 RAID 到 Hadoop Hdfs