YARN—Hadoop系统平台的大管家
声明：本文档所有内容均在本人的学习和理解上整理，仅供参考，欢迎讨论。不具有权威性，甚至不具有精确性，也会在以后的学习中对不合理之处进行修改。
按照Hadoop的常规学习流程，在底层的文件存储结束后，应该介绍它的算法核心模块MapReduce。YARN作为协调者会在之后的各种算法中穿插用到。原本想单独介绍MapReduce算法思想，但发现怎么都绕不开YARN这个话题。将二者放在一块，里面的一些概念又容易混淆，不利于以后对计算层的其他算法的理解。故这一篇文档单独将YARN作为整个Hadoop的协调层来介绍，并且放在算法之前。要理解YARN的“协调者”这个概念，我想来想去给他定了个比较容易理解的身份——大管家。作为一个家族的大管家，他不必像底层佣人亲自动手事必躬亲，但也不能同决策者制定方针谋划未来。他能做的，是根据主人下达的命令，筹集资源、动员人手，下放给佣人实际操作。希望这样比喻比较好理解。
一、YARN出现的背景
YARN作为一种协调机制，是在Hadoop 2.0版本才出现使用的。在1.0版本中，对数据的处理、资源的调度主要依赖于MapReduce算法。来看一下Hadoop 1.版本的应用处理机制：
1、一个需要用到Data A和Data C的应用提交给M/R
2、M/R为应用创建一个Job，Job将应用分片后提交给Job Tracker
3、Job Tracker根据应用所需的数据找到相应的DN节点，在DN节点上分配相应的Task Tracker执行任务
4、Task Tracker在执行任务时实时与Job Tracker进行交互，汇报任务执行情况
5、Job Tracker接受各Task Tracker的计算结果
我们先理解一下Job Tracker和Task Tracker。应用在提交给Job Tracker时已经分好片，在Job Tracker接受到的仍是一个完整的应用。之后由Job Tracker将分片的应用下放到相应的DN节点，由Task Tracker具体执行，这个时候Task Tracker收到的时整个应用的一部分，可以成为任务。那么我们可以将Job Tracker理解为整个应用和整个DN集群的管理器，而Task Tracker则是分片任务的管理器。选择回顾整个处理机制，我们能发现两个突出的问题：
1、Job Tracker的地位很重要，但负载也太大了。除了初始的应用分片不需要它处理，剩下的一切都需要它”追踪“，包括任务的具体执行情况也要它操个心。对整个系统来说，这不是好事。
2、Job Tracker时按照所需数据来进行分配，那么资源（主要指内存）就很容易分配不均。打个比方：一个Job被分成6个子Job，每个子Job需要的资源（内存）是1GB。但所有子Job所需要的数据全部集中在一台DN节点上，该节点内存只有4GB，一次只能接受4给子Job。剩下的2个子Job正能等内存释放后再进入执行。而在等待工程中，其他的DN节点是处于空闲状态的。
这两个问题暴露了Hadoop 1.0版本的资源协调在处理大规模数据时会有些”力不从心“。而随着数据规模的快速扩大，Hadoop亟需一种更优化的资源协调解决方案，YARN就在这一背景下诞生。
二、YARN的重要角色及概念
1、ResourceManager（RM）
RM是整个集群的资源管理器，负责整个集群的资源调度和管理。同时也负责与客户端交互，处理客户端的应用请求等。它主要有２个组建构成：
①Resource Scheduler：纯资源调度器，只负责为程序进程调度所需的资源
②Applications Manager(ASM)：与具体应用程序打交道，处理程序的请求，具体负责程序的分配
2、Node Manager（ＮＭ)：节点管理器，负责管理自己节点上的资源和使用，于RM交互，上报节点的状态，以便RM调用
3、Application Master(AM)：在DN节点上中，是每个子程序的管理者，负责管理由RM分发的任务，包括任务的资源申请和执行情况
4、Container：资源打包容器，AM向RM申请来的资源的集合，并利用这些资源负责具体执行任务。位于DN节点上。
三、YARN运行流程
还是要提一下，YARN作为资源的协调者，本身不提供应用程序和文件数据。应用程序由客户端发起，由Hadoop上层的算法转化成不同的任务，数据文件存储在HDFS上。所以说，YARN只是辅助任务去调用资源来计算这些数据，并不参与到计算中去。
1、客户端向RM发送应用请求
2、RM根据NM的节点信息选择合适的DN节点
3、RM在选中的DN节点上创建并启动AM，将任务分发给AM
4、AM根据自己的任务情况向RM申请相应的资源
5、RM为AM分配相应的资源
6、AM得到资源后启动对应的资源容器（Container）执行任务并进行监控
7、Conrtainer将任务执行完毕报告给AM
8、AM将任务的执行结果上报给RM
9、RM向Client返回应用的执行结果
现在我们再回顾一下Hadoop 1.0版本的局限性：
1、Job Tracker既要调度又要监控，负载过高
再YARN中，区别于1.0版本最主要的思想就是将调度和监控功能分离。RM主要负责资源的调度，具体任务监控则由AM来完成。RM只要在节点上启动AM并将任务发给AM就行，不用管任务具体是怎么执行的，当任务完成后由AM向RM报告一个结果就行了。且AM分布在各节点上，不占用RM本身资源，大大减少了RM的工作量，整个系统的稳定性就有了极大的提高。
2、任务按数据需求分配，资源分配不均，效率低下
AM在向RM申请资源时，不在局限于本节点的资源，而是由RM根据各节点信息选择合适的节点资源调配给AM使用。换句话说，”AM你有什么需求尽管提，只要我有一定给你（哦吼，霸道总裁既视感）“这个”我“指的就是整个集群了。
YARN的加入使得Hadoop 2.0系统有了一种高效、可靠的处理大规模数据的能力。但老样子，为保持整个Hadoop系统的高可靠性，YARM也需要一套高可靠性机制。
四、YARN的高可靠性
高可靠性，主要就是对整个运行环节中的任一环节的出错情况有一套快速恢复的预案。我们结合YARN的角色看一下每个环节的解决方案
1、任务执行出错（Container）
Container作为任务的具体执行者，由任务管理器AM所监控。当Container出错时会向AM发送报告，随后释放自己的资源。AM收到失败报告后会重新启动该任务，一般会选在不同节点
2、任务管理器出错（AM）
AM作为节点信息，会周期性的向RM发送心跳信息。当AM出错时，一般会尝试进行重启。重启失败后，RM会发现该AM不可用，则会在其他节点建立一个新的AM，用来接管原AM管理的Container
３、节点管理器出错（NM）
节点管理器管理者整个节点的资源和信息，并与RM建立心跳联系。当NM出现问题，即表示该节点损坏，RM检测到之后，会将该节点从自己的节点池中移除，并将该节点上的进程加载到其他节点上运行
４、资源管理器出错（RM）
RM作为整个集群的资源管理器，是YARN最核心的部分，一旦宕机将会丢失一切任务和资源信息。为保障其高可靠性，采取了主备机制。整个集群中会运行多个RM，通过ZooKeeper进行主备选举。主RM运行中的相关信息会保存在ZooKeeper的一个存储区内，当主RM宕机或算坏后，ZooKeeper会立即选举出新的主RM。新的主RM会从ZooKeeper中获取进程的运行信息和节点的信息，来接替主RM的工作
五、总结
YARN作为Hadoop的资源协调者，是Hadoop处理大规模数据的保障。在以后学习Hadoop的上层算法中，基本都会涉及到YARN的资源协调。换句话说，YARN为大数据的高效算法提供了优秀的协调机制。
ps：计算层过段时间再更，容老夫理理思路。
