YARN 概述

Yarn 是一个资源调度渠道，担任为运算程序提供服务器计算资源，相当于一个分布式的操作系统渠道，而 MapReduce、Spark、Flink 等运转程序则相当于运转于操作系统渠道之上的应用程序。

YARN 发生的背景

Yarn 是 Hadoop2.X 版别中的一个新的特性。它的呈现其实是为了处理第一代 MapReduce 编程结构的不足，提高集群环境下的资源利用率，这些资源包含了内存、磁盘、网络等等。

Hadoop2.X 版别中从头设计的这个 YARN 集群，具有更好的扩展性，可用性，可靠性，向后兼容性，以 及能支撑除 MapReduce 以外的更多分布式计算结构。

在 MapReduce 1.x 时的架构图如下：

从上图能够看到，1.x 时也是 Master/Slave 这种主从结构，在集群上的表现便是一个JobTracker 和多个 TaskTracker。

• JobTracker：担任资源办理和作业调度
  
• TaskTracker：定期向 JobTracker 报告本节点的健康状况、资源运用情况以及作业履行情况。还能够接纳来自JobTracker的指令，例如发动使命或结束使命等。
  

那么，这种架构会存在哪些问题？

1. 整个集群中只有一个 JobTracker，存在单点故障。
   
2. JobTracker 节点压力大，不但要处理Client 的恳求，还得处理 TaskTracker 的心跳等恳求。
   
3. 由于 JobTracker 是单节点，所以简单成为集群中的瓶颈，不易扩展。
   
4. JobTracker 担任的工作太多，基本上一切的工作都需求跟 JobTracker 进行交互。
   
5. 1.x 的整个集群只支撑MapReduce 使命，不支撑其他例如 Spark 的使命。
   

根据上面的种种原因，Hadoop 在 2.x 中对资源调度进行了剥离，形成了独自的组件，也便是 Yarn 。

YARN 的架构

Yarn 的架构图如下：

YARN 的基本思想是将资源办理和作业调度/监督的功用分解为独自的守护进程。它具有一个全局 ResourceManager（RM）和每个应用程序 ApplicationMaster（AM）。应用程序能够是单个作业，也能够是作业的DAG（有向无环图，能够理解为对作业相互之间的依赖联系的一种描述）。

ResourceManager

ResourceManager 是根据应用程序对集群资源的需求进行调度的 YARN 集群主控节点，担任 协谐和办理整个集群（一切 NodeManager）的资源，呼应用户提交的不同类型应用程序的 解析，调度，监控等工作。ResourceManager 会为每一个 Application 发动一个 MRAppMaster， 而且 MRAppMaster 涣散在各个 NodeManager 节点　　它主要由两个组件构成：调度器（Scheduler）和应用程序办理器（ApplicationsManager， ASM）

ResourceManager 的职责：

1. 处理客户端恳求　　　　
   
2. 发动或监控 MRAppMaster　　　　
   
3. 监控 NodeManager　　　　
   
4. 资源的分配与调度
   

NodeManager

NodeManager是每台机器结构署理，担任容器（Container）的办理，监督其资源运用情况（CPU，内存，磁盘，网络）并将其报告给 ResourceManager / Scheduler。

NodeManager 的职责：　　　　

1. 办理单个节点上的资源，敞开容器。
   
2. 处理来自 ResourceManager 的指令　　　　
   
3. 处理来自 MRAppMaster 的指令
   

ApplicationMaster

每个程序都对应一个 ApplicationMaster，它担任向资源调度器恳求履行使命的资源容器，运转使命，监控整个使命的履行，跟踪整个使命的状况，处理使命失败以异常情况。

Container

Container 容器是一个抽象出来的逻辑资源单位。容器是由 ResourceManager Scheduler 服务 动态分配的资源构成，它包含了该节点上的一定量 CPU，内存，磁盘，网络等信息，MapReduce 程序的一切 Task 都是在一个容器里履行完成的，容器的大小是能够动态调整的。

YARN 履行流程

先上图，以 WordCount 的整个运转流程为例：

整个进程如下：

1. 客户端地点的机器 履行 job.submit() ,调用 YarnRunner 去向 ResourceManager 恳求提交一个 application。
   
2. ReourceManager 返回 一个 资源提交的地址 hdfs://xxx/.staging/applicationid/  和 applicationid。因为后续的使命需求履行这些个资源文件，到这个阶段，还不了解每个使命到底会分配到哪台机器上，干脆直接给一个都能访问到的地址，使命到谁那里，就自己去这个位置拉取需求的jar 包和 配置信息。
   
3. YarnRunner 提交 job 所需求的 资源文件到上面的地址。
   
4. YarnRunner 提交资源完毕，向 ResourceManager 恳求发动 MrAppMaster。
   
5. ResourceManager 收到恳求，然后封装成一个 task 放入使命行列，等待 NodeManager 获取履行，此行列默认运用FIFO。
   
6. NodeManager1 把这次使命下载到本地。
   
7. NodeManager1 下载 job 相关的文件，并在本地地发动一个 Container 运转 MrAppMaster ，container 便是一个容器，利用的是 linux 的 cgroup ,现在市面上的虚拟化技能底层也是运用的此技能。
   
8. MrAppMaster 根据配置信息，去跟 ResourceManager 恳求运转 maptask 的容器，还是跟第 5 步一样，ReourceManager 拿到后封装成一个task 放到使命行列。
   
9. Nodemanager 2 和 3 分别下载 上个步骤的 task 使命 ,然后在本地发动一个  container  容器。
   
10. MrAppMaster  向 第9 步新发动的 容器发送 复制文件、履行 maptask 等使命的指令。maptask 履行完成后，把数据写到自己本地，容器的工作目录。
    
11. MrAppMaster  再向 YARN 恳求资源来运转 reducetask 使命。
    
12. reducetask 向 map 端获取相应的分区数据进行处理 ，处理完成后进行输出。
    
13. 整个 applicetion 履行完成后，MrAppMaster 向 ResourceManager 恳求毁掉自己。
    

参考资料

Apache Hadoop YARN http://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/YARN.html

Hadoop学习之路（二十四）YARN的资源调度 https://www.cnblogs.com/qingyunzong/p/8615096.html

分布式资源调度——YARN结构 https://blog.51cto.com/zero01/2091635