众所周知，在升级到 Yarn这一阶段之前，我们还是用的是MapReduce1，构成它的守护进程包括两个：JobTracker 和 TaskTracker，JobTracker将任务分发给TaksTracker，后者负责执行任务，并且将任务执行情况和最终结果定期汇报给前者。这样，JobTracker的工作内容就包括了任务的分发与调度+任务进度监控。可以想到，在MR1的阶段JobTracker作为一个单点，同时肩负着很多任务，是一个设计上的缺点，也给MR1带来了一定的局限性，当节点数达到4000，任务数达到40000时候，扩展性的性能瓶颈就会出现。
于是，在Hadoop2阶段，Apache Yarn被引入到系统内，用来扩展MapReduce的性能，与此同时，由于Yarn的通用性，提供使用集群资源的Api，它能够在底层给其他分布式应用以足够多的支持，例如：Spark、Tez。当然，基于这些应用之上，还可以构建一些更方便与我们日常使用的应用程序，比如Pig、Hive、Crunch都是基于这些分布式应用的大数据问题处理框架。
首先，Yarn的构成主要包括了
Resource Manager 资源管理器：主要负责管理集群上资源的使用情况；
Node Manager 节点管理器：运行在每个几节点上，负责启动和监控容器的使用；
Container 容器：用于执行特点应用程序的进程，每个容器都有内存和CPU的使用限制。
对于Yarn与MR1的结构对应关系如下：
|
MapReduce 1
|
Yarn
|
|
JobTracker
|
资源管理器、Application Master、时间轴服务器 |
|
TaskTracker
|
节点管理器 |
|
Slot
|
容器 |
对于MR1来说，每个任务都需要JobTracker来进行调度、资源分配和任务监控；在Yarn架构下，每一个MR任务都有一个专门的 Application Master 来负责任务的整个生命周期的监控。这样一来，克服了JobTracker的局限性，节点数目和任务数目都分别增加到了10000个和100000个。主要有三个主要的更新点：
可用性：在MR1阶段，由于JobTracker负责的工作多，每个任务的运行都是时时刻刻在变化，因此要实现高可用非常困难；在Yarn阶段，由于将JobTracker进行了职责划分，相当于用了分而治之的方式，这样可以单独对ResourceManger和ApplicationMaster进行高可用的支持。
利用率：MR1的每个TaskTracker都被分配了固定长度的slot，分别被设置为MapSlot和ReduceSlot，这样可能存在Map任务已经完成，并且仅有MapSlot有空闲的情况下，可能导致Reduce任务因为资源问题被挂起。在Yarn中，节点管理器管理一个资源池，而不是固定数目的slot，并且不再划分MapSlot和ReduceSlot；并且Yarn能够做到更加精细化的管理，不再划分一个固定的不可分割的slot，而是按需请求资源。
多租户：可以说是yarn最大的创新点，正是由于yarn实现了多租户，这样就可以在yarn上运行多种分布式框架，甚至可以运行多版本的hadoop。
Yarn有三种调度策略：
FIFO Scheduler：简单易懂，不需要任何配置，但是不适合集群配置，因为大的任务会占据大量资源，小任务无法快速计算出结果，将会被一致阻塞直到大任务执行完毕。
Capacity Scheduler 容量调度：单独划分出一个队列作为小任务的执行队列，这样就可以保证大任务的执行不会影响小任务的执行进度，但是很明显，这样做会降低集群的使用率，使大任务的执行周期变长。
Fair Scheduler 公平调度：给每个用户队列分配公平的资源，当只有一个用户时，他占有100%的资源，当有两个用户同时提交任务的时候，他们各占50%。
Dominant Resource Fairness，DRF 主导资源公平：
默认情况下，不启动DRF，主要资源只计算内存，当开启之后，任务占用较多的资源类型作为主要资源，资源分配以主要资源占用量作为决定因素。