一、第一代资源管理器为什么会被淘汰掉
我们知道，hadoop 主要是由三部分组成，HDFS （hadoop 分布式文件系统），MapReduce（分布式计算框架），还有一个就是分布式集群资源调度框架 YARN。
但是 YARN 并不是随 HADOOP 的推出一开始就有的。
YARN 是在 Mapreduce 基础上演化而来的，它克服了 MapReduce 架构中的各种局限性，主要可概括为以下几个方面：
-
可靠性差
MRv1采用了master/slave结构，其中，master存在单点故障问题，一旦它出现故障将导致整个集群不可用。
-
扩展性差
在MRv1中，JobTracker（master）同时兼备了资源管理和作业控制两个功能，这成为系统的一个最大瓶颈，严重制约了Hadoop集群扩展性。
-
资源利用率低
MRv1采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些的空闲资源。
此外，Hadoop将槽位分为Map Slot和Reduce Slot两种，且不允许它们之间共享，常常会导致一种槽位资源紧张而另外一种闲置（比如一个作业刚刚提交时，只会运行Map Task，此时Reduce Slot闲置）。
-
无法支持多种计算框架
随着互联网高速发展，MapReduce这种基于磁盘的离线计算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、流式计算框架和迭代式计算框架等，而MRv1不能支持多种计算框架并存。
在 Hadoop 早期的时候，大数据技术就只有 Hadoop 一家，这个缺点并不明显。
但随着大数据技术的发展，各种新的计算框架不断出现，我们不可能为每一种计算框架部署一个服务器集群，而且就算能部署新集群，数据还是在原来集群的 HDFS 上。
所以我们需要把 MapReduce 的资源管理和计算框架分开，这也是 Hadoop 2 最主要的变化，就是将 Yarn 从 MapReduce 中分离出来，成为一个独立的资源调度框架。
二、Yarn 的设计思想
基本设计思想是将 JobTracker 的两个主要功能，即资源管理和作业控制（包括作业监控、容错等），分拆成两个独立的进程。
资源管理进程和具体的应用程序无关，它负责整个集群的资源（内存，CPU，磁盘等）管理，而作业控制进程则是直接与应用程序相关的模块，且每个作业控制进程只负责管理一个作业。
这样，通过将原有JobTracker中与应用程序相关和无关的模块分开，不仅减轻了JobTracker的负载，也使得Hadoop支持更多的计算框架。
从资源管理的角度看，下一代MapReduce框架衍生出了一个资源统一管理平台，它使得Hadoop不再局限于仅支持MapReduce一种计算模型，而是可无限融入多种计算框架，并且对这些框架进行统一管理和调度。
三、Yarn 的架构
从图上看，Yarn 包括两个部分：一个是资源管理器（ResourceManager），一个是节点管理器（NodeManager）。
ResourceManager 进程负责整个集群的资源调度管理，通常部署在独立的服务器上；
NodeManager 进程负责具体服务器上的资源和任务管理，在集群的每一台计算服务器上都会启动。基本上跟 HDFS 的 DataNode 进程一起出现。
资源管理器
调度器
调度器主要功能是根据资源容量，队列等方面的限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个应用程序。
YARN中的调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。
调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（ResourceContainer，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
在YARN中，资源调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如 Fair Scheduler 和 Capacity Scheduler 。
应用程序管理器
应用程序管理器负责应用程序的提交、监控应用程序运行状态等。
应用程序启动后需要在集群中运行一个 ApplicationMaster，ApplicationMaster 也需要运行在容器里面。
每个应用程序启动后都会先启动自己的 ApplicationMaster，由 ApplicationMaster 根据应用程序的资源需求进一步向 ResourceManager 进程申请容器资源，得到容器以后就会分发自己的应用程序代码到容器上启动，进而开始分布式计算。
四、以一个 MapReduce 为例介绍 Yarn 的工作流程
当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：第一个阶段是启动ApplicationMaster；第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。
YARN的工作流程分为以下几个步骤：
步骤1 用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
步骤2 ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。
步骤3 ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManage查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。
步骤4 ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
步骤5 一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。
步骤6 NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
步骤7 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。
步骤8 应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。
五、总结
我认为理解 Yarn 的工作原理和架构，对于正确使用大数据技术，排查任务运行错误原因，是非常重要的。
在云计算的时代，一切资源都是动态管理的，理解这种动态管理的原理对于理解云计算也非常重要。
Yarn 作为一个大数据平台的资源管理框架，简化了应用场景，对于帮助我们理解云计算的资源管理很有帮助。
扫一扫，我们的故事就开始了。
如果这篇文章对你有所启发，点赞、转发都是一种支持！
另外公众号改变了推送规则，大家看文章不要忘记点击最下方的在看，点赞按钮，这样微信自动识别为常看公众号，否则很可能推送的文章可能淹没在别的文章找不到，谢谢大家
让我知道你在看
本文分享自微信公众号 - 大数据实战演练（gh_f942bfc92d26）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。