说在前面：

《尼恩 大数据 面试宝典》 是 《尼恩Java面试宝典》 姊妹篇。

这里特别说明一下：《尼恩Java面试宝典》41个专题 PDF （请在文末获取）自发布以来， 已经收集了 好几千题， 足足4000多页，帮助很多小伙伴进了大厂，拿了高薪。 已经变成Java学习和面试的必读书籍。

于是，尼恩团队趁热打铁，推出 《尼恩 大数据 面试宝典》

《尼恩 大数据 面试宝典》 后面会不断升级，不断 迭代， 变成大数据领域 学习和面试的必读书籍。

注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，请从文末【技术自由圈】获取

作者介绍：

一作：Mark， 资深大数据架构师、Java架构师，近20年Java、大数据架构和开发经验。资深架构导师，成功指导了多个中级Java、高级Java转型架构师岗位。

二作： 尼恩，资深系统架构师、IT领域资深作家、著名博主。近20年高性能Web平台、高性能通信、高性能搜索、数据挖掘等领域的3高架构研究、系统架构、系统分析、核心代码开发工作。资深架构导师，成功指导了多个中级Java、高级Java转型架构师岗位。

专题1： 史上最全Hadoop面试题

1、聊聊：Hadoop 集群的最主要瓶颈

Hadoop 集群的最主要瓶颈可能包括以下几个方面：

1. 网络带宽：Hadoop 集群中的数据通常需要在不同的节点之间传输，如果网络带宽不足，可能会导致数据传输速度变慢，从而影响整个集群的性能。
2. 存储性能：Hadoop 集群通常使用分布式文件系统来存储数据，如果存储性能不足，可能会导致数据读写速度变慢，从而影响整个集群的性能。
3. 计算资源：Hadoop 集群中的计算任务通常需要在不同的节点上执行，如果某些节点的计算资源不足，可能会导致任务执行速度变慢，从而影响整个集群的性能。
4. 数据倾斜：在某些情况下，Hadoop 集群中的数据可能会出现倾斜，即某些节点的数据量过大，导致这些节点的计算任务执行时间过长，从而影响整个集群的性能。
5. 调度策略：Hadoop 集群中的任务通常需要由调度器进行分配和调度，如果调度策略不合理，可能会导致某些节点的负载过重，从而影响整个集群的性能。

2、聊聊：Hadoop运行模式

本地模式、伪分布式模式、完全分布式模式

本地模式是指Hadoop运行在单机上，数据存储在本地文件系统中，适用于数据量较小的情况，主要用于开发和测试。

分布式模式是指Hadoop运行在多台机器上，数据被分割成多个块，存储在不同的节点上，通过网络进行通信和协调，适用于处理大规模数据的情况，主要用于生产环境。在分布式模式下，Hadoop提供了两种运行模式：独立模式和伪分布式模式。

伪分布式模式是指Hadoop运行在单台机器上，但是各个组件运行在不同的进程中，模拟了分布式环境，适用于开发和测试。

3、聊聊：Hadoop生态圈的组件并做简要描述

1）Zookeeper：是一个开源的分布式应用程序协调服务,基于zookeeper可以实现同步服务，配置维护，命名服务。

2）Flume：一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统。

3）Hbase：是一个分布式的、面向列的开源数据库, 利用Hadoop HDFS作为其存储系统。

4）Hive：基于Hadoop的一个数据仓库工具，可以将结构化的数据档映射为一张数据库表，并提供简单的sql 查询功能，可以将sql语句转换为MapReduce任务进行运行。

5）Sqoop：将一个关系型数据库中的数据导进到Hadoop的 HDFS中，也可以将HDFS的数据导进到关系型数据库中。

4、聊聊：“hadoop”和“hadoop 生态系统”两个概念

Hadoop是指Hadoop框架本身；hadoop生态系统，不仅包含hadoop，还包括保证hadoop框架正常高效运行其他框架，比如zookeeper、Flume、Hbase、Hive、Sqoop等辅助框架。

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、聊聊： HDFS 中的 block 默认保存几份？

在 HDFS 中，block 默认会被保存三份，这也被称为副本（replica）。

这种副本的机制被称为数据冗余（data redundancy），它的目的是为了提高数据的可靠性和可用性。当某个副本不可用时，HDFS 可以使用其他副本来保证数据的可用性。

同时，HDFS 还会定期地对副本进行校验，确保它们的一致性。

可以通过修改 HDFS 的配置来改变副本的数量。

但是需要注意的是，增加副本数量会占用更多的存储空间和网络带宽，因此需要根据实际情况进行权衡。

7、聊聊：HDFS 默认 BlockSize 是多大？

HDFS（Hadoop Distributed File System）的默认 BlockSize 是 128MB。

这个值可以通过 HDFS 的配置文件进行修改，但是一般来说，不建议随意修改这个值，因为它会影响到 HDFS 的性能和数据存储的效率。如果你需要存储的文件比较小，可以考虑将多个小文件合并成一个大文件，以达到更好的存储效率。

8、聊聊：负责HDFS数据存储的是哪一部分？

DataNode负责数据存储

9、聊聊：SecondaryNameNode的目的是什么？

他的目的使帮助NameNode合并编辑日志，减少NameNode 启动时间

10、聊聊：hadoop的块大小，从哪个版本开始是128M

Hadoop1.x都是64M，hadoop2.x开始都是128M。

11、聊聊：HDFS读写流程

尼恩提示：

这个问题是个核心 题目。 虽然见过无数次，面试官问过无数次。

但是，还是有不少面试者不能完整的说出来，所以，请务必记住。

另外，并且很多问题都是从HDFS读写流程中引申出来的。

HDFS写流程：

Client客户端发送上传请求，通过RPC与NameNode建立通信，NameNode检查该用户是否有上传权限，以及上传的文件是否在HDFS对应的目录下重名，如果这两者有任意一个不满足，则直接报错，如果两者都满足，则返回给客户端一个可以上传的信息；

Client根据文件的大小进行切分，默认128M一块，切分完成之后给NameNode发送请求，询问第一个block块上传到哪些服务器上；

NameNode收到请求之后，根据网络拓扑和机架感知以及副本机制进行文件分配，返回可用的DataNode的地址；

注：Hadoop在设计时考虑到数据的安全与高效, 数据文件默认在HDFS上存放三份, 存储策略为本地一份，同机架内其它某一节点上一份, 不同机架的某一节点上一份。

客户端收到地址之后与服务器地址列表中的一个节点如A进行通信，本质上就是RPC调用，建立pipeline，A收到请求后会继续调用B，B再调用C，将整个pipeline建立完成，逐级返回Client；

Client开始向A上发送第一个block（先从磁盘读取数据然后放到本地内存缓存），以packet（数据包，64kb）为单位，A收到一个packet就会发送给B，然后B发送给C，A每传完一个packet就会放入一个应答队列等待应答；

数据被分割成一个个的packet数据包在pipeline上依次传输，在pipeline反向传输中，逐个发送ack（命令正确应答），最终由pipeline中第一个DataNode节点A将pipelineack发送给Client；

当一个block传输完成之后, Client再次请求NameNode上传第二个block，NameNode重新选择三台DataNode给Client。

HDFS读流程：

Client向NameNode发送RPC请求。请求文件block的位置；

NameNode收到请求之后会检查用户权限以及是否有这个文件，如果都符合，则会视情况返回部分或全部的block列表，对于每个block，NameNode都会返回含有该block副本的DataNode地址；这些返回的DataNode地址，会按照集群拓扑结构得出DataNode与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离 Client 近的排靠前；心跳机制中超时汇报的DataNode状态为STALE，这样的排靠后；

Client选取排序靠前的DataNode来读取block，如果客户端本身就是DataNode,那么将从本地直接获取数据(短路读取特性)；

底层上本质是建立Socket Stream（FSDataInputStream），重复的调用父类DataInputStream的read方法，直到这个块上的数据读取完毕；

当读完列表的block后，若文件读取还没有结束，客户端会继续向NameNode 获取下一批的block列表；

读取完一个block都会进行checksum验证，如果读取DataNode时出现错误，客户端会通知NameNode，然后再从下一个拥有该block副本的DataNode 继续读；

read方法是并行的读取block信息，不是一块一块的读取；NameNode只是返回Client请求包含块的DataNode地址，并不是返回请求块的数据；

最终读取来所有的block会合并成一个完整的最终文件；

12、聊聊：HDFS在读取文件的时候，如果其中一个块突然损坏了怎么办

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

也就是说：如果 HDFS 中的一个块在读取时损坏了，HDFS 会尝试从其他副本中读取数据。在 HDFS 中，每个块都有多个副本，这些副本通常存储在不同的节点上。如果一个副本损坏了，HDFS 会尝试从其他副本中读取数据，以确保数据的完整性和可用性。

在 HDFS 中，块的副本数量是可以配置的，默认情况下是三个。如果一个副本损坏了，HDFS 会尝试从其他副本中读取数据，如果所有的副本都损坏了，那么这个块就会被标记为“丢失”，这时需要进行数据恢复或重新上传数据。

13、聊聊：HDFS在上传文件的时候，如果其中一个DataNode突然挂掉了怎么办

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

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

14、聊聊：NameNode在启动的时候会做哪些操作

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

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

（1）首次启动NameNode：

①首先格式化NameNode，生成fsimage镜像文件；

②启动NameNode：

• 读取fsimage镜像文件，将文件内容加载进内存，
• 等待DataNode的注册和block report；

③启动DataNode：

• 首先向NameNode进行注册
• 发送block report
• 检查fsimage中的block是否和block report中的数量一致；

④对文件系统进行操作：

• 此时的创建目录，上传文件等等这些改变信息会被记录在edits编辑日志文件中；

（2）第二次启动NameNode：

①读取fsimage和edits文件；

②将两个fsimage中的数据进行编辑日志文件记录的操作后生成新的fsimage镜像文件；

③创建新的edits编辑日志文件；

④启动DataNode节点。

15、聊聊： Secondary NameNode了解吗，它的工作机制是怎样的

SecondaryNameNode有两个作用，一是镜像备份，二是日志与镜像的定期合并。两个过程同时进行，称为checkpoint（检查点）。

从Secondary NameNode的名字上看，它给人的感觉就像是NameNode的备份,但它实际上却不是。很多Hadoop的初学者都很疑惑，Secondary NameNode究竟是做什么的，以及它为什么会出现在HDFS中。

首先回顾NameNode

NameNode主要是用来保存HDFS的元数据信息，比如命名空间信息，块信息等。

当NameNode运行的时候，这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。

上面的这张图片展示了NameNode怎么把元数据保存到磁盘上的。这里有两个不同的文件：

• fsimage - 它是在NameNode启动时对整个文件系统的快照
• edit logs - 它是在NameNode启动后，对文件系统的改动序列

只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。

在这种情况下就会出现下面一些问题：

• edit logs文件会变的很大，怎么去管理这个文件是一个挑战。
• NameNode的重启会花费很长时间，因为有很多改动要合并到fsimage文件上。

如果NameNode挂掉了，那我们就丢失了很多改动因为此时的fsimage文件非常旧。

因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。这跟Windows的恢复点是非常像的，Windows的恢复点机制允许我们对OS进行快照，这样当系统发生问题时，我们能够回滚到最新的一次恢复点上。

现在我们明白了NameNode的功能和所面临的挑战 - 保持文件系统最新的元数据。

那么，这些跟Secondary NameNode又有什么关系呢？

Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。

它不是要取代掉NameNode也不是NameNode的备份， SecondaryNameNode有两个作用，一是镜像备份，二是日志与镜像的定期合并。

两个过程同时进行，称为checkpoint（检查点）。

镜像备份的作用：备份fsimage(fsimage是元数据发送检查点时写入文件)； 日志与镜像的定期合并的作用：将Namenode中edits日志和fsimage合并,防止如果Namenode节点故障，

namenode下次启动的时候，会把fsimage加载到内存中，应用edits log，edits log往往很大，导致操作往往很耗时。（这也是namenode容错的一套机制）

Secondarynamenode工作过程

SecondaryNameNode备份由三个参数控制fs.checkpoint.period控制周期（以秒为单位，默认3600秒），fs.checkpoint.size控制日志文件超过多少大小时合并（以字节为单位，默认64M）， dfs.http.address表示http地址，这个参数在SecondaryNameNode为单独节点时需要设置。

1. SecondaryNameNode通知NameNode准备提交edits文件，此时主节点将新的写操作数据记录到一个新的文件edits.new中。
2. SecondaryNameNode通过HTTP GET方式获取NameNode的fsimage与edits文件（在SecondaryNameNode的current同级目录下可见到 temp.check-point或者previous-checkpoint目录，这些目录中存储着从namenode拷贝来的镜像文件）。
3. SecondaryNameNode开始合并获取的上述两个文件，产生一个新的fsimage文件fsimage.ckpt。
4. SecondaryNameNode用HTTP POST方式发送fsimage.ckpt至NameNode。
5. NameNode将fsimage.ckpt与edits.new文件分别重命名为fsimage与edits，然后更新fstime，整个checkpoint过程到此结束。

从工作过程可以看出，SecondaryNameNode的重要作用是定期通过编辑日志文件合并命名空间镜像，以防止编辑日志文件过大。SecondaryNameNode一般要在另一台机器上运行，因为它需要占用大量的CPU时间与namenode相同容量的内存才可以进行合并操作。它会保存合并后的命名空间镜像的副本，并在namenode发生故障时启用。

16、聊聊：Secondary NameNode不能恢复NameNode的全部数据，那如何保证NameNode数据存储安全

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

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

元数据信息同步在 HA 方案中采用的是“共享存储”。每次写文件时，需要将日志同步写入共享存储，这个步骤成功才能认定写文件成功。然后备份节点定期从共享存储同步日志，以便进行主备切换。

监控NameNode状态采用zookeeper，两个NameNode节点的状态存放在zookeeper中，另外两个NameNode节点分别有一个进程监控程序，实施读取zookeeper中有NameNode的状态，来判断当前的NameNode是不是已经down机。如果Standby的NameNode节点的ZKFC发现主节点已经挂掉，那么就会强制给原本的Active NameNode节点发送强制关闭请求，之后将备用的NameNode设置为Active。

提示：如果面试官再问HA中的 共享存储 是怎么实现的知道吗？

可以进行解释下：NameNode 共享存储方案有很多，比如Linux HA, VMware FT, QJM等，目前社区已经把由Clouderea公司实现的基于QJM（Quorum Journal Manager）的方案合并到HDFS的trunk之中并且作为默认的共享存储实现。

基于QJM的共享存储系统主要用于保存EditLog，并不保存FSImage文件。FSImage文件还是在NameNode的本地磁盘上。

QJM共享存储的基本思想来自于Paxos算法，采用多个称为JournalNode的节点组成的JournalNode集群来存储EditLog。每个JournalNode保存同样的EditLog副本。每次NameNode写EditLog的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向JournalNode集群之中的每一个JournalNode发送写请求，只要大多数的JournalNode节点返回成功就认为向JournalNode集群写入EditLog成功。如果有2N+1台JournalNode，那么根据大多数的原则，最多可以容忍有N台JournalNode节点挂掉。

17、聊聊： Secondary namenode工作机制

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。

NameNode与SecondaryNameNode 的区别与联系？

1）区别：

（1）NameNode负责管理整个文件系统的元数据，以及每一个路径（文件）所对应的数据块信息。

（2）SecondaryNameNode主要用于定期合并命名空间镜像和命名空间镜像的编辑日志。

2）联系：

（1）SecondaryNameNode中保存了一份和namenode一致的镜像文件（fsimage）和编辑日志（edits）。

（2）在主namenode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。

18、聊聊： 在NameNode HA中，会出现脑裂问题吗？怎么解决脑裂

HA NameNode如何工作？

ZKFailoverController主要职责

1）健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机器宕机，心跳失败，那么zkfc就会标记它处于一个不健康的状态。

2）会话管理：如果NN是健康的，zkfc就会在zookeeper中保持一个打开的会话，如果NameNode同时还是Active状态的，那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode，当这个NN挂掉时，这个znode将会被删除，然后备用的NN，将会得到这把锁，升级为主NN，同时标记状态为Active。

3）当宕机的NN新启动时，它会再次注册zookeper，发现已经有znode锁了，便会自动变为Standby状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持最多配置2个NN。

4）master选举：如上所述，通过在zookeeper中维持一个短暂类型的znode，来实现抢占式的锁机制，从而判断那个NameNode为Active状态

什么是脑裂？

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

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

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

首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能把它转换为 Standby 状态。

如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施，Hadoop 目前主要提供两种隔离措施，通常会选择 sshfence：

sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死；

shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离。

19、聊聊：小文件过多会有什么危害，如何避免

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

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

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

20、聊聊：请说下HDFS的组织架构

架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。下面我们分别介绍这四个组成部分。

1）Client：客户端

（1）切分文件。文件上传 HDFS 的时候，Client 将文件切分成一个一个的 Block，然后进行存储

（2）与 NameNode 交互，获取文件的位置信息

（3）与 DataNode 交互，读取或者写入数据

（4）Client 提供一些命令来管理 HDFS，比如启动关闭 HDFS、访问 HDFS 目录及内容等

2）NameNode：名称节点，也称主节点，存储数据的元数据信息，不存储具体的数据

（1）管理 HDFS 的名称空间

（2）管理数据块（Block）映射信息

（3）配置副本策略

（4）处理客户端读写请求

3）DataNode：数据节点，也称从节点。NameNode 下达命令，DataNode 执行实际的操作

（1）存储实际的数据块

（2）执行数据块的读/写操作

4）Secondary NameNode：并非 NameNode 的热备。当 NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务

（1）辅助 NameNode，分担其工作量

（2）定期合并 Fsimage 和 Edits，并推送给 NameNode

（3）在紧急情况下，可辅助恢复 NameNode

21、聊聊：请说下MR中Map Task的工作机制

简单概述：

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

详细步骤：

读取数据组件 InputFormat (默认 TextInputFormat) 会通过 getSplits 方法对输入目录中的文件进行逻辑切片规划得到 block，有多少个 block就对应启动多少个 MapTask。

将输入文件切分为 block 之后，由 RecordReader 对象 (默认是LineRecordReader) 进行读取，以 \n 作为分隔符, 读取一行数据, 返回 <key，value>， Key 表示每行首字符偏移值，Value 表示这一行文本内容。

读取 block 返回 <key,value>, 进入用户自己继承的 Mapper 类中，执行用户重写的 map 函数，RecordReader 读取一行这里调用一次。

Mapper 逻辑结束之后，将 Mapper 的每条结果通过 context.write 进行collect数据收集。在 collect 中，会先对其进行分区处理，默认使用 HashPartitioner。

接下来，会将数据写入内存，内存中这片区域叫做环形缓冲区(默认100M)，缓冲区的作用是 批量收集 Mapper 结果，减少磁盘 IO 的影响。我们的 Key/Value 对以及 Partition 的结果都会被写入缓冲区。当然，写入之前，Key 与 Value 值都会被序列化成字节数组。

当环形缓冲区的数据达到溢写比列(默认0.8)，也就是80M时，溢写线程启动，需要对这 80MB 空间内的 Key 做排序 (Sort)。排序是 MapReduce 模型默认的行为，这里的排序也是对序列化的字节做的排序。

合并溢写文件，每次溢写会在磁盘上生成一个临时文件 (写之前判断是否有 Combiner)，如果 Mapper 的输出结果真的很大，有多次这样的溢写发生，磁盘上相应的就会有多个临时文件存在。当整个数据处理结束之后开始对磁盘中的临时文件进行 Merge 合并，因为最终的文件只有一个写入磁盘，并且为这个文件提供了一个索引文件，以记录每个reduce对应数据的偏移量。

22、聊聊：请说下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 函数进行处理。

详细步骤：

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

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

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

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

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

23、聊聊：MR中Shuffle阶段的核心步骤

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

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

Collect阶段：将 MapTask 的结果输出到默认大小为 100M 的环形缓冲区，保存的是 key/value，Partition 分区信息等。

Spill阶段：当内存中的数据量达到一定的阀值的时候，就会将数据写入本地磁盘，在将数据写入磁盘之前需要对数据进行一次排序的操作，如果配置了 combiner，还会将有相同分区号和 key 的数据进行排序。

MapTask阶段的Merge：把所有溢出的临时文件进行一次合并操作，以确保一个 MapTask 最终只产生一个中间数据文件。

Copy阶段：ReduceTask 启动 Fetcher 线程到已经完成 MapTask 的节点上复制一份属于自己的数据，这些数据默认会保存在内存的缓冲区中，当内存的缓冲区达到一定的阀值的时候，就会将数据写到磁盘之上。

ReduceTask阶段的Merge：在 ReduceTask 远程复制数据的同时，会在后台开启两个线程对内存到本地的数据文件进行合并操作。

Sort阶段：在对数据进行合并的同时，会进行排序操作，由于 MapTask 阶段已经对数据进行了局部的排序，ReduceTask 只需保证 Copy 的数据的最终整体有效性即可。

Shuffle 中的缓冲区大小会影响到 mapreduce 程序的执行效率，原则上说，缓冲区越大，磁盘io的次数越少，执行速度就越快。

缓冲区的大小可以通过参数调整, 参数：mapreduce.task.io.sort.mb 默认100M

24、聊聊：Shuffle阶段的数据压缩机制了解吗

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

hadoop当中支持的压缩算法：

gzip、bzip2、LZO、LZ4、Snappy，这几种压缩算法综合压缩和解压缩的速率，谷歌的Snappy是最优的，一般都选择Snappy压缩。谷歌出品，必属精品。

25、聊聊： 在写MR时，什么情况下可以使用规约

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

26、聊聊：YARN集群的架构和工作原理

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

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

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

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

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

与RM调度器协商以获得资源，资源以Container表示。

将得到的任务进一步分配给内部的任务。

与NM通信以启动/停止任务。

监控所有的内部任务状态，并在任务运行失败的时候重新为任务申请资源以重启任务。

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

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

27、聊聊：YARN的任务提交流程是怎样的

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

用户向YARN提交一个应用程序，并指定ApplicationMaster程序、启动ApplicationMaster的命令、用户程序。

RM为这个应用程序分配第一个Container，并与之对应的NM通讯，要求它在这个Container中启动应用程序ApplicationMaster。

ApplicationMaster向RM注册，然后拆分为内部各个子任务，为各个内部任务申请资源，并监控这些任务的运行，直到结束。

AM采用轮询的方式向RM申请和领取资源。

RM为AM分配资源，以Container形式返回。

AM申请到资源后，便与之对应的NM通讯，要求NM启动任务。

NodeManager为任务设置好运行环境，将任务启动命令写到一个脚本中，并通过运行这个脚本启动任务。

各个任务向AM汇报自己的状态和进度，以便当任务失败时可以重启任务。

应用程序完成后，ApplicationMaster向ResourceManager注销并关闭自己。

28、聊聊：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调度器时的时间。

Fair Scheduler（公平调度器）：

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

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

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

说在后面：

持续迭代、持续升级 是 尼恩团队的宗旨，

持续迭代、持续升级 也是 《尼恩 大数据 面试宝典》、《尼恩Java面试宝典》的灵魂。

后面会收集更多的大数据真题，同时，遇到大数据的面试难题，可以来尼恩的社区《技术自由圈（原疯狂创客圈）》中交流和求助。

咱们的目标，打造宇宙最牛的 大数据 面试宝典。

技术自由的实现路径 PDF：

实现你的 架构自由：

《吃透8图1模板，人人可以做架构》

《10Wqps评论中台，如何架构？B站是这么做的！！！》

《阿里二面：千万级、亿级数据，如何性能优化？ 教科书级 答案来了》

《峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？》

《100亿级订单怎么调度，来一个大厂的极品方案》

《2个大厂 100亿级 超大流量 红包 架构方案》

… 更多架构文章，正在添加中

实现你的 响应式 自由：

《响应式圣经：10W字，实现Spring响应式编程自由》

这是老版本 《Flux、Mono、Reactor 实战（史上最全）》

实现你的 spring cloud 自由：

《Spring cloud Alibaba 学习圣经》

《分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）》

《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）》

实现你的 linux 自由：

《Linux命令大全：2W多字，一次实现Linux自由》

实现你的 网络 自由：

《TCP协议详解 (史上最全)》

《网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！》

实现你的 分布式锁 自由：

《Redis分布式锁（图解 - 秒懂 - 史上最全）》

《Zookeeper 分布式锁 - 图解 - 秒懂》

实现你的 王者组件 自由：

《队列之王： Disruptor 原理、架构、源码 一文穿透》

《缓存之王：Caffeine 源码、架构、原理（史上最全，10W字 超级长文）》

《缓存之王：Caffeine 的使用（史上最全）》

《Java Agent 探针、字节码增强 ByteBuddy（史上最全）》

实现你的 面试题 自由：

4000页《尼恩Java面试宝典 》 40个专题

尼恩 架构笔记、面试题 的PDF文件更新，请到下面【技术自由圈】取↓↓↓