一、概念理解
Apache Hadoop YARN（Yet Another Resource Negotiator,另一种资源协调者）是一种新的Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来的巨大的好处。
YARN产生背景：
a）JobTracker单点故障
b）JobTracker承受的访问压力大，影响系统的扩展性
c）不支持MapReduce之外的计算框架，比如storm、spark、flink
YARN的优势：
资源的统一管理和调度：
集群中所有节点的资源(内存、CPU、磁盘、网络等)抽象为Container。计算框架需要资源进行运算任务时需要向YARN申请Container， YARN按照特定的策略对资源进行调度进行Container的分配。
资源隔离：
YARN使用了轻量级资源隔离机制Cgroups进行资源隔离以避免相互干扰，一旦Container使用的资源量超过事先定义的上限值，就将其杀死。
二、YARN的架构
从YARN的架构来看，它由ResourceManager、NodeManager、JobHistoryServer、Containers、Application Master、job、Task、Client组成。
组件的主要功能介绍：
（1）ResourceManager：
处理客户端请求
启动/监控ApplicationMaster
监控NodeManager
资源分配与调度
（2）ApplicationMaster：
为应用程序申请资源，并分配给内部任务
任务调度、监控与容错
（3）NodeManager：
单个节点上的资源管理
处理来自ResourceManger的命令
处理来自ApplicationMaster的命令
（4）Container：
对资源抽象和封装，目的是为了让每个应用程序对应的任务完成执行
（5）JobHistoryServer：
负责查询job运行进度及元数据管理。
（6）job：
是需要执行的一个工作单元：它包括输入数据、MapReduce程序和配置信息。job也可以叫作Application。
（7）task：
一个具体做Mapper或Reducer的独立的工作单元。task运行在NodeManager的Container中。
（8）Client：
一个提交给ResourceManager的一个Application程序。
（1）ResourceManager
ResourceManager（RM）是一个全局的资源管理器，负责整个系统的资源管理和分配，主要包括两个组件，即调度器（Scheduler）和应用程序管理器（Applications Manager）。
调度器接收来自ApplicationMaster的应用程序资源请求，把集群中的资源以“容器”的形式分配给提出申请的应用程序，容器的选择通常会考虑应用程序所要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢”。
容器（Container）作为动态资源分配单位，每个容器中都封装了一定数量的CPU、内存、磁盘等资源，从而限定每个应用程序可以使用的资源量。
调度器被设计成是一个可插拔的组件，YARN不仅自身提供了许多种直接可用的调度器，也允许用户根据自己的需求重新设计调度器。
应用程序管理器（Applications Manager）负责系统中所有应用程序的管理工作，主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等。
（2）ApplicationMaster
ResourceManager接收用户提交的作业，按照作业的上下文信息以及从NodeManager收集来的容器状态信息，启动调度过程，为用户作业启动一个ApplicationMaster。
ApplicationMaster的主要功能是：
（1）当用户作业提交时，ApplicationMaster与ResourceManager协商获取资源，ResourceManager会以容器的形式为ApplicationMaster分配资源；
（2）把获得的资源进一步分配给内部的各个任务（Map任务或Reduce任务），实现资源的“二次分配”；
（3）与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复（即重新申请资源重启任务）；
（4）定时向ResourceManager发送“心跳”消息，报告资源的使用情况和应用的进度信息；
（5）当作业完成时，ApplicationMaster向ResourceManager注销容器，执行周期完成。
（3）NodeManager
NodeManager是驻留在一个YARN集群中的每个节点上的代理，主要负责：
容器生命周期管理。
监控每个容器的资源（CPU、内存等）使用情况。
跟踪节点健康状况。
以“心跳”的方式与ResourceManager保持通信。
向ResourceManager汇报作业的资源使用情况和每个容器的运行状态。
接收来自ApplicationMaster的启动/停止容器的各种请求 。
需要说明的是，NodeManager主要负责管理抽象的容器，只处理与容器相关的事情，而不具体负责每个任务（Map任务或Reduce任务）自身状态的管理，因为这些管理工作是由ApplicationMaster完成的，ApplicationMaster会通过不断与NodeManager通信来掌握各个任务的执行状态。
三、Yarn基本流程
用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序
ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster
ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManage查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7
ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源
一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务
NodeManager为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务
各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态
应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己
四、一个job运行处理的整体流程
用户向YARN中提交作业，其中包括Application Master启动、Application Master的命令及用户程序等；ResourceManager为作业分配第一个Container，并与对应的NodeManager通信，要求它在这个Container中启动该作业的Application Master；Application Master首先向ResourceManager注册，这样用户可以直接通过ResourceManager查询作业的运行状态，然后它将为各个任务申请资源并监控任务的运行状态，直到任务结束。Application通过RPC请求想ResourceManager申请和领取资源。
然后ApplicationMaster要求指定的NodeManager节点启动任务。
启动之后，去干ResoucrceManager指定的Map task。
等Map task干完之后，通知Application Master。然后Application Master去告知Resource Manager。接下来Resource Manager分配新的资源给Application Master，让它找人去干其他的活。
接下来Application Master通知NodeManager启动新的Container准备干新的活，该活的输入是Map task的输出。
开始干Reduce task任务。
等各个节点的Reduce task都干好了，将干活的NodeManager的任务结果进行同步。做最后的Reduce任务。
等计算完了，最后将最终的结果输出到HDFS。
任务完成！
五、Yarn调度器Scheduler
理想情况下，我们应用对 Yarn 资源的请求应该立刻得到满足，但现实情况资源往往是有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到相应的资源。在Yarn中，负责给应用分配资源的就是Scheduler。其实调度本身就是一个难题，很难找到一个完美的策略可以解决所有的应用场景。为此Yarn提供了多种调度器和可配置的策略供我们选择。在 Yarn 中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，Fair Scheduler。
三种调度器基本原理：
FIFO Scheduler（先进先出调度器）： 把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推
工作方法：
单队列
先进先出原则
Capacity Scheduler（容器调度器）： 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。
工作方法：
多队列
资源使用量最小、优先级高的先执行
在多用户的情况下，可以最大化集群的吞吐量和利用率
Fair Scheduler（公平调度器）： 针对不同的应用（也可以为用户或用户组），每个应用属于一个队列，主旨是让每个应用分配的资源大体相当。（当然可以设置权重），若是只有一个应用，那集群所有资源都是他的。和 Capacity的区别是不需要预留资源 。适用情况：共享大集群、队列之间有较大差别。
工作方法：
多队列
公平调度，所有任务具有相同的资源
六、YARN的HA架构
Container 故障：Resource Manager 可以分配其他的 Container 继续执行
App Master故障：分配新的 Container，启动 App Master，新的 App Master 从 App Manager 获取相关恢复信
NodeManager 故障：移除这个节点，在其他的 NodeManager 重启继续任务。
ResourceManager 故障：在Yarn 集群中，ResourceManager 可以启动多台，只有其中一台是 active 状态的，其他都处于待命状态。 这台active 状态的 ResourceManager 执行的时候会向 ZooKeeper 集群写入它的状态； 当它故障的时候这些 RM首先选举出另外一台 leader 变为 active 状态，然后从 ZooKeeper 集群加载 ResourceManager的状态； 在转移的过程中它不接收新的 Job，转移完成后才接收新 Job。
ResourceManager HA 由一对 Active，Standby节点构成，通过RMStataStore存储内部数据和主要应用的数据及标记。
目前支持的可替代的 RMStateStore实现有：基于内存的 MemoryRMStateStore，基于文件系统的FileSystemRMStateStore，及基于Zookeeper的ZKRMStateStore。
ResourceManager HA的架构模式同NameNode HA的架构模式基本一致，数据共享由RMStateStore，而ZKFC称为ResourceManager进程的一个服务，非独立存在。
