Hadoop面试常见问题

一 什么是Hadoop？

Hadoop是一个开源的分布式计算平台，可以处理大规模数据集。它由两个核心组件组成：HDFS文件系统 和 MapReduce计算框架。

二 Hadoop的优点是什么？

可以处理大规模数据集，支持PB级别的数据存储和处理

可以在廉价的硬件上运行，降低了成本

可以通过数据冗余和自动故障转移来提高可靠性

可以通过水平扩展来提高性能

可以通过MapReduce计算框架来处理复杂的数据分析任务

三 Hadoop的工作流程是什么？

数据被分割成块并存储在HDFS中

MapReduce框架将任务分配给集群中的节点

每个节点运行Map任务来处理数据块

Map任务输出键值对，这些键值对被shuffle后传递给Reduce任务

Reduce任务对键值对进行聚合和处理，并将结果写回HDFS

四 Hadoop的数据复制是如何实现的？–涉及HDFS数据写入流程

Hadoop的数据复制是通过HDFS实现的，当数据被写入HDFS时，它被分成块并复制到多个节点上。默认情况下，每个块会被复制到三个节点上，以提高数据的可靠性。如果一个节点失效，HDFS会自动将数据块复制到其他节点上，以保证数据的可用性。

五 Hadoop是数据压缩是如何实现的？

Hadoop是数据压缩是通过MapReduce框架中的压缩器实现的。压缩器可以在Map和Reduce任务之间压缩和解压缩数据。Hadoop支持多种压缩算法，包括Gzip、Bzip2和Snappy等。

六 Hadoop的数据安全是如何实现的？

Hadoop的数据安全是通过HDFS中的访问控制列表（ACL）和MapReduce框架中的用户身份验证实现的。ACL可以控制对HDFS中文件和目录的访问权限。MapReduce框架可以通过用户身份验证来确保只有授权用户才能运行作业。

七 Hadoop的调优技巧有哪些？

增加节点数：通过增加节点数来提高性能

调整块大小：通过调整块大小来提高性能

使用压缩：通过使用压缩来减少数据传输量和磁盘空间

调整内存和CPU：通过调整内存和CPU来提高性能

使用本地磁盘：通过使用本地磁盘来提高性能

避免数据倾斜：通过避免数据倾斜来提高性能

八 Hadoop是常见问题有哪些？

数据倾斜：当数据分布不均匀时，会导致某些节点的负载过重，从而影响性能

网络带宽限制：当集群中的节点之间的网络带宽不足时，会影响性能

硬件故障：当节点硬件故障时，会影响数据可靠性和性能

数据丢失：当数据丢失时，会影响数据可靠性和性能

安全问题：当Hadoop集群存在安全漏洞时，会影响数据安全性和性能

九 如何解决Hadoop是常见问题？

数据倾斜：通过数据预处理、数据分区和数据复制等方法来避免数据倾斜

网络带宽限制：通过增加网络带宽、优化数据传输和调整数据块大小等方法来解决网络带宽限制问题

硬件故障：通过使用冗余节点、自动故障转移和备份等方法来提高数据可靠性

数据丢失：通过使用数据备份、数据恢复和数据冗余等方法来提高数据可靠性

安全问题：通过使用访问控制列表、用户身份验证和加密等方法来提高数据安全性

十 请说下HDFS读写流程

HDFS写流程：

1. Client发送上传请求，通过RPC与NameNode建立通信，NameNode检查用户是否有上传权限，以及上传的文件是否在HDFS对应的目录下不重名，如果这两者有任意一个不满足，则直接报错，如果两者都满足，则返回给客户端一个可以上传的信息；
2. Client根据文件的大小进行切分，默认128M一块，切分完成之后给NameNode发送请求第一个block块上传到哪些服务器上；
3. NameNode收到请求之后，根据网络拓扑和机架感知以及副本机制进行文件分配，返回可用的DataNode的地址；
4. Cilent收到地址之后与服务器地址列表中的一个节点如A进行通信，本质上就是RPC调用，建立pipeline，A收到请求后会继续调用B，B再调用C，将整个pipeline建立完成，逐级返回Client；
5. Cilent开始向A上发送第一个block（先从磁盘读取数据然后放到本地缓存），以packet（数据包，64kb）为单位，A收到一个packet就会发送给B，然后B发送给C，A每传完一个packet就会放入一个应答队列等待应答；
6. 数据被分隔成一个个的packet数据包在pipeline上依次传输，在pipeline反向传输中，逐个发送ack（命令正确应答），最终由pipeline中第一个DataNode节点A将pipeline ack发送给Cilent；
7. 当一个block传输完成之后，Client再次请求NameNode上传第二个block，NameNode重新选择三台DataNode给Client。

HDFS读流程：

1. Client向NameNode发送RPC请求，请求block的位置；
2. NameNode收到请求之后会检查用户权限以及是否有这个文件，如果都符合，则会视情况返回部分或全部的block列表，对于每个block，NameNode都会返回含有该block副本的DataNode地址；这些返回的DataNode地址，会按照集群拓扑结构得出DataNode与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离Client近的排靠前；心跳机制中超时汇报的DataNode状态为STALE，这样的排靠后；
3. Client选取排序靠前的DataNode来读取block，如果Client本身就是DataNode，那么将从本地直接获取数据（短路读取特性）；
4. 底层本质上是建立Socket Stream（FSDataInputStream），重复的调用父类DataInputStream的read方法，知道这个块上的数据读取完毕；
5. 当读完列表的block后，若文件读取还没有结束，Client会继续向NameNode获取下一批的block列表；
6. 读取完一个block都会进行checksum验证，如果读取DataNode时出现错误，Client会通知NameNode，然后再从下一个拥有该block副本的DataNode继续读；
7. read方法是并行的读取block信息，不是一块一块的读取；NameNode只是返回Client请求包含块的DataNode地址，并不是返回请求块是数据；
8. 最终读取来所有的block会合并成一个完整的最终文件。

十一 什么是HDFS的安全模式？

HDFS的安全模式，即HDFS safe mode，是HDFS文件系统的一种特殊状态，在该状态下，HDFS文件系统只接收数据请求，而不接收删除、修改等变更操作，也不能复制底层的block及其副本

十二 进入安全模式的两种方式

被动进入：使用命令—> hdfs dfsadmin -safemode enter

主动进入：为了保证整个文件系统的数据一致性/整个文件系统不丢失数据

• ​ 根本原因：

1. 与namenode保持定期心跳的datanode的个数没有达到指定阈值（阈值通过dfs.namenode.safemode.min.datanodes指定）

2. 没有足够的block拥有指定的副本数（也就是没达到阈值，最小副本数通过参数dfs.namenode.replication.min指定，阈值通过dfs.namenode.safemode.threshold-pct指定，默认是0.999f）

正常情况下，HDFS启动过程中，会主动进入安全模式一段时间，这是HDFS的分布式架构决定的。因为namenode启动成功后，需要等待datanode启动成功并通过心跳汇报datanode上存储的block信息，有足够的block拥有指定的副本数之后，并等待特定时间后（通过参数dfs.namenode.safemode.extensions 30000控制），主动退出安全模式。

• 直接原因：

1. 部分datanode启动失败或者因为网络原因与namenode心跳连接失败
2. 部分datanode节点存储hdfs数据的磁盘卷有损坏，导致存储在该磁盘卷中的数据无法提取
3. 部分datanode节点存储hdfs数据的磁盘分区空间满，导致存储在该磁盘卷中的数据无法正常读取

十三 修复问题–修复数据

比如如果有datanode未成功启动，则尝试修复并启动对应的datanode
比如如果有datanode存储hdfs数据的磁盘分区空间满，则尝试扩展磁盘分区空间
比如如果有datanode存在存储卷故障，则尝试修复存储卷，如果无法修复则需要替换存储卷（会丢失存储卷上的数据）

需要注意的是，如果出现了某些datanode彻底损坏无法启动，或某些datanode节点磁盘卷故障彻底无法修复的情况，则这些数据对应的block及block上层的hdfs文件，就被丢失了，就需要补数据（从上游重新拉取数据，或重新运行作业生成数据），也可能无法补。

十四 HDFS在读取文件的时候，如果其中一个块突然损坏了怎么办？

Cilent读取完DataNode上的块之后会进行checksum验证，也就是把客户端读取到本地的块与HDFS上的原始块进行校验，如果发现校验结果不一致，客户端会通知NameNode，然后再从下一个拥有该block副本的DataNode继续读。

十五 HDFS在上传文件的时候，如果其中一个DataNode突然挂掉了怎么办？

客户端上传文件时与DataNode建立pipeline管道，管道的正方向是客户端向DataNode发送的数据包，管道反方向是DataNode向客户端发送ack确认，也就是正确接收到数据包之后发送一个已确认接收到的应答。

当DataNode突然挂掉了，客户端接收不到这个DataNode发送的ack确认，客户端会通知NameNode，NameNode检查该块的副本与规定的不符，NameNode会通知DataNode去复制副本，并将挂掉的DataNode做下线处理，不再让它参与文件上传与下载。

十六 NameNode在启动的时候会做哪些操作？

NameNode数据存储在内存和本地磁盘，本地磁盘数据存储在fsimage镜像文件和edits编辑日志文件。

首次启动NameNode：

1. 格式化文件系统，为了生成fsimage镜像文件

2. 启动NameNode：

   1. 读取fsimage文件，将文件内容加载进内容
   2. 等待DataNode注册与发送block report

3. 启动DataNode：

   1. 向NameNode注册
   2. 发送block report
   3. 检查fsimage中记录的块的数量和block report中的块是总数是否相同

4. 对文件系统进行操作（创建目录、上传文件、删除文件等）：

   此时内存中已经有文件系统改变的信息，但是磁盘中没有文件系统改变的信息，此时会将这些改变信息写入edits中，edits文件中存储的是文件系统元数据改变的信息

第二次启动NameNode：

1. 读取fsimage和edits文件；
2. 将fsimage和edits文件合并成新的fsimage文件；
3. 创建新的edits文件，内容开始为空；
4. 启动DataNode

十七 谈谈对Secondary NameNode的了解，它的工作机制是怎样的？

Secondary NameNode是合并NameNode的edits logs到fsimage文件中。

它的具体工作机制：

1. Secondary NameNode询问NameNode是否需要checkpoint。直接带回结果；
2. Secondary NameNode请求执行checkpoint；
3. NameNode滚动正在写的edits日志；
4. 将滚动前的edits日志和fsimage镜像文件拷贝到Secondary NameNode；
5. Secondary NameNode加载edits日志和fsimage镜像文件到内存，并合并；
6. 生成新的镜像文件fsimage.checkpoint；
7. 拷贝到fsimage.checkpoint到NameNode；
8. NameNode将fsimage.checkpoint重新命名成fsimage；

所以如果NameNode中的元数据丢失，是可以从Secondary NameNode恢复一部分元数据信息的，但不是全部，因为NaneNode正在写的edits日志还没有拷贝到Secondary NameNode，这部分恢复不了。

十八 Secondary NameNode不能恢复NameNode的全部数据，那如何保证NameNode数据存储安全？

这个问题就要说NameNode的高可用了，即NameNode HA。

一个NameNode有单点故障问题，那就配置两个NameNode，配置有两个关键点，一是必须要保证这两个NameNode的元数据信息必须要同步的，二是一个NameNode挂掉之后另一个要立马补上。

1. 元数据信息同步在HA方案中采用的是“共享存储”。每次写文件时，需要将日志同步写入共享存储，这个步骤成功才能认定写文件成功。然后备份节点定期从共享存储同步日志，以便进行主备切换。
2. 监控NameNode状态采用zookeeper，两个NameNode节点的状态存放在zookeeper中，另外，两个NameNode节点分别有一个进程监控程序–ZKFC，实时读取zookeeper中NameNode的状态，来判断当前的NameNode是不是已经宕机。如果Standby的NameNode节点的ZKFC发现主节点已经挂掉，那么就会强制给原本的Active NameNode节点发送强制关闭请求，之后将Standby的NameNode设置为Active。

十九 在NameNode HA中，会出现脑裂问题吗？怎么解决脑裂？

会出现脑裂问题：假设 NameNode1 当前为 Active 状态，NameNode2 当前为 Standby 状态。如果某一时刻 NameNode1 发生了“假死”现象（在进行垃圾回收时 和 网络延迟大时 可能发生），那么 Zookeeper 服务端会认为 NameNode1 挂掉了，根据前面的主备切换逻辑，NameNode2 会替代 NameNode1 进入 Active 状态。但是此时 NameNode1 可能仍然处于 Active 状态正常运行，这样 NameNode1 和 NameNode2 都处于 Active 状态，都可以对外提供服务。这种情况称为脑裂。

脑裂对于NameNode这类对数据一致性要求非常高的系统来说是灾难性的，数据会发生错乱且无法恢复。zookeeper社区对这种问题的解决方法叫做fencing（隔离），也就是想办法把旧是Active NameNode隔离起来，使它不能正常对外提供服务。

在进行fencing的时候，会执行以下操作：

1. 首先尝试调用这个旧Active NameNode的HAServiceProtocol RPC接口的transition ToStandby方法，看能不能把它转换为Standby状态。
2. 如果失败，那么就执行Hadoop配置文件之中预定义的隔离措施，Hadoop目前主要提供两种隔离措施，通常会选择sshfence：
   1. sshfence：通过SSH登录到目标机器上，执行命令fuser将对应的进程杀死；
   2. shellfence：执行一个用户自定义的shell脚本来将对应的进程隔离。

二十 小文件过多会有什么危害，如何避免？

Hadoop上大量HDFS元数据信息存储在NameNode内存中，因此过多的小文件必定会压垮NameNode的内存。

每个元数据对象约占50byte，所以如果有1千万个小文件，每个文件占用一个block，则NameNode大约需要2G空间。如果存储1亿个文件，则NameNode需要20G空间。

显而易见的解决这个问腿的方法就是合并小文件，可以选择在客户端上传时执行一定的策略先合并，或者是使用Hadoop的CombineFileInputFormat<K,V>实现小文件的合并。

二十一 请说下HDFS的组织架构

1. Client：客户端
   1. 切分文件。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行存储
   2. 与NameNode交互，获取文件的位置信息
   3. 与DataNode交互，读取或者写入数据
   4. Client提供一些命令来管理HDFS，比如启动关闭HDFS、访问HDFS目录及内容（hdfs dfs -ls /）等
2. NameNode：名称节点，也称主节点，存储数据的元数据信息，不存储具体的数据
   1. 管理HDFS的名称空间
   2. 管理数据块映射信息
   3. 配置副本策略
   4. 处理客户端读写请求
3. DataNode：数据节点，也称从节点。NameNode下达命令，DataNode执行实际的操作
   1. 存储实际的数据块
   2. 执行数据块的读/写操作
4. Secondary NameNode：并非NameNode的热备。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务
   1. 辅助NameNode，分担其工作量
   2. 定期合并Fsimage和Edits，并推送给NameNode
   3. 在紧急情况下，可辅助恢复NameNode

二十二 请说下MR中的Map Task的工作机制

简单概述：

inputFile通过split被切割为多个split文件，通过Record按行读取内容给map（自己写的处理逻辑的方法），数据被map处理完之后，交给OutputCollect收集器，对其结果key进行分区（默认使用的hashPartitioner），然后写入buffer，每个map task都有一个内存缓冲区（环形缓冲区），存放着map的输出结果，当缓冲区快满的时候需要将缓冲区的数据以一个临时文件的方式溢写到磁盘，当整个map task结束后再对磁盘中这个map task产生的所有临时文件做合并，生成最终的正式输出文件，然后等待reduce task的拉取。

详细步骤：

1. 读取数据组件 InputFormat（默认 TextInputFormat）会通过 getSplits 方法对输入目录中的文件进行逻辑切片规划得到InputSplit，有多少个InputSplit就对应启动多少个map task
2. 将输入文件切分为InputSplit之后，由RecordReader对象（默认是LineRecordReader）进行读取，以 \n 作为分隔符，读取一行数据，返回<key,value>，key表示每行首字符偏移量，value表示这一行文本内容
3. 读取InputSplit返回<key,value>，进入用户自己继承的Mapper类中，执行用户重写的map函数，RecordReader读取一行这里调用一次
4. Mapper逻辑结束之后，将Mapper的每条结果通过 context.write进行collect数据收集。在collect中，会先对其进行分区处理，默认使用HashPartitioner
5. 接下来，会将数据写入内存，内存中这片区域叫做环形缓冲区（默认100M），缓冲区的作用是批量收集Mapper结果，减少磁盘IO的影响。我们的key/value键值对以及Partition的结果都会被写入缓冲区。当然，写入之前，key与value值都会被序列化成字节数组
6. 当环形缓冲区的数据达到溢写比例（默认0.8），也就是80M时，溢写线程启动，需要对这80M空间内的数据做排序和合并。排序是MR模型默认的行为，这里的排序也是对序列化的字节做的排序
7. 合并溢写文件，每次溢写会在磁盘上生成一个临时溢出文件（写之前判断是否有Combiner），如果Mapper的输出结果真的很大，有多次这样的溢写发生，磁盘上相应的就会有多个临时溢出文件存在。当整个数据处理结束之后开始对磁盘中的所有临时文件进行Merge归并、排序，因为最终的文件只有一个写入磁盘，并且为这个文件提供了一个索引文件，以记录每个reduce对应数据的偏移量

二十三 请说下MR中Reduce Task的工作机制

简单描述：

Reduce大致分为copy、sort、reduce三个阶段，重点在前两个阶段

copy阶段包含一个eventFetcher来获取已完成的map列表，由Fetcher线程去copy数据，在此过程中启动两个merge线程，分别为inMemoryMerger和onDiskMerger，分别将内存中的数据merge到磁盘和磁盘中是数据进行merge。待数据copy完成之后，copy阶段就完成了。

开始sort阶段，sort阶段主要是执行finalMerge操作，纯粹的sort阶段，完成之后就是reduce阶段，调用用户定义的reduce函数进行处理

详细步骤：

1. Copy阶段：简单地拉取数据。Reduce进程启动一些数据copy线程（Fetcher），通过HTTP方式请求map task获取属于自己的文件（map task的分区会标识每个map task属于哪个reduce task，默认reduce task的标识从0开始）

2. Merge阶段：在远程拷贝数据的同时，Reduce Task启动了两个后台线程对内存和磁盘上的文件进行合并，以防止内存使用过多或磁盘文件过多

   merge有三种形式：内存到内存；内存到磁盘；磁盘到磁盘。默认情况下第一种形式不启用。当内存中的数据量到达一定阈值，就直接启动内存到磁盘的merge。与map端类似，这也是溢写的过程，这个过程中如果你设置有Combiner，也是会启用的，然后在磁盘中生成了众多的溢写文件。内存到磁盘的merge方式一直在运行，直到没有map端的数据时才结束，然后启动第三种磁盘到磁盘的merge方式生成最终的文件

3. 合并排序：把分散的数据合并成一个大的数据后，还会再对合并后的数据排序

4. 对排序后的键值对调用reduce方法：键相等的键值对调用一次reduce方法，每次调用会产生零个或者多个键值对，最后把这些输出的键值对写入到HDFS文件中

二十四 请说下MR中的shuffle阶段

shuffle阶段分为四个步骤：分区、排序、规约、分组，其中前三个步骤在map阶段完成，最后一个步骤在reduce阶段完成

shuffle是MR的核心，它分布在MR的map阶段和reduce阶段。一般把从map产生输出开始到reduce取得数据作为输入之前的过程称作shuffle

1. Collect阶段：将Map Task的结果输出到默认为100M的环形缓冲区，保存的是key/value，Partition分区信息等
2. Spill阶段：当内存中的数据量达到一定的阈值的时候，就会将数据写入本地磁盘，在将数据写入磁盘之前需要对数据进行一次排序的操作，如果配置了Combiner，还会将有相同分区号和key的数据进行排序
3. Map Task阶段的Merge：把所有溢出的临时文件进行一次合并操作，以确保一个Map Task最终只产生一个中间数据文件
4. Copy阶段：Reduce Task启动Fetcher线程到已完成Map Task的节点上复制一份属于自己的数据，这些数据默认会保存在内存的缓冲区中，当内存的缓冲区达到一定阈值的时候，就会将数据写到磁盘上
5. Reduce Task阶段的Merge：在Reduce Task远程复制数据的同时，会在后台开启两个线程对内存到本地的数据文件进行合并操作
6. Sort阶段：在对数据进行合并的同时，会进行排序操作，由于Map Task阶段已经对数据进行了局部的排序，Reduce Task只需保证copy的数据的最终整体有效性即可

Shuffle中的缓冲区大小会影响到MR程序的执行效率，原则上说，缓冲区越大，磁盘io的次数越少，执行速度越快。缓冲区的大小可以通过参数调整，参数：mapreduce.task.io.sort.mb 默认100M

二十五 shuffle阶段的数据压缩机制了解吗？

在shuffle阶段，可以看到数据通过大量拷贝，从map阶段输出的数据，都要通过网络拷贝，发送到reduce阶段，这一过程中，涉及到大量的网络IO，如果数据能够进行压缩，那么数据的发送量就会少很多

hadoop当中支持的压缩算法：gzip、bzip2、LZO、LZ4、Snappy，这几种压缩算法综合压缩和解压缩的速率，谷歌的Snappy是最优的，一般都选择Snappy压缩。

二十六 在写MR时，什么情况下可以使用规约？

规约（Combiner）是不能够影响任务的运行结果的局部汇总，适用于求和类，不适用于求平均值，如果reduce的输入参数类型和输出参数的类型是一样的，则规约的类可以使用reduce类，只需要在驱动类中指明规约的类即可

二十七 YARN集群的架构和工作原理知道多少？

YARN的基本设计思想是将MapReduce V1中的JobTracker拆分为两个独立的服务：ResourceManager和ApplicationMaster

ResourceManager负责整个系统的资源管理和分配，ApplicationMaster负责单个应用程序的管理

1. ResourceManager：RM是一个全局的资源管理器，负责整个系统的资源管理和分配，它由两个部分组成：调度器（Scheduler）和应用程序管理器（Application Manager）

   调度器根据容量、队列等限制条件，将系统中的资源分配给正在运行的应用程序，在保证容量、公平性和服务等级的前提下，优化集群资源利用率，让所有的资源都被充分利用。应用程序管理器负责管理整个系统中的所有的应用程序，包括应用程序的提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重启它。

2. ApplicationMaster：用户提交的一个应用程序会ApplicationMaster，它的主要功能有：

   1. 与RM调度器协商以获得资源，资源以Container表示
   2. 将得到的任务进一步分配给内部的任务
   3. 与NM通信与启动/停止任务
   4. 监控所有的内部任务状态，并在任务运行失败的时候重新为任务申请资源以重启任务

3. NodeManager：NodeManager是每个节点上的资源和任务管理器，一方面，它会定期地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，他接收并处理来自AM的Container启动和停止使用请求

4. Container：Container是YARN中的资源抽象，封装了各种资源。一个应用程序会分配一个Container，这个应用程序只能使用Container中描述的资源。不同于MapReduce V1中槽位solt的资源封装，Container是一个动态资源的划分单位，更能充分利用资源。

可以把YARN中的ResourceManager比作一个工程公司，其中调度器比作财务部，负责财务（资源）的管理；应用程序管理器比作研发部，负责管理研发任务；ApplicationMaster比作研发部门的小组，但是不是事先存在的，有任务才产生；NodeManager比作研发小组中的组员；Container比作给的钱。
当一个研发任务被客户提交给公司，研发部跟财务部协商，打第一份钱来组成研发小组，研发小组成立，如果还有足够余钱（因为组成这个小组会花钱，比如配电脑什么的），就直接分配任务和钱给组员。否则就向财务部申请money，再分配给组员。在这个过程中，组员会向小组汇报任务进程，小组会向研发部汇报进程。

二十八 YARN的任务提交流程是怎样的？

当JobClient向YARN提交一个应用程序后，YARN将分两个阶段运行这个应用程序：一是启动ApplicationMaster；二是由ApplicationMaster创建应用程序，为它申请资源，监控运行直到结束。具体步骤如下：

1. 用户向YARN提交一个应用程序，并指定ApplicationMaster程序、启动ApplicationMaster、用户程序
2. RM为这个应用程序分配第一个Container，并与之对应的NM通讯，要求他在这个Container中启动应用程序ApplicationMaster
3. ApplicationMaster向RM注册，然后拆分为内部各个子任务，为各个内部任务申请资源，并监控这些任务的运行，直到结束
4. AM采用轮询的方式向RM申请和领取资源
5. RM为AM分配资源，以Container形式返回
6. AM申请到资源后，便与之对应的NM通讯，要求NM启动任务
7. NodeManager为任务设置好运行环境，将任务启动命令写到一个脚本中，并通过运行这个脚本启动任务
8. 各个任务向AM汇报自己的状态和进度，以便当任务失败时可以重启任务
9. 应用程序完成后，ApplicationMaster向ResourceManager注销并关闭自己

二十九 YARN的资源调度三种模型了解吗？

在YARN中有三种调度器可以选择：FIFO Scheduler、Capacity Scheduler、Fair Scheduler

Apache版本的hadoop默认使用的是Capacity Scheduler调度方式。CDH版本的默认使用的是Fair Scheduler调度方式

FIFO Scheduler（先来先服务）：

FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用分配资源，待最头上的应用需求满足后再给下一个分配

FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其他应用被阻塞。

Capacity Scheduler（能力调度器）：

对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO Scheduler调度器时的时间

Fair Scheduler（公平调度器）：

在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有的job动态的调整系统资源

比如：当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小job提交后，Fair调度器会分配一半资源给这个小job，让这两个任务公平的共享集群资源

需要注意的是，在Fair调度器中，第二个任务从提交到获得资源会有一定延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后，也会释放自己占用的资源，大人物又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。