Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
YARN是在MRv1基础上演化而来的，它克服了MRv1中的各种局限性。
扩展性差：在 MRv1 中，JobTracker 同时兼备了资源管理和作业控制两个功能，这成为系统的一个最大瓶颈，严重制约了 Hadoop 集群扩展性。
可靠性差：MRv1采用了master/slave结构，其中master存在单点故障问题，一旦它出现故障将导致整个集群不可用。
资源利用率低：MRv1采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，其他任务也无法使用这些空闲资源。此外，Hadoop将槽位分为Map Slot和Reduce Slot两种，且不允许它们之间共享， 常常会导致一种槽位资源紧张而另外一种闲置（比如一个作业刚刚提交时，只会运行Map Task，此时Reduce Slot闲置）。
无法支持多种计算框架：随着互联网高速发展，MapReduce这种基于磁盘的离线计算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、流式计算框架和迭代式计算框架等，而MRv1不能支持多种计算框架并存。
yarn的工作流程：
1.用户向YARN提交应用程序，其中包括ApplicationMaster程序，启动AM的命令，用户程序。
2.RM为该应用程序分配第一个Container,并与对应的NM通信，要求它在这个Container中启动应用程序对应的AM。
3.AM启动后向RM注册，用户可以直接通过RM查看应用程序的运行状态。重复4~7。
4.AM采用轮询的方式通过RPC协议向RM申请和领取资源。
5.一旦AM申请到资源后，与对应的NM通信，要求它启动任务。
6.NM为任务设置好运行环境（包括环境变量、JAR包、二级制程序等）后，将任务启动命令写入一个脚本中，通过该脚本启动任务。
7.各个任务通过RPC协议向AM汇报自己的状态和进度，以让AM随时掌握任务的运行状态，从而可以在任务失败时重启任务。
8.任务运行完成后，AM向RM注销并关闭自己。
资源调度器是YARN中最核心的组件之一，且是插拔式的，它定义了一整套接口规范以便用户可按照需要实现自己的调度器。YARN自带了FIFO、Capacity Scheduler和Fair Scheduler三种常用资源调度器，当然，用户可按照接口规范编写一个新的资源调度器，并通过简单的配置使它运行起来。
YARN采用了双层资源调度模型：在第一层中，ResourceManager中的资源调度器将资源分配给各个ApplicationMaster；在第二层中，ApplicationMaster再进一步将资源分配给它内部的各个任务。这里资源调度器主要关注的是第一层的调度问题，至于第二层的调度策略，完全由用户应用程序自己决定。
YARN采用的是pull-base通信模型，而不是push-base通信模型。资源调度器将资源分配给一个应用程序后，它不会立刻push给对应的ApplicationMaster，而是暂时放到一个缓冲区中，等待ApplicationMaster通过周期性的心跳主动来取。
在资源调度器中，每个队列可设置一个最小资源量和最大资源量，其中，最小资源量是资源紧缺情况下每个队列需保证的资源量，而最大资源量则是极端情况下队列也不能超过的资源使用量。资源抢占发生的原因则完全是由于“最小资源量”这一概念。通常而言，为了提高资源利用率，资源调度器（包括Capacity Scheduler和Fair Scheduler） 会将负载较轻的队列的资源暂时分配给负载重的队列（即最小资源量并不是硬资源保证，当队列不需要任何资源时，并不会满足它的最小资源量，而是暂时将空闲资源分配给其他需要资源的队列），仅当负载较轻队列突然收到新提交的应用程序时，调度器才进一步将本属于该队列的资源分配给它。但由于此时资源可能正被其他队列使用，因此调度器必须等待其他队列释放资源后，才能将这些资源“物归原主”，这通常需要一段不确定的等待时间。为了防止应用程序等待时间过长， 调度器等待一段时间后若发现资源并未得到释放，则进行资源抢占。
