YARN中自己总结的几个关键点

以前在Hadoop 1.0中JobTracker主要完成两项功能：资源的管理和作业控制。在集群规模过大的场景下，JobTracker
存在以下不足：
1）JobTracker 单点故障。
2）JobTracker 承受的访问压力大，影响系统的扩展性。
3）不支持MapReduce之外的计算框架，比如Storm、Spa rk、Flink

因此在YARN的设计中，资源的管理和作业控制是分离开的。取代JobTracker的是ResourceManager、ApplicationMaster两个部分。

● Resource Manager是一个全局的资源管理器 ，它做的事情是调度、启动每一个Job所属的ApplicationMaster、另外监控ApplicationMaster的存在情况。注：RM只负责监控AM，在AM运行失败时候启动它，RM并不负责AM内部任务的容错，这由AM来完成。（是通过RM中的applicationManager来完成的）
● ApplicationMaster是每一个Job（不是每一种）都有的一个部分，ApplicationMaster可以运行在ResourceManager以外的机器上，每个应用程序对应一个ApplicationMaster。。
● NodeManager是ResourceManager的在每个节点的代理，负责 Container 状态的维护，并向RM保持心跳。
● 另外，YARN使用Container对资源进行抽象，它封装了某个节点上一定量的资源（现在YARN仅支持CPU和内存两种资源）。当AM向RM申请资源时，RM为AM返回的资源使用Container表示。YARN会为每个任务分配一个或多个Container，且该任务只能使用该Container中描述的资源。（注：AM也是运行在一个Container中），）目前可以支持多种计算框架运行在YARN上面，比如MapReduce、Storm、Spark、Flink。

说明一下container
Container 是 YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。

要使用一个 YARN 集群，首先需要来自包含一个应用程序的客户的请求。

YARN设计的优点
● 将资源管理和作业控制分离，减小JobTracker压力
○ YARN的设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。
○ 老的框架中，JobTracker一个很大的负担就是监控job下的tasks的运行状况，现在，这个部分就扔给ApplicationMaster做了而ResourceManager中有一个模块叫做ApplicationsManager(ASM)，它负责监测ApplicationMaster的运行状况。
● 能够支持不同的计算框架

工作原理

[img]http://dl2.iteye.com/upload/attachment/0121/8879/2617652e-0ca8-3883-8940-b1bef90f19d9.png[/img]

mapreduce on yarn

[img]http://dl2.iteye.com/upload/attachment/0121/8881/a82767a7-a953-38ba-9aeb-86ccee1ee593.png[/img]

ARN的不足与展望
YARN是一个双层调度器（Two-level scheduler），解决了中央调度器（Monolithic scheduler）的不足（中央调度器典型的代表就是JobTracker)，双层调度架构看上去为调度增加了灵活性和并发性，但实际上它保守的资源可见性和上锁算法（使用悲观并发）也限制了灵活性和并发性。第一，保守的资源可见性导致各框架无法感知整个集群的资源使用情况，有空闲资源无法通知排队的进程，容易造成资源的浪费；第二，上锁算法降低了并发性，调度器会将资源分配给一个架构，只有该架构返回资源后，调度器才回将该部分资源分配给其他架构，在第一个分配过程中，资源相当于被锁住，从而降低了并发性。总结来说，YARN同其他双层架构的调度器（例如：Mesos）都有的不足为：
● 各个应用无法感知集群整体资源的使用情况，只能等待上层调度推送信息。
● 资源分配采用轮询、ResourceOffer机制（mesos)，在分配过程中使用悲观锁，并发粒度小。
● 缺乏一种有效的竞争或优先抢占的机制。
为了改善双层调度系统的的不足，尤其是各个应用无法感知集群整体资源的使用情况和悲观加锁控制导致的并发性不高这两个不足，共享状态调度器（Shared State Scheduler）被越来越多的人所重视，其中最具代表性的就是Google的Omega。共享状态调度器在双层调度器的基础上做了改进：
● 简化了双层调度器中的全局资源管理器，改为由一个Cell State来记录集群内的资源使用情况，这些使用情况都是共享的数据，以此来达到与全局资源管理器相同的效果。
● 所有任务访问共享数据时，采用乐观并发控制方法。
共享调度器也存在不足。例如，当某一资源被不同任务同时访问时容易产生冲突，访问的任务越多时，冲突次数就会越多，冲突次数越高调度器的性能下降越快，这将影响调度器的工作效率和工作性能。