• Apache Hadoop YARN(Yet Another Resource Negotiator)是Hadoop的子项目，为分离Hadoop2.0资源管理和计算组件而引入

• YRAN具有足够的通用性，可以支持其它的分布式计算模式
  

  一、YARN架构

  类似HDFS，YARN也是经典的主从（master/slave）架构

• YARN服务由一个ResourceManager（RM）和多个NodeManager（NM）构成

• ResourceManager为主节点（master）

• NodeManager为从节点（slave）
  
  ApplicationMaster可以在容器内运行任何类型的任务。例如，MapReduce ApplicationMaster请求容器启动map或reduce任务，而Giraph ApplicationMaster请求容器运行Giraph任务。

ResourceManager 负责对各个 NodeManager 上资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的 ApplicationMaster，它负责向 ResourceManager 申请资源，并要求 NodeManger 启动可以占用一定资源的任务。由于不同的 ApplicationMaster 被分布到不同的节点上，因此它们之间不会相互影响。

Client 向 ResourceManager 提交的每一个应用程序都必须有一个 ApplicationMaster，它经过 ResourceManager 分配资源后，运行于某一个 Slave 节点的 Container 中，具体做事情的 Task，同样也运行与某一个 Slave 节点的 Container 中。

1.1、ResourceManager

• RM是一个全局的资源管理器，集群只有一个

1. 负责整个系统的资源管理和分配
2. 包括处理客户端请求
3. 启动/监控 ApplicationMaster
4. 监控 NodeManager、资源的分配与调度

• 它主要由两个组件构成：

1. 调度器（Scheduler）
2. 应用程序管理器（Applications Manager，ASM）

• 调度器

1. 调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
2. 需要注意的是，该调度器是一个“纯调度器”

• 它不从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。
• 调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
• 应用程序管理器

1. 应用程序管理器主要负责管理整个系统中所有应用程序
   接收job的提交请求
2. 为应用分配第一个 Container 来运行 ApplicationMaster，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等

   1.2、NodeManager

   

• NodeManager 是一个 slave 服务，整个集群有多个
• NodeManager ：

1. 它负责接收 ResourceManager 的资源分配请求，分配具体的 Container 给应用。
2. 负责监控并报告 Container 使用信息给 ResourceManager。

• 功能：

1. NodeManager 本节点上的资源使用情况和各个 Container 的运行状态（cpu和内存等资源）
2. 接收及处理来自 ResourceManager 的命令请求，分配 Container 给应用的某个任务；
3. 定时地向RM汇报以确保整个集群平稳运行，RM 通过收集每个 NodeManager 的报告信息来追踪整个集群健康状态的，而 NodeManager 负责监控自身的健康状态；
4. 处理来自 ApplicationMaster 的请求；
5. 管理着所在节点每个 Container 的生命周期；
6. 管理每个节点上的日志；
7. 当一个节点启动时，它会向 ResourceManager 进行注册并告知 ResourceManager 自己有多少资源可用。
8. 在运行期，通过 NodeManager 和 ResourceManager 协同工作，这些信息会不断被更新并保障整个集群发挥出最佳状态。
9. NodeManager 只负责管理自身的 Container，它并不知道运行在它上面应用的信息。负责管理应用信息的组件是 ApplicationMaster

1.3、Container

• Container 是 YARN 中的资源抽象

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

• Container 和集群NodeManager节点的关系是：

1. 一个NodeManager节点可运行多个 Container
2. 但一个 Container 不会跨节点。
3. 任何一个 job 或 application 必须运行在一个或多个 Container 中
4. 在 Yarn 框架中，ResourceManager 只负责告诉 ApplicationMaster 哪些 Containers 可以用
5. ApplicationMaster 还需要去找 NodeManager 请求分配具体的 Container。

• 需要注意的是

1. Container 是一个动态资源划分单位，是根据应用程序的需求动态生成的
2. 目前为止，YARN 仅支持 CPU 和内存两种资源，且使用了轻量级资源隔离机制 Cgroups 进行资源隔离。

• 功能：

1. 对task环境的抽象；
2. 描述一系列信息；
3. 任务运行资源的集合（cpu、内存、io等）；
4. 任务运行环境

   1.4、ApplicationMaster

• 功能：

1. 数据切分；
2. 为应用程序申请资源并进一步分配给内部任务（TASK）；
3. 任务监控与容错；
4. 负责协调来自ResourceManager的资源，并通过NodeManager监视容器的执行和资源使用情况。

• ApplicationMaster 与 ResourceManager 之间的通信

1. 是整个 Yarn 应用从提交到运行的最核心部分，是 Yarn 对整个集群进行动态资源管理的根本步骤
2. Yarn 的动态性，就是来源于多个Application 的 ApplicationMaster 动态地和 ResourceManager 进行沟通，不断地申请、释放、再申请、再释放资源的过程。

   1.5、Resource Request

• Yarn的设计目标

1. 允许我们的各种应用以共享、安全、多租户的形式使用整个集群。
2. 并且，为了保证集群资源调度和数据访问的高效性，Yarn还必须能够感知整个集群拓扑结构。

• 为了实现这些目标，ResourceManager的调度器Scheduler为应用程序的资源请求定义了一些灵活的协议，Resource Request和Container。

1. 一个应用先向ApplicationMaster发送一个满足自己需求的资源请求
2. 然后ApplicationMaster把这个资源请求以resource-request的形式发送给ResourceManager的Scheduler
3. Scheduler再在这个原始的resource-request中返回分配到的资源描述Container。

• 每个ResourceRequest可看做一个可序列化Java对象，包含的字段信息如下：

<!--- resource-name：资源名称，现阶段指的是资源所在的host和rack，后期可能还会支持虚拟机或者更复杂的网络结构
- priority：资源的优先级
- resource-requirement：资源的具体需求，现阶段指内存和cpu需求的数量
- number-of-containers：满足需求的Container的集合
-->
<resource-name, priority, resource-requirement, number-of-containers>

1.6、JobHistoryServer

作业历史服务

• 记录在yarn中调度的作业历史运行情况情况 ,
• 通过命令启动

mr-jobhistory-daemon.sh start historyserver

• 在集群中的数据节点机器上单独使用命令启动直接启动即可,

• 启动成功后会出现JobHistoryServer进程(使用jps命令查看，下面会有介绍) ,

• 并且可以从19888端口进行查看日志详细信息node01:19888

• 点击链接，查看job日志

如果没有启动jobhistoryserver，无法查看应用的日志
打开如下图界面，在下图中点击History，页面会进行一次跳转
点击History之后 跳转后的页面如下图是空白的，因为没有启动jobhistoryserver
jobhistoryserver启动后，在此运行MR程序，如wordcount

• 点击History连接，跳转一个赞新的页面

1. TaskType中列举的map和reduce，Total表示此次运行的mapreduce程序执行所需要的map和reduce的任务数
   点击TaskType列中Map连接

看到map任务的相关信息比如执行状态,启动时间，完成时间。

• 可以使用同样的方式我们查看reduce任务执行的详细信息，这里不再赘述.
• jobhistoryserver就是进行作业运行过程中历史运行信息的记录，方便我们对作业进行分析.

1.7、Timeline Server

• 用来写日志服务数据 , 一般来写与第三方结合的日志服务数据(比如spark等)

• 它是对jobhistoryserver功能的有效补充，jobhistoryserver只能对mapreduce类型的作业信息进行记录

• 它记录除了jobhistoryserver能够进行对作业运行过程中信息进行记录之外

• 还记录更细粒度的信息，比如任务在哪个队列中运行，运行任务时设置的用户是哪个用户。

• 根据官网的解释jobhistoryserver只能记录mapreduce应用程序的记录，timelineserver功能更强大,但不是替代jobhistory两者是功能间的互补关系.

二、YARN应用运行原理

2.1、YARN应用提交过程

Application在Yarn中的执行过程，整个执行过程可以总结为三步：

• 应用程序提交
• 启动应用的ApplicationMaster实例
• ApplicationMaster 实例管理应用程序的执行

具体提交过程为：

• 客户端程序向 ResourceManager 提交应用，并请求一个 ApplicationMaster 实例；
• ResourceManager 找到一个可以运行一个 Container 的 NodeManager，并在这个 Container 中启动 ApplicationMaster 实例；
• ApplicationMaster 向 ResourceManager 进行注册，注册之后客户端就可以查询 ResourceManager 获得自己 ApplicationMaster 的详细信息，以后就可以和自己的 ApplicationMaster 直接交互了（这个时候，客户端主动和 ApplicationMaster 交流，应用先向 ApplicationMaster 发送一个满足自己需求的资源请求）；
• ApplicationMaster 根据 resource-request协议 向 ResourceManager 发送 resource-request请求；
• 当 Container 被成功分配后，ApplicationMaster 通过向 NodeManager 发送 container-launch-specification信息 来启动Container，container-launch-specification信息包含了能够让Container 和 ApplicationMaster 交流所需要的资料；
• 应用程序的代码以 task 形式在启动的 Container 中运行，并把运行的进度、状态等信息通过 application-specific协议 发送给ApplicationMaster；
• 在应用程序运行期间，提交应用的客户端主动和 ApplicationMaster 交流获得应用的运行状态、进度更新等信息，交流协议也是 application-specific协议；
• 应用程序执行完成并且所有相关工作也已经完成，ApplicationMaster 向 ResourceManager 取消注册然后关闭，用到所有的 Container 也归还给系统。

精简版的：

• 步骤1：用户将应用程序提交到 ResourceManager 上；
• 步骤2：ResourceManager为应用程序 ApplicationMaster 申请资源，并与某个 NodeManager 通信启动第一个 Container，以启动ApplicationMaster；
• 步骤3：ApplicationMaster 与 ResourceManager 注册进行通信，为内部要执行的任务申请资源，一旦得到资源后，将于 NodeManager 通信，以启动对应的 Task；
• 步骤4：所有任务运行完成后，ApplicationMaster 向 ResourceManager 注销，整个应用程序运行结束。

2.2、MapReduce on YARN

提交作业

• ①程序打成jar包，在客户端运行hadoop jar命令，提交job到集群运行
• job.waitForCompletion(true)中调用Job的submit()，此方法中调用JobSubmitter的submitJobInternal()方法；

1. ②submitClient.getNewJobID()向resourcemanager请求一个MR作业id
2. 检查输出目录：如果没有指定输出目录或者目录已经存在，则报错
3. 计算作业分片；若无法计算分片，也会报错
4. ③运行作业的相关资源，如作业的jar包、配置文件、输入分片，被上传到HDFS上一个以作业ID命名的目录（jar包副本默认为10，运行作业的任务，如map任务、reduce任务时，可从这10个副本读取jar包）
5. ④调用resourcemanager的submitApplication()提交作业

• 客户端每秒查询一下作业的进度（map 50% reduce 0%），进度如有变化，则在控制台打印进度报告；
• 作业如果成功执行完成，则打印相关的计数器
• 但如果失败，在控制台打印导致作业失败的原因（要学会查看日志，定位问题，分析问题，解决问题）

初始化作业

• 当ResourceManager(一下简称RM)收到了submitApplication()方法的调用通知后，请求传递给RM的scheduler（调度器）；调度器分配container（容器）
• ⑤a RM与指定的NodeManager通信，通知NodeManager启动容器；NodeManager收到通知后，创建占据特定资源的container；
• ⑤b 然后在container中运行MRAppMaster进程
• ⑥MRAppMaster需要接受任务（各map任务、reduce任务的）的进度、完成报告，所以appMaster需要创建多个簿记对象，记录这些信息
• ⑦从HDFS获得client计算出的输入分片split

1. 每个分片split创建一个map任务
2. 通过 mapreduce.job.reduces 属性值(编程时，jog.setNumReduceTasks()指定)，知道当前MR要创建多少个reduce任务
3. 每个任务(map、reduce)有task id

Task 任务分配

• 如果小作业，appMaster会以uberized的方式运行此MR作业；appMaster会决定在它的JVM中顺序此MR的任务；

1. 原因是，若每个任务运行在一个单独的JVM时，都需要单独启动JVM，分配资源（内存、CPU），需要时间；多个JVM中的任务再在各自的JVM中并行运行
2. 若将所有任务在appMaster的JVM中顺序执行的话，更高效，那么appMaster就会这么做 ，任务作为uber任务运行
3. 小作业判断依据：①小于10个map任务；②只有一个reduce任务；③MR输入大小小于一个HDFS块大小
4. 如何开启uber?设置属性 mapreduce.job.ubertask.enable 值为true

configuration.set("mapreduce.job.ubertask.enable", "true");

• 在运行任何task之前，appMaster调用setupJob()方法，创建OutputCommitter，创建作业的最终输出目录（一般为HDFS上的目录）及任务输出的临时目录（如map任务的中间结果输出目录）
• ⑧若作业不以uber任务方式运行，那么appMaster会为作业中的每一个任务（map任务、reduce任务）向RM请求container

1. 由于reduce任务在进入排序阶段之前，所有的map任务必须执行完成；所以，为map任务申请容器要优先于为reduce任务申请容器
2. 5%的map任务执行完成后，才开始为reduce任务申请容器
3. 为map任务申请容器时，遵循数据本地化，调度器尽量将容器调度在map任务的输入分片所在的节点上（移动计算，不移动数据）
4. reduce任务能在集群任意计算节点运行
5. 默认情况下，为每个map任务、reduce任务分配1G内存、1个虚拟内核，由属性决定mapreduce.map.memory.mb、mapreduce.reduce.memory.mb、mapreduce.map.cpu.vcores、mapreduce.reduce.reduce.cpu.vcores

Task 任务执行

• 当调度器为当前任务分配了一个NodeManager（暂且称之为NM01）的容器，并将此信息传递给appMaster后；appMaster与NM01通信，告知NM01启动一个容器，并此容器占据特定的资源量（内存、CPU）
• NM01收到消息后，启动容器，此容器占据指定的资源量
• 容器中运行YarnChild，由YarnChild运行当前任务（map、reduce）
• ⑩在容器中运行任务之前，先将运行任务需要的资源拉取到本地，如作业的JAR文件、配置文件、分布式缓存中的文件

作业运行进度与状态更新

1. 作业job以及它的每个task都有状态（running、successfully completed、failed），当前任务的运行进度、作业计数器
2. 任务在运行期间，每隔3秒向appMaster汇报执行进度、状态（包括计数器）
3. appMaster汇总目前运行的所有任务的上报的结果
4. 客户端每个1秒，轮询访问appMaster获得作业执行的最新状态，若有改变，则在控制台打印出来

完成作业

1. appMaster收到最后一个任务完成的报告后，将作业状态设置为成功
2. 客户端轮询appMaster查询进度时，发现作业执行成功，程序从waitForCompletion()退出
3. 作业的所有统计信息打印在控制台
4. appMaster及运行任务的容器，清理中间的输出结果
5. 作业信息被历史服务器保存，留待以后用户查询

2.3、YARN应用生命周期

• RM: Resource Manager
• AM: Application Master
• NM: Node Manager

1. Client向RM提交应用，包括AM程序及启动AM的命令。
2. RM为AM分配第一个容器，并与对应的NM通信，令其在容器上启动应用的AM。
3. AM启动时向RM注册，允许Client向RM获取AM信息然后直接和AM通信。
4. AM通过资源请求协议，为应用协商容器资源。
5. 如容器分配成功，AM要求NM在容器中启动应用，应用启动后可以和AM独立通信。
6. 应用程序在容器中执行，并向AM汇报。
7. 在应用执行期间，Client和AM通信获取应用状态。
8. 应用执行完成，AM向RM注销并关闭，释放资源。

申请资源->启动appMaster->申请运行任务的container->分发Task->运行Task->Task结束->回收container

三、如何使用YARN

3.1、配置文件

<!-- $HADOOP_HOME/etc/hadoop/mapred-site.xml -->
<configuration>
    <property>
        <name>mapreduce.framework.name</name>
        <value>yarn</value>
    </property>
</configuration>

<!-- $HADOOP_HOME/etc/hadoop/yarn-site.xml -->
<configuration>
    <property>
        <name>yarn.nodemanager.aux-services</name>
        <value>mapreduce_shuffle</value>
    </property>
</configuration>

3.2、YARN启动停止

启动 ResourceManager 和 NodeManager （以下分别简称RM、NM）

#主节点运行命令
$HADOOP_HOME/sbin/start-yarn.sh

停止 RM 和 NM

#主节点运行命令
$HADOOP_HOME/sbin/stop-yarn.sh

若RM没有启动起来，可以单独启动

#若RM没有启动，在主节点运行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start resouremanager
#相反，可单独关闭
$HADOOP_HOME/sbin/yarn-daemon.sh stop resouremanager

若NM没有启动起来，可以单独启动

#若NM没有启动，在相应节点运行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start nodemanager
#相反，可单独关闭
$HADOOP_HOME/sbin/yarn-daemon.sh stop nodemanager

3.3、YARN常用命令

3.3.1、yarn命令列表

3.3.2、yarn application命令

#1.查看正在运行的任务
yarn application -list

#2.杀掉正在运行任务
yarn application -kill 任务id

#3.查看节点列表
yarn node -list

#4.查看节点状况；所有端口号与上图中端口号要一致（随机分配）
yarn node -status node-03:45568

#5.查看yarn依赖jar的环境变量
yarn classpath

四、YARN应用状态

在yarn 的web ui上能够看到yarn 应用程序分为如下几个状态:

• NEW —–新建状态
• NEW_SAVING—–新建保存状态
• SUBMITTED—–提交状态
• ACCEPTED—–接受状态
• RUNNING—–运行状态
• FINISHED—–完成状态
• FAILED—–失败状态
• KILLED—–杀掉状态
  

一、介绍下Yarn的框架及其作用

YARN是Apache Hadoop的核心组件之一，用于集群资源的管理和任务调度。YARN的出现主要是为了解决早期Hadoop版本中JobTracker的性能瓶颈和可伸缩性问题。

YARN的框架由两个核心组件组成：资源管理器（ResourceManager）和应用程序管理器（ApplicationMaster），它们共同工作以实现高效的资源管理和任务调度。

• （1）ResourceManager（资源管理器）：
  ResourceManager负责整个Hadoop集群的资源分配和管理。它接收来自各个节点的资源申请，并决定如何分配这些资源给不同的应用程序。ResourceManager还负责监控集群中的资源使用情况，并在需要时重新分配资源以提高资源利用率。
• （2）ApplicationMaster（应用程序管理器）：
  每个运行在YARN上的应用程序都有一个对应的ApplicationMaster，负责该应用程序的任务调度和资源管理。当一个应用程序需要执行任务时，它会向ResourceManager申请资源，并启动一个ApplicationMaster来协调任务的执行。ApplicationMaster负责与ResourceManager通信，获取分配给应用程序的资源，并将任务分配给集群的节点上的容器进行执行。

YARN的作用主要有以下几个方面：

• （1）高效的资源调度：YARN通过从集群中的节点池中分配资源，实现了更加灵活和高效的资源调度。每个应用程序可以根据自身的需求申请所需的资源，并在任务执行完成后释放这些资源，提高整体的资源利用率。
• （2）多种计算框架支持：YARN不仅支持Hadoop MapReduce计算框架，还可以作为底层资源管理框架来支持其他计算框架（如Apache Spark、Apache Flink等）。这使得用户可以在同- 一集群上运行多种计算工作负载，提高资源的复用性和集群的利用率。
• （3）高可靠性和可扩展性：通过将资源管理和任务调度分离，YARN实现了更好的可扩展性和高可靠性。ResourceManager和ApplicationMaster的分离使得系统可以根据需要增加或减少资源管理器和应用程序管理器的数量，以适应不同规模的集群和任务需求。
• （4）支持多租户和多应用程序：YARN支持在同一个集群上同时运行多个应用程序，并为每个应用程序提供资源独立性和隔离性。这使得用户可以共享同一集群的资源，提高集群的利用率，同时保证各个应用程序之间的资源不互相干扰。

二、介绍下Yarn的任务提交流程

Hadoop中Yarn的任务提交流程如下：

• （1）向YARN提交应用程序，并指定ApplicationMaster程序、启动ApplicationMaster的命令和用户程序。
• （2）ResourceManager为该应用程序分配Container，并与对应的NodeManager进行通信，要求在该Container中启动应用程序的ApplicationMaster。
• （3）ApplicationMaster向ResourceManager注册，并将自身拆分为内部的子任务。它为每个子任务申请资源，并监控它们的运行状态，直到任务全部完成。
• （4）ApplicationMaster使用轮询方式向ResourceManager申请和领取资源。
• （5）ResourceManager为ApplicationMaster分配资源，以Container的形式返回。
• （6）ApplicationMaster与相应的NodeManager通信，要求NodeManager启动任务。
• （7）NodeManager为任务设置合适的运行环境，将任务启动命令写入脚本，并通过运行该脚本来启动任务。
• （8）各个任务定期向ApplicationMaster汇报自己的状态和进度，以便在任务失败时重新启动任务。
• （9）应用程序完成后，ApplicationMaster向ResourceManager注销并关闭自身。

三、YARN支持哪些调度（Scheduler）？

YARN支持多种调度器（Scheduler），包括以下三种常见的调度器：

• （1）Capacity Scheduler：
  容量调度器是YARN的默认调度器，它支持将集群资源划分为多个队列，并为每个队列分配一定比例的资源容量。根据队列的优先级和资源需求，容量调度器决定如何分配资源给不同的应用程序。如果某个队列没有使用其全部容量，剩余的资源可以自动分配给其他队列。这使得容量调度器适合多租户环境，可以有效地共享和管理集群资源。
• （2）Fair Scheduler：
  公平调度器根据应用程序的公平性原则来分配资源。它将集群资源按照时间片（Fair Share）的方式分配给不同的应用程序，确保每个应用程序都有公平的机会获得资源。如果有多个应用程序要求资源，调度器会尽量均匀地分配资源，避免某个应用程序长期占用过多的资源。公平调度器还支持配置权重和优先级，以满足不同应用程序的需求。
• （3）FIFO Scheduler：
  FIFO Scheduler把应用按提交的顺序排成一个队列，先进先出，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。

但它的缺点是大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。

此外，除了以上三种调度器，YARN还支持自定义调度器，允许用户根据特定需求开发和使用自己的调度算法。用户可以基于YARN提供的调度器接口，实现自定义的调度逻辑，并将其配置为YARN的调度器。这样可以根据具体的业务场景和应用需求，灵活地对资源进行调度和分配。

四、介绍下Yarn的容错机制

YARN是Hadoop生态系统中的资源调度框架，具备多个容错机制来确保集群的稳定运行。以下是YARN的主要容错机制：

• （1）ResourceManager的容错：
  ResourceManager是YARN集群中的主要调度和资源管理器。为了保证其高可用性，YARN提供了ResourceManager的容错机制。通过使用ZooKeeper实现的Active-Standby模式，可以将ResourceManager配置为主备模式，当主要的ResourceManager节点出现故障时，系统会自动切换到备用节点上，从而保证资源调度和管理的连续性。
• （2）ApplicationMaster的容错：
  在YARN中，每个应用程序都有一个对应的ApplicationMaster来管理和监控任务的执行。YARN提供了ApplicationMaster的容错机制，确保应用程序在出现故障或异常情况下能够继续执行。如果ApplicationMaster节点发生故障，YARN会自动重新分配一个新的节点，并将正在执行的任务迁移到新的节点上，从而实现容错和任务恢复。
• （3）NodeManager的容错：
  NodeManager会定期发送心跳以维持通信。如果某个组件长时间没有收到心跳，则会认为该组件出现故障。ResourceManager 会自动检测到节点的失效，并将其上面的Container状态置为失败，最后告诉对应的ApplicationMaster，以决定如何处理这些Container中运行的任务。

五、Spark on yarn 和Hadoop on yarn有什么区别？

Spark on YARN和Hadoop中的YARN是两个不同的概念，虽然它们都与YARN相关，但在功能和使用方式上有所区别。

• （1）Spark on YARN：
  Spark on YARN是指在YARN资源管理框架上运行Apache Spark的一种方式。Spark on YARN允许将Spark作为一个应用程序提交给YARN集群进行资源调度和管理。Spark应用程序通过YARN的资源管理器（ResourceManager）向集群请求所需的资源，并由YARN的应用程序主管（ApplicationMaster）进行任务的调度和监控。通过将Spark on YARN与其他基于YARN的应用程序共享集群资源，可以更有效地利用集群资源，实现资源共享和多任务调度。
• （2）Hadoop中的YARN：
  Hadoop中的YARN是一个用于大数据集群上的资源调度和管理框架。YARN作为Hadoop生态系统的一部分，负责处理不同类型的应用程序对集群资源的请求，以及任务的调度、监控和容错。YARN将集群资源划分为容器（Container），根据应用程序的需求将容器分配给不同的任务执行单元，如MapReduce任务、Spark任务等。YARN还提供了资源管理器（ResourceManager）和应用程序主管（ApplicationMaster）等关键组件来执行资源调度和任务管理。