Hadoop面试-HDFS，MapReduce，Yarn

Hadoop面试

HDFS

###1.hdfs写流程

（1）客户端通过 Distributed FileSystem 模块向 NameNode 通信请求上传文件，NameNode 检查目标文件是否已存在，父目录是否存在。

（2）NameNode 返回是否可以上传。

（3）客户端请求第一个 Block 上传到哪几个 DataNode 服务器上。

（4）NameNode 返回 3 个 DataNode 节点，分别为 dn1、dn2、dn3。

（5）客户端通过 FSDataOutputStream 模块请求 dn1 上传数据（本质上是一个RPC调用，建立pipeline），dn1 收到请求会继续调用 dn2，然后 dn2 调用 dn3，将这个通信管道建立完成。

（6）dn1、dn2、dn3 逐级应答客户端。

（7）客户端开始往 dn1 上传第一个 Block（先从磁盘读取数据放到一个本地内存缓存）， 以 Packet 为单位，dn1 收到一个 Packet 就会传给 dn2，dn2 传给 dn3；dn1 每传一个 packet 会放入一个应答队列等待应答。

（8）当一个 Block 传输完成之后，客户端再次请求 NameNode 上传第二个 Block 的服务 器。（重复执行 3-7 步）

###行哥版：

1 客户端请求namenode上传文件数据(大小 , 物理切块大小, 副本个数)

2 namenode接收到客户端的上传请求以后, 各种校验(权限 , 存储容量,分配元数据信息)

3 客户端收到namenode的ok响应

4 客户端请求namenode上传第一块数据, NN返回第一块数据的元信息

5 客户端和返回的元数据中的3台机器建立连接通道 ,

6 返回OK

7 客户端本地读取待上传文件的第一块数据的内容 io.read length=128M

8 本地流一边读取数据 一边转换成分布式输出流(DistributeOutputStream)[封装字节数据为数据包 提高传输效率]

9 分布式输出流输出数据包到lx01在lx01上接收数据, 一边写到本地 一边输出给linux02 Linux02 传输给Linux03

10 linux01 02 03 都会将数据存储到本地的指定目录, 目录结构一样

11 当集群中有一个数据块存储成功 , 当次上传的数据块就是成功 , 如果副本个数不够,后续的NN会自动维护副本个数

12 返回ok 上传成功

上传后续的数据块的流程执行 4 — 12 步

在数据上传过程中要注意,客户端在将数据传输到第一个节点后,如果这个过程中这个节点宕机,或者发生其他情况,导致数据无法正常上传,那么数据就会上传失败,主节点会重新规划元数据,然后进行再次的上传,如果客户端已经成功的将数据块上传到第一个节点上后,那么这个数据块就是上传成功了,在第一个节点将数据的副本传输到其他节点上时,某个接收数据副本的节点宕机了,不会影响第一个节点将数据上传成功的信息返回给客户端,后续会根据datanode和namenode的心跳机制,将数据的副本存储到其他节点上的.

2.网络拓扑-节点距离计算

在 HDFS 写数据的过程中，NameNode 会选择距离待上传数据最近距离的 DataNode 接 收数据。那么这个最近距离怎么计算呢？

节点距离：两个节点到达最近的共同祖先的距离总和。

3.机架感知（副本存储节点选择）

1）机架感知说明

（1）官方说明 http://hadoop.apache.org/docs/r3.1.3/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html#Data_Replication

For the common case, when the replication factor is three, HDFS’s placement policy is to put one replica on the local machine if the writer is on a datanode, otherwise on a random datanode, another replica on a node in a different (remote) rack, and the last on a different node in the same remote rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure; this policy does not impact data reliability and availability guarantees. However, it does reduce the aggregate network bandwidth used when reading data since a block is placed in only two unique racks rather than three. With this policy, the replicas of a file do not evenly distribute across the racks. One third of replicas are on one node, two thirds of replicas are on one rack, and the other third are evenly distributed across the remaining racks. This policy improves write performance without compromising data reliability or read performance.

（2）源码说明 Crtl + n 查找 BlockPlacementPolicyDefault，在该类中查找 chooseTargetInOrder 方法。

2）Hadoop3.1.3 副本节点选择

###4.hdfs读流程

（1）客户端通过 DistributedFileSystem 向 NameNode 请求下载文件，NameNode 通过查 询元数据，找到文件块所在的 DataNode 地址。

（2）挑选一台 DataNode（就近原则，然后随机）服务器，请求读取数据。

（3）DataNode 开始传输数据给客户端（从磁盘里面读取数据输入流，以 Packet 为单位 来做校验）。

（4）客户端以 Packet 为单位接收，先在本地缓存，然后写入目标文件。

###5.hdfs的体系结构

###6.HDFS 文件块大小

思考：为什么块的大小不能设置太小， 也不能设置太大？
（ 1） HDFS的块设置太小， 会增加寻址时间， 程序一直在找块的开始位置；
（ 2） 如果块设置的太大， 从磁盘传输数据的时间会明显大于定位这个块开
始位置所需的时间。 导致程序在处理这块数据时， 会非常慢。
总结： HDFS块的大小设置主要取决于磁盘传输速率。

7.一个datanode 宕机,怎么一个流程恢复

Datanode宕机了后，如果是短暂的宕机，可以实现写好脚本监控，将它启动起来。如果是长时间宕机了，那么datanode上的数据应该已经被备份到其他机器了，那这台datanode就是一台新的datanode了，删除他的所有数据文件和状态文件，重新启动。

8.hadoop 的 namenode 宕机,怎么解决

先分析宕机后的损失，宕机后直接导致client无法访问，内存中的元数据丢失，但是硬盘中的元数据应该还存在，如果只是节点挂了，重启即可，如果是机器挂了，重启机器后看节点是否能重启，不能重启就要找到原因修复了。但是最终的解决方案应该是在设计集群的初期就考虑到这个问题，做namenode的HA。

9.namenode对元数据的管理

namenode对数据的管理采用了三种存储形式：

• 内存元数据(NameSystem)
• 磁盘元数据镜像文件(fsimage镜像)
• 数据操作日志文件（可通过日志运算出元数据）(edit日志文件)

10.NN 和 2NN 工作机制 （了解就行）

思考： NameNode 中的元数据是存储在哪里的？
首先，我们做个假设，如果存储在 NameNode 节点的磁盘中，因为经常需要进行随机访
问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在
内存中，一旦断电，元数据丢失，整个集群就无法工作了。 因此产生在磁盘中备份元数据的
FsImage。

这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新 FsImage，就会导
致效率过低，但如果不更新，就会发生一致性问题，一旦 NameNode 节点断电，就会产生数
据丢失。 因此，引入 Edits 文件（只进行追加操作，效率很高） 。每当元数据有更新或者添
加元数据时，修改内存中的元数据并追加到 Edits 中。 这样，一旦 NameNode 节点断电，可
以通过 FsImage 和 Edits 的合并，合成元数据。

但是，如果长时间添加数据到 Edits 中，会导致该文件数据过大，效率降低，而且一旦
断电，恢复元数据需要的时间过长。因此，需要定期进行 FsImage 和 Edits 的合并，如果这
个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于 FsImage 和 Edits 的合并。

1） 第一阶段： NameNode 启动
（1） 第一次启动 NameNode 格式化后， 创建 Fsimage 和 Edits 文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2） 客户端对元数据进行增删改的请求。
（3） NameNode 记录操作日志，更新滚动日志。
（4） NameNode 在内存中对元数据进行增删改。

2） 第二阶段： Secondary NameNode 工作
（1） Secondary NameNode 询问 NameNode 是否需要 CheckPoint。 直接带回 NameNode
是否检查结果。
（2） Secondary NameNode 请求执行 CheckPoint。
（3） NameNode 滚动正在写的 Edits 日志。
（4） 将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode。
（5） Secondary NameNode 加载编辑日志和镜像文件到内存，并合并。
（6） 生成新的镜像文件 fsimage.chkpoint。
（7） 拷贝 fsimage.chkpoint 到 NameNode。
（8） NameNode 将 fsimage.chkpoint 重新命名成 fsimage。

11.Fsimage 和 Edits 解析

fsimage和edit的区别

fsimage：filesystem image 的简写，文件镜像。

客户端修改文件时候，先更新内存中的metadata信息,只有当对文件操作成功的时候，才会写到editlog。

fsimage是文件meta信息的持久化的检查点。secondary namenode会定期的将fsimage和editlog合并dump成新的fsimage

12.DataNode 工作机制

（1） 一个数据块在 DataNode 上以文件形式存储在磁盘上，包括两个文件，一个是数据
本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。
（2） DataNode 启动后向 NameNode 注册，通过后，周期性（6 小时） 的向 NameNode 上
报所有的块信息。

DN 向 NN 汇报当前解读信息的时间间隔，默认 6 小时；

DN 扫描自己节点块信息列表的时间，默认 6 小时

（3） 心跳是每 3 秒一次，心跳返回结果带有 NameNode 给该 DataNode 的命令如复制块
数据到另一台机器，或删除某个数据块。 如果超过 10 分钟没有收到某个 DataNode 的心跳，
则认为该节点不可用。
（4） 集群运行中可以安全加入和退出一些机器。

13.DataNode数据完整性

思考：如果电脑磁盘里面存储的数据是控制高铁信号灯的红灯信号（1）和绿灯信号（0），
但是存储该数据的磁盘坏了，一直显示是绿灯，是否很危险？ 同理 DataNode 节点上的数据
损坏了， 却没有发现，是否也很危险， 那么如何解决呢？
如下是 DataNode 节点保证数据完整性的方法。
（1） 当 DataNode 读取 Block 的时候，它会计算 CheckSum。
（2） 如果计算后的 CheckSum，与 Block 创建时值不一样，说明 Block 已经损坏。
（3） Client 读取其他 DataNode 上的 Block。
（4）常见的校验算法 crc（32）， md5（128）， sha1（160）
（5） DataNode 在其文件创建后周期验证 CheckSum。

14.DataNode掉线时限参数设置

需要注意的是 hdfs-site.xml 配置文件中的 heartbeat.recheck.interval 的单位为毫秒，
dfs.heartbeat.interval 的单位为秒。

15.元数据的checkpoint

每隔一段时间，会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）

namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据

16.简单描述一下HDFS的系统架构，怎么保证数据安全?

1. 存储在HDFS系统上的文件，会分割成128M大小的block存储在不同的节点上，block的副本数默认3份，也可配置成更多份；

2. 第一个副本一般放置在与client（客户端）所在的同一节点上（若客户端无datanode，则随机放），第二个副本放置到与第一个副本同一机架的不同节点，第三个副本放到不同机架的datanode节点，当取用时遵循就近原则；

3. datanode已block为单位，每3s报告心跳状态，做10min内不报告心跳状态则namenode认为block已死掉，namonode会把其上面的数据备份到其他一个datanode节点上，保证数据的副本数量；

4. datanode会默认每小时把自己节点上的所有块状态信息报告给namenode；

5. 采用safemode模式：datanode会周期性的报告block信息。Namenode会计算block的损坏率，当阀值<0.999f时系统会进入安全模式，HDFS只读不写。HDFS元数据采用secondaryname备份或者HA备份

17.在通过客户端向hdfs中写数据的时候，如果某一台机器宕机了，会怎么处理

在写入的时候不会重新重新分配datanode。如果写入时，一个datanode挂掉，会将已经写入的数据放置到queue的顶部，并将挂掉的datanode移出pipline，将数据写入到剩余的datanode，在写入结束后， namenode会收集datanode的信息，发现此文件的replication没有达到配置的要求（default=3）,然后寻找一个datanode保存副本。

MapReduce

1.MapReduce核心编程思想

（1） 分布式的运算程序往往需要分成至少 2 个阶段。
（2） 第一个阶段的 MapTask 并发实例，完全并行运行，互不相干。
（3） 第二个阶段的 ReduceTask 并发实例互不相干，但是他们的数据依赖于上一个阶段
的所有 MapTask 并发实例的输出。
（4） MapReduce 编程模型只能包含一个 Map 阶段和一个 Reduce 阶段，如果用户的业
务逻辑非常复杂，那就只能多个 MapReduce 程序，串行运行。
总结： 分析 WordCount 数据流走向深入理解 MapReduce 核心思想。

2.MapReduce 进程

一个完整的 MapReduce 程序在分布式运行时有三类实例进程：
（1） MrAppMaster：负责整个程序的过程调度及状态协调。
（2） MapTask：负责 Map 阶段的整个数据处理流程。
（3） ReduceTask：负责 Reduce 阶段的整个数据处理流程。

3.MapReduce程序运行流程分析

4.MapTask，ReduceTask工作机制

（1） Read 阶段： MapTask 通过 InputFormat 获得的 RecordReader， 从输入 InputSplit 中
解析出一个个 key/value。
（2） Map 阶段：该节点主要是将解析出的 key/value 交给用户编写 map()函数处理，并
产生一系列新的 key/value。
（3） Collect 收集阶段**：在用户编写 map()函数中，当数据处理完成后，一般会调用
OutputCollector.collect()输出结果。在该函数内部，它会将生成的 key/value 分区（ 调用
Partitioner） ， 并写入一个环形内存缓冲区中。
（4） Spill 阶段：即“溢写”， 当环形缓冲区满后， MapReduce 会将数据写到本地磁盘上，
生成一个临时文件。需要注意的是，将数据写入本地磁盘之前，先要对数据进行一次本地排序，并在必要时对数据进行合并、 压缩等操作。

溢写阶段详情：
步骤 1： 利用快速排序算法对缓存区内的数据进行排序，排序方式是，先按照分区编号
Partition 进行排序，然后按照 key 进行排序。这样， 经过排序后，数据以分区为单位聚集在
一起，且同一分区内所有数据按照 key 有序。
步骤 2： 按照分区编号由小到大依次将每个分区中的数据写入任务工作目录下的临时文
件 output/spillN.out（N 表示当前溢写次数）中。如果用户设置了 Combiner，则写入文件之
前，对每个分区中的数据进行一次聚集操作。
步骤 3： 将分区数据的元信息写到内存索引数据结构 SpillRecord 中，其中每个分区的元
信息包括在临时文件中的偏移量、压缩前数据大小和压缩后数据大小。如果当前内存索引大
小超过 1MB，则将内存索引写到文件 output/spillN.out.index 中。

（5） Merge 阶段：当所有数据处理完成后， MapTask 对所有临时文件进行一次合并，
以确保最终只会生成一个数据文件。
当所有数据处理完后， MapTask 会将所有临时文件合并成一个大文件， 并保存到文件
output/file.out 中，同时生成相应的索引文件 output/file.out.index。
在进行文件合并过程中， MapTask 以分区为单位进行合并。对于某个分区， 它将采用多
轮递归合并的方式。 每轮合并 mapreduce.task.io.sort.factor（默认 10） 个文件，并将产生的文
件重新加入待合并列表中，对文件排序后，重复以上过程，直到最终得到一个大文件。
让每个 MapTask 最终只生成一个数据文件，可避免同时打开大量文件和同时读取大量
小文件产生的随机读取带来的开销。

（1） Copy 阶段： ReduceTask 从各个 MapTask 上远程拷贝一片数据，并针对某一片数
据，如果其大小超过一定阈值，则写到磁盘上，否则直接放到内存中。
**（2） Sort 阶段：**在远程拷贝数据的同时， ReduceTask 启动了两个后台线程对内存和磁
盘上的文件进行合并，以防止内存使用过多或磁盘上文件过多。按照 MapReduce 语义，用
户编写 reduce()函数输入数据是按 key 进行聚集的一组数据。 为了将 key 相同的数据聚在一
起， Hadoop 采用了基于排序的策略。由于各个 MapTask 已经实现对自己的处理结果进行了
局部排序，因此， ReduceTask 只需对所有数据进行一次归并排序即可。
（3） Reduce 阶段： reduce()函数将计算结果写到 HDFS 上。

5.MapReduce 工作流程

1. 一个mr程序启动的时候，最先启动的是MRAppMaster，MRAppMaster启动后根据本次job的描述信息，计算出需要的maptask实例数量，然后向集群申请机器启动相应数量的maptask进程

2. maptask进程启动之后，根据给定的数据切片范围进行数据处理，主体流程为：

3. 利用客户指定的inputformat来获取RecordReader读取数据，形成输入KV对

4. 将输入KV对传递给客户定义的map()方法，做逻辑运算，并将map()方法输出的KV对收集到缓存

5. 将缓存中的KV对按照K分区排序后不断溢写到磁盘文件

6. MRAppMaster监控到所有maptask进程任务完成之后，会根据客户指定的参数启动相应数量的reducetask进程，并告知reducetask进程要处理的数据范围（数据分区）

7. Reducetask进程启动之后，根据MRAppMaster告知的待处理数据所在位置，从若干台maptask运行所在机器上获取到若干个maptask输出结果文件，并在本地进行重新归并排序，然后按照相同key的KV为一个组，调用客户定义的reduce()方法进行逻辑运算，并收集运算输出的结果KV，然后调用客户指定的outputformat将结果数据输出到外部存储

上面的流程是整个 MapReduce 最全工作流程，但是 Shuffle 过程只是从第 7 步开始到第
16 步结束， 具体 Shuffle 过程详解， 如下：
（1） MapTask 收集我们的 map()方法输出的 kv 对，放到内存缓冲区中
（2） 从内存缓冲区不断溢出本地磁盘文件，可能会溢出多个文件
（3） 多个溢出文件会被合并成大的溢出文件
（4） 在溢出过程及合并的过程中，都要调用 Partitioner 进行分区和针对 key 进行排序
（5） ReduceTask 根据自己的分区号，去各个 MapTask 机器上取相应的结果分区数据
（6） ReduceTask 会抓取到同一个分区的来自不同 MapTask 的结果文件， ReduceTask 会将这些文件再进行合并（归并排序）
（7） 合并成大文件后， Shuffle 的过程也就结束了，后面进入 ReduceTask 的逻辑运算过
程（从文件中取出一个一个的键值对 Group，调用用户自定义的 reduce()方法）
注意：
（1） Shuffle 中的缓冲区大小会影响到 MapReduce 程序的执行效率，原则上说，缓冲区
越大，磁盘 io 的次数越少，执行速度就越快。
（2） 缓冲区的大小可以通过参数调整，参数： mapreduce.task.io.sort.mb 默认 100M。

6.Shuffle机制（shuffle 阶段,你怎么理解的）

shuffle: 洗牌、发牌——（核心机制：缓存，数据分区，排序，Merge进行局部value的合并）；

具体来说：就是将maptask输出的处理结果数据，分发给reducetask，并在分发的过程中，对数据按key进行了分区和排序；

1）Map 方法之后 Reduce 方法之前这段处理过程叫 Shuffle

2）Map 方法之后，数据首先进入到分区方法，把数据标记好分区，然后把数据发送到 环形缓冲区；环形缓冲区默认大小 100m，环形缓冲区达到 80%时，进行溢写；溢写前对数 据进行排序，排序按照对 key 的索引进行字典顺序排序，排序的手段快排；溢写产生大量溢 写文件，需要对溢写文件进行归并排序；对溢写的文件也可以进行 Combiner 操作，前提是汇总操作，求平均值不行。最后将文件按照分区存储到磁盘，等待 Reduce 端拉取。

3）每个 Reduce 拉取 Map 端对应分区的数据。拉取数据后先存储到内存中，内存不够 了，再存储到磁盘。拉取完所有数据后，采用归并排序将内存和磁盘中的数据都进行排序。

在进入 Reduce 方法前，可以对数据进行分组操作。

8.MapReduce 开发总结

1） 输入数据接口： InputFormat
（1） 默认使用的实现类是： TextInputFormat
（2） TextInputFormat 的功能逻辑是：一次读一行文本，然后将该行的起始偏移量作为
key，行内容作为 value 返回。
（3） CombineTextInputFormat 可以把多个小文件合并成一个切片处理，提高处理效率。
2） 逻辑处理接口： Mapper
用户根据业务需求实现其中三个方法： map() setup() cleanup ()
3） Partitioner 分区
（1）有默认实现 HashPartitioner，逻辑是根据 key 的哈希值和 numReduces 来返回一个
分区号； key.hashCode()&Integer.MAXVALUE % numReduces
（2）如果业务上有特别的需求，可以自定义分区。
4） Comparable 排序
（1）当我们用自定义的对象作为 key 来输出时，就必须要实现 WritableComparable 接
口，重写其中的 compareTo()方法。
（2） 部分排序：对最终输出的每一个文件进行内部排序。
（3）全排序：对所有数据进行排序，通常只有一个 Reduce。
（4）二次排序：排序的条件有两个。
5） Combiner 合并
Combiner 合并可以提高程序执行效率，减少 IO 传输。但是使用时必须不能影响原有的
业务处理结果。
6） 逻辑处理接口： Reducer
用户根据业务需求实现其中三个方法： reduce() setup() cleanup ()
7） 输出数据接口： OutputFormat
（1）默认实现类是 TextOutputFormat，功能逻辑是：将每一个 KV 对，向目标文本文件
输出一行。
（2）用户还可以自定义 OutputFormat。

9.用mapreduce怎么处理数据倾斜问题？

数据倾斜：map /reduce程序执行时，reduce节点大部分执行完毕，但是有一个或者几个reduce节点运行很慢，导致整个程序的处理时间很长，这是因为某一个key的条数比其他key多很多（有时是百倍或者千倍之多），这条key所在的reduce节点所处理的数据量比其他节点就大很多，从而导致某几个节点迟迟运行不完，此称之为数据倾斜。

（1）局部聚合加全局聚合。

第一次在 map 阶段对那些导致了数据倾斜的 key 加上 1 到 n 的随机前缀，这样本来相

同的 key 也会被分到多个 Reducer 中进行局部聚合，数量就会大大降低。

第二次 mapreduce，去掉 key 的随机前缀，进行全局聚合。

思想：二次 mr，第一次将 key 随机散列到不同 reducer 进行处理达到负载均衡目的。第

二次再根据去掉 key 的随机前缀，按原 key 进行 reduce 处理。

这个方法进行两次 mapreduce，性能稍差。

（2）增加 Reducer，提升并行度

JobConf.setNumReduceTasks(int)

（3）实现自定义分区

根据数据分布情况，自定义散列函数，将 key 均匀分配到不同 Reducer

10.Mapreduce 的 map 数量 和 reduce 数量是由什么决定的 ,怎么配置

map的数量由输入切片的数量决定，128M切分一个切片，只要是文件也分为一个切片，有多少个切片就有多少个map Task。

reduce数量自己配置。

11.MapReduce优化经验

1.设置合理的map和reduce的个数。合理设置blocksize

2.避免出现数据倾斜

3.combine函数

4.对数据进行压缩

5.小文件处理优化：事先合并成大文件，combineTextInputformat，在hdfs上用mapreduce将小文件合并成SequenceFile大文件（key:文件名，value：文件内容）

6.参数优化

###12.mapreduce内部处理数据流程和shuffle详解

https://blog.csdn.net/qq_37933018/article/details/107336396

###13.mapreduce数据分析案例之实现SQL JOIN语法

https://blog.csdn.net/qq_37933018/article/details/107297870

Yarn

1.Yarn 基础架构

YARN 主要由 ResourceManager、 NodeManager、 ApplicationMaster 和 Container 等组件
构成。

###2.Yarn 工作机制

（1） MR 程序提交到客户端所在的节点。
（2） YarnRunner 向 ResourceManager 申请一个 Application。
（3） RM 将该应用程序的资源路径返回给 YarnRunner。
（4）该程序将运行所需资源提交到 HDFS 上。
（5）程序资源提交完毕后，申请运行 mrAppMaster。
（6） RM 将用户的请求初始化成一个 Task。
（7）其中一个 NodeManager 领取到 Task 任务。
（8）该 NodeManager 创建容器 Container， 并产生 MRAppmaster。
（9） Container 从 HDFS 上拷贝资源到本地。
（10） MRAppmaster 向 RM 申请运行 MapTask 资源。
（11） RM 将运行 MapTask 任务分配给另外两个 NodeManager， 另两个 NodeManager 分
别领取任务并创建容器。
（12） MR 向两个接收到任务的 NodeManager 发送程序启动脚本， 这两个 NodeManager
分别启动 MapTask， MapTask 对数据分区排序。
（13）MrAppMaster 等待所有 MapTask 运行完毕后，向 RM 申请容器， 运行 ReduceTask。
（14） ReduceTask 向 MapTask 获取相应分区的数据。
（15）程序运行完毕后， MR 会向 RM 申请注销自己。

3.HDFS、 YARN、 MapReduce三者关系

4.作业提交过程之YARN

5.作业提交过程之HDFS & MapReduce

作业提交全过程详解
（1） 作业提交
第 1 步： Client 调用 job.waitForCompletion 方法，向整个集群提交 MapReduce 作业。
第 2 步： Client 向 RM 申请一个作业 id。
第 3 步： RM 给 Client 返回该 job 资源的提交路径和作业 id。
第 4 步： Client 提交 jar 包、切片信息和配置文件到指定的资源提交路径。
第 5 步： Client 提交完资源后，向 RM 申请运行 MrAppMaster。
（2） 作业初始化
第 6 步： 当 RM 收到 Client 的请求后，将该 job 添加到容量调度器中。
第 7 步： 某一个空闲的 NM 领取到该 Job。
第 8 步： 该 NM 创建 Container， 并产生 MRAppmaster。
第 9 步：下载 Client 提交的资源到本地。
（3） 任务分配
第 10 步： MrAppMaster 向 RM 申请运行多个 MapTask 任务资源。
第 11 步： RM 将运行 MapTask 任务分配给另外两个 NodeManager， 另两个 NodeManager
分别领取任务并创建容器。
（4） 任务运行
第 12 步： MR 向两个接收到任务的 NodeManager 发送程序启动脚本， 这两个
NodeManager 分别启动 MapTask， MapTask 对数据分区排序。
第13步： MrAppMaster等待所有MapTask运行完毕后，向RM申请容器， 运行ReduceTask。
第 14 步： ReduceTask 向 MapTask 获取相应分区的数据。
第 15 步： 程序运行完毕后， MR 会向 RM 申请注销自己。
（5） 进度和状态更新
YARN 中的任务将其进度和状态(包括 counter)返回给应用管理器, 客户端每秒(通过
mapreduce.client.progressmonitor.pollinterval 设置)向应用管理器请求进度更新, 展示给用户。
（6） 作业完成
除了向应用管理器请求作业进度外, 客户端每 5 秒都会通过调用 waitForCompletion()来
检查作业是否完成。 时间间隔可以通过 mapreduce.client.completion.pollinterval 来设置。 作业
完成之后, 应用管理器和 Container 会清理工作状态。 作业的信息会被作业历史服务器存储
以备之后用户核查。

###6.yarn的三大调度策略

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

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

在Fair（公平）调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。

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

###行哥：https://blog.csdn.net/qq_37933018/article/details/107338151

###7.MR在Yarn上运行流程

https://blog.csdn.net/qq_37933018/article/details/107337897

其他

1.hadoop中combiner和partition的作用

combiner是发生在map的最后一个阶段，父类就是Reducer，意义就是对每一个maptask的输出进行局部汇总，以减小网络传输量，缓解网络传输瓶颈，提高reducer的执行效率。

partition的主要作用将map阶段产生的所有kv对分配给不同的reducer task处理，可以将reduce阶段的处理负载进行分摊

2.分别举例什么情况要使用 combiner，什么情况不使用？

求平均数的时候就不需要用combiner，因为不会减少reduce执行数量。在其他的时候，可以依据情况，使用combiner，来减少map的输出数量，减少拷贝到reduce的文件，从而减轻reduce的压力，节省网络开销，提升执行效率

3.Hadoop优化有哪些方面

0）HDFS 小文件影响

（1）影响 NameNode 的寿命，因为文件元数据存储在 NameNode 的内存中

（2）影响计算引擎的任务数量，比如每个小的文件都会生成一个 Map 任务

1）数据输入小文件处理：

（1）合并小文件：对小文件进行归档（Har）、自定义 Inputformat 将小文件存储成SequenceFile 文件。

（2）采用 ConbinFileInputFormat 来作为输入，解决输入端大量小文件场景。

（3）对于大量小文件 Job，可以开启 JVM 重用。

2）Map 阶段

（1）增大环形缓冲区大小。由 100m 扩大到 200m

（2）增大环形缓冲区溢写的比例。由 80%扩大到 90%

（3）减少对溢写文件的 merge 次数。（10 个文件，一次 20 个 merge）

（4）不影响实际业务的前提下，采用 Combiner 提前合并，减少 I/O。

3）Reduce 阶段

（1）合理设置 Map 和 Reduce 数：两个都不能设置太少，也不能设置太多。太少，会导致 Task 等待，延长处理时间；太多，会导致 Map、Reduce 任务间竞争资源，造成处理超时等错误。

（2）设置 Map、Reduce 共存：调整 slowstart.completedmaps 参数，使 Map 运行到一定程度后，Reduce 也开始运行，减少 Reduce 的等待时间。

（3）规避使用 Reduce，因为 Reduce 在用于连接数据集的时候将会产生大量的网络消耗。

（4）增加每个 Reduce 去 Map 中拿数据的并行数

（5）集群性能可以的前提下，增大 Reduce 端存储数据内存的大小。

4）IO 传输

（1）采用数据压缩的方式，减少网络 IO 的的时间。安装 Snappy 和 LZOP 压缩编码器。

（2）使用 SequenceFile 二进制文件

5）整体

（1）MapTask 默认内存大小为 1G，可以增加 MapTask 内存大小为 4-5g

（2）ReduceTask 默认内存大小为 1G，可以增加 ReduceTask 内存大小为 4-5g

（3）可以增加 MapTask 的 cpu 核数，增加 ReduceTask 的 CPU 核数

（4）增加每个 Container 的 CPU 核数和内存大小

（5）调整每个 Map Task 和 Reduce Task 最大重试次数

4.大量数据求topN(写出mapreduce的实现思路）

5.列出正常工作的hadoop集群中hadoop都分别启动哪些进程以及他们的作用

1.NameNode它是hadoop中的主服务器，管理文件系统名称空间和对集群中存储的文件的访问，保存有metadate。

2.SecondaryNameNode它不是namenode的冗余守护进程，而是提供周期检查点和清理任务。帮助NN合并editslog，减少NN启动时间。

3.DataNode它负责管理连接到节点的存储（一个集群中可以有多个节点）。每个存储数据的节点运行一个datanode守护进程。

4.ResourceManager（JobTracker）JobTracker负责调度DataNode上的工作。每个DataNode有一个TaskTracker，它们执行实际工作。

5.NodeManager（TaskTracker）执行任务

6.DFSZKFailoverController高可用时它负责监控NN的状态，并及时的把状态信息写入ZK。它通过一个独立线程周期性的调用NN上的一个特定接口来获取NN的健康状态。FC也有选择谁作为Active NN的权利，因为最多只有两个节点，目前选择策略还比较简单（先到先得，轮换）。

7.JournalNode 高可用情况下存放namenode的editlog文件.

6.Hadoop总job和Tasks之间的区别是什么？

Job是我们对一个完整的mapreduce程序的抽象封装

Task是job运行时，每一个处理阶段的具体实例，如map task，reduce task，maptask和reduce task都会有多个并发运行的实例

7.Hadoop高可用HA模式

HDFS高可用原理：

Hadoop HA（High Available）通过同时配置两个处于Active/Passive模式的Namenode来解决上述问题，状态分别是Active和Standby. Standby Namenode作为热备份，从而允许在机器发生故障时能够快速进行故障转移，同时在日常维护的时候使用优雅的方式进行Namenode切换。Namenode只能配置一主一备，不能多于两个Namenode。

主Namenode处理所有的操作请求（读写），而Standby只是作为slave，维护尽可能同步的状态，使得故障时能够快速切换到Standby。为了使Standby Namenode与Active Namenode数据保持同步，两个Namenode都与一组Journal Node进行通信。当主Namenode进行任务的namespace操作时，都会确保持久会修改日志到Journal Node节点中。Standby Namenode持续监控这些edit，当监测到变化时，将这些修改同步到自己的namespace。

当进行故障转移时，Standby在成为Active Namenode之前，会确保自己已经读取了Journal Node中的所有edit日志，从而保持数据状态与故障发生前一致。

为了确保故障转移能够快速完成，Standby Namenode需要维护最新的Block位置信息，即每个Block副本存放在集群中的哪些节点上。为了达到这一点，Datanode同时配置主备两个Namenode，并同时发送Block报告和心跳到两台Namenode。

确保任何时刻只有一个Namenode处于Active状态非常重要，否则可能出现数据丢失或者数据损坏。当两台Namenode都认为自己的Active Namenode时，会同时尝试写入数据（不会再去检测和同步数据）。为了防止这种脑裂现象，Journal Nodes只允许一个Namenode写入数据，内部通过维护epoch数来控制，从而安全地进行故障转移。

8.简要描述安装配置一个hadoop集群的步骤

1.使用root账户登录。

2.修改IP。

3.修改Host主机名。

4.配置SSH免密码登录。

5.关闭防火墙。

6.安装JDK。

7.上传解压Hadoop安装包。

8.配置Hadoop的核心配置文件hadoop-evn.sh，core-site.xml，mapred-site.xml，hdfs-site.xml，yarn-site.xml

9.配置hadoop环境变量

10.格式化hdfs # bin/hadoop namenode -format

11.启动节点start-all.sh

9.hadoop的shell命令用的多吗?,说出一些常用的

10.用mr实现用户pv的top10？

11.HDFS-HA故障转移机制