大数据面试题——Hadoop篇
前言
结合南国 不到一年时间 学习大数据的知识梳理，加上2019年春天找实习的经历，在这里南国写博客的同时会参考一些资料 写出大数据内一些高频的面试知识点。
1.Hadoop基础
1.1 通常是集群的最主要瓶颈：磁盘IO
cpu 和内存在大数据集群中都是可以扩充的，磁盘不行。
1.2 Yarn,ClouderaManager可以作为集群的管理，zookeeper不可以。
Zookeeper:是一个开源的分布式应用程序协调服务,基于zookeeper可以实现同步服务，配置维护，命名服务。但它不能作为集群管理，注意区分。
1.3 请列出正常工作的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）执行任务
备注：这一部分南国在之前的博客中有详细描述。
2.HDFS
2.1 HDFS 中的 block 默认保存3份，默认BlockSize是64MB(Hadoop 1.x)/128MB(Hadoop 2.x)。
如果文件快默认大小为64MB，修改为128MB 【增加文件块大小，需要增加磁盘的传输速率】
2.2 Client上传文件过程：Client端将文件切分为Block，依次上传，它只上传数据到一台DataNode，然后由NameNode负责Block复制工作
2.3 DataNode负责HDFS的数据存储。
2.4 关于 SecondaryNameNode 哪项是正确的？（C）
A.它是NameNode的热备
B.它对内存没有要求
C.他的目的使帮助NameNode合并编辑日志，减少NameNode 启动时间
D. SecondaryNameNode应与NameNode 部署到一个节点
2.5 下列哪个程序通常与 NameNode 在一个节点启动？（D）
A.SecondaryNameNode
B.DataNode
C.TaskTracker
D.JobTracker
解析：hadoop的集群是基于master/slave模式，namenode和jobtracker属于master，datanode和tasktracker属于slave，master只有一个，而slave有多个。
SecondaryNameNode内存需求和NameNode在一个数量级上，所以通常secondary NameNode（运行在单独的物理机器上）和 NameNode 运行在不同的机器上。
JobTracker对应于NameNode,TaskTracker对应于DataNode。
DataNode和NameNode是针对数据存放来而言的。JobTracker和TaskTracker是对于MapReduce执行而言的。
mapreduce中几个主要概念，mapreduce 整体上可以分为这么几条执行线索：jobclient，JobTracker与TaskTracker。
1）JobClient会在用户端通过JobClient类将已经配置参数打包成jar文件的应用存储到hdfs，并把路径提交到Jobtracker,然后由JobTracker创建每一个Task（即 MapTask 和 ReduceTask）并将它们分发到各个TaskTracker服务中去执行。
2）JobTracker是一master服务，软件启动之后JobTracker接收Job，负责调度Job的每一个子任务。task运行于TaskTracker上，并监控它们，如果发现有失败的task就重新运行它。一般情况应该把JobTracker 部署在单独的机器上。
3）TaskTracker是运行在多个节点上的slaver服务。TaskTracker主动与JobTracker通信，接收作业，并负责直接执行每一个任务。TaskTracker 都需要运行在HDFS的DataNode上。
2.6 NameNode与SecondaryNameNode 的区别与联系？
区别：
（1）NameNode负责管理整个文件系统的元数据，以及每一个路径（文件）所对应的数据块信息。
（2）SecondaryNameNode主要用于定期合并命名空间镜像和命名空间镜像的编辑日志。
联系：
（1）SecondaryNameNode中保存了一份和namenode一致的镜像文件（fsimage）和编辑日志（edits）。
（2）在主namenode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。
2.7 NameNode HA实现原理(重要！！！)
在Hadoop 1.x版本，HDFS集群的NameNode一直存在单点故障问题：集群只存在一个NameNode节点，它维护了HDFS所有的元数据信息，当该节点所在服务器宕机或者服务不可用，整个HDFS集群都将处于不可用状态，极大限制了HDFS在生产环境的应用场景。直到Hadoop 2.0版本才提出了高可用 (High Availability, HA) 解决方案，并且经过多个版本的迭代更新，已经广泛应用于生产环境。
为什么要Namenode HA？
- NameNode High Availability即高可用，它配置了一堆活动-备用(active-standby) namendoe。当活动namenode失效时，备用namenode就会接管它的任务并开始服务与来自客户端的请求，不会有任何明显中断。
- NameNode 很重要，挂掉会导致存储停止服务，无法进行数据的读写，基于此NameNode的计算（MR，Hive等）也无法完成。
简单概括：在同一个HDFS集群，运行两个互为主备的NameNode节点。一台为主Namenode节点，处于Active状态，一台为备NameNode节点，处于Standby状态。其中只有Active NameNode对外提供读写服务，Standby NameNode会根据Active NameNode的状态变化，在它失效时切换成Active状态，不会有任何明显的中断。
Namenode HA 如何实现，关键技术难题是什么？
1. 如何保持主和备NameNode的状态同步，并让Standby在Active挂掉后迅速提供服务，namenode启动比较耗时，包括加载fsimage和editlog（获取file to block信息），处理所有datanode第一次blockreport（获取block to datanode信息），保持NN的状态同步，需要这两部分信息同步。
2. 脑裂（split-brain），指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。
3. NameNode切换对外透明，主Namenode切换到另外一台机器时，不应该导致正在连接的客户端失败，主要包括Client，Datanode与NameNode的链接。
为了实现这些目标，需要在架构上作如下修改：
这部分内容 更多详情参考：
NameNode HA实现原理
Namenode HA原理分析
2.8 hadoop2.x Federation
单Active NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，NN成为了性能的瓶颈。
为了解决这个问题,Hadoop 2.x提供了HDFS Federation, 示意图如下：
多个NN共用一个集群里的存储资源，每个NN都可以单独对外提供服务每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储。
DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况。
如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录。
好处：
多namespace的方式可以直接减轻单一NameNode的压力。
一个典型的例子就是上面提到的NameNode内存过高问题,我们完全可以将上面部分大的文件目录移到另外一个NameNode上做管理.更重要的一点在于，这些NameNode是共享集群中所有的DataNode的，它们还是在同一个集群内的。
3.MapReduce
3.1 Hadoop中定义的InputFormat，默认的是TextInputFormat.
两个类TextInputFormat和KeyValueInputFormat的区别是什么？
1）相同点：
TextInputformat和KeyValueTextInputFormat都继承了FileInputFormat类，都是每一行作为一个记录；
2）区别：
TextInputformat将每一行在文件中的起始偏移量作为 key，每一行的内容作为value。默认以\n或回车键作为一行记录。
KeyValueTextInputFormat 适合处理输入数据的每一行是两列，并用 tab 分离的形式。
3.2 在一个运行的Hadoop 任务中，什么是InputSplit？
FileInputFormat源码解析(input.getSplits(job))
（1）找到你数据存储的目录。
（2）开始遍历处理（规划切片）目录下的每一个文件
（3）遍历第一个文件ss.txt
* a）获取文件大小fs.sizeOf(ss.txt);
* b）计算切片大小computeSliteSize(Math.max(minSize,Math.min(maxSize,blocksize)))=blocksize=128M
- c）默认情况下，切片大小=blocksize
- d）开始切，形成第1个切片：ss.txt—0:128M 第2个切片ss.txt—128:256M 第3个切片ss.txt—256M:300M（每次切片时，都要判断切完剩下的部分是否大于块的1.1倍，不大于1.1倍就划分一块切片）
- e）将切片信息写到一个切片规划文件中
- f）整个切片的核心过程在getSplit()方法中完成。
- g）数据切片只是在逻辑上对输入数据进行分片，并不会再磁盘上将其切分成分片进行存储。InputSplit只记录了分片的元数据信息，比如起始位置、长度以及所在的节点列表等。
- h）注意：block是HDFS上物理上存储的存储的数据，切片是对数据逻辑上的划分。
(4）提交切片规划文件到yarn上，yarn上的MrAppMaster就可以根据切片规划文件计算开启maptask个数。
3.3 如何决定一个job的map和reduce的数量?
1）map数量
splitSize=max{minSize,min{maxSize,blockSize}}
map数量由处理的数据分成的block数量决定default_num = total_size / split_size;
2）reduce数量
reduce的数量job.setNumReduceTasks(x);x 为reduce的数量。不设置的话默认为 1。
3.4 MapTask(重要！！！)
一个job的map阶段MapTask并行度（个数），由客户端提交job时的切片个数决定。
关于MapTask的工作机制：
（1）Read阶段：Map Task通过用户编写的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）Combine阶段：当所有数据处理完成后，MapTask对所有临时文件进行一次合并，以确保最终只会生成一个数据文件。
当所有数据处理完后，MapTask会将所有临时文件合并成一个大文件，并保存到文件output/file.out中，同时生成相应的索引文件output/file.out.index。
在进行文件合并过程中，MapTask以分区为单位进行合并。对于某个分区，它将采用多轮递归合并的方式。每轮合并io.sort.factor（默认100）个文件，并将产生的文件重新加入待合并列表中，对文件排序后，重复以上过程，直到最终得到一个大文件。
让每个MapTask最终只生成一个数据文件，可避免同时打开大量文件和同时读取大量小文件产生的随机读取带来的开销。
3.5 ReduceTask(重要！！！)
（1）Copy阶段：ReduceTask从各个MapTask上远程拷贝一片数据，并针对某一片数据，如果其大小超过一定阈值，则写到磁盘上，否则直接放到内存中。
（2）Merge阶段：在远程拷贝数据的同时，ReduceTask启动了两个后台线程对内存和磁盘上的文件进行合并，以防止内存使用过多或磁盘上文件过多。
（3）Sort阶段：按照MapReduce语义，用户编写reduce()函数输入数据是按key进行聚集的一组数据。为了将key相同的数据聚在一起，Hadoop采用了基于排序的策略。由于各个MapTask已经实现对自己的处理结果进行了局部排序，因此，ReduceTask只需对所有数据进行一次归并排序即可。
（4）Reduce阶段：reduce()函数将计算结果写到HDFS上。
总结前面两小节对于MapTask和Reduce Task的总结，我们得到整个MR过程详细的过程和排序过程：
(2020.1.10更新)
这其中还有一个问题很有意思，值得研究。
3.7 描述MapReduce有几种排序及排序发生的阶段
1）排序的分类：
- 部分排序：
MapReduce根据输入记录的键对数据集排序。保证输出的每个文件内部排序。 - 全排序：
如何用Hadoop产生一个全局排序的文件？最简单的方法是使用一个分区。但该方法在处理大型文件时效率极低，因为一台机器必须处理所有输出文件，从而完全丧失了MapReduce所提供的并行架构。
替代方案：首先创建一系列排好序的文件；其次，串联这些文件；最后，生成一个全局排序的文件。主要思路是使用一个分区来描述输出的全局排序。例如：可以为待分析文件创建3个分区，在第一分区中，记录的单词首字母a-g，第二分区记录单词首字母h-n, 第三分区记录单词首字母o-z。 - 辅助排序：（GroupingComparator分组）
Mapreduce框架在记录到达reducer之前按键对记录排序，但键所对应的值并没有被排序。甚至在不同的执行轮次中，这些值的排序也不固定，因为它们来自不同的map任务且这些map任务在不同轮次中完成时间各不相同。一般来说，大多数MapReduce程序会避免让reduce函数依赖于值的排序。但是，有时也需要通过特定的方法对键进行排序和分组等以实现对值的排序。 - 二次排序：
在自定义排序过程中，如果compareTo中的判断条件为两个即为二次排序。
2）自定义排序WritableComparable
bean对象实现WritableComparable接口重写compareTo方法，就可以实现排序。
@Override
public int compareTo(FlowBean o) {
// 倒序排列，从大到小
return this.sumFlow > o.getSumFlow() ? -1 : 1;
}
3）排序发生的阶段：
- 一个是在mapTask中 发生在spill后combine前。
- 一个是在reduceTask中 发生在copy后reduce前
3.8 描述MapReduce中combiner的作用是什么，一般使用情景，哪些情况不需要，及和reduce的区别？
1）Combiner的意义就是对每一个maptask的输出进行局部汇总，以减小网络传输量。
2）Combiner能够应用的前提是不能影响最终的业务逻辑，而且，Combiner的输出kv应该跟reducer的输入kv类型要对应起来。
3）Combiner和reducer的区别在于运行的位置。
- Combiner是在每一个maptask所在的节点运行；
- Reducer是接收全局所有Mapper的输出结果。
8. MapReduce如何实现TopN?
这里介绍三种比较常见的实现方法：
- 直接排序,在ReduceTask中进行排序(最简单的方法，核心代码就是Reduce里面的排序代码)
- 利用Tree排序,该方式利用小顶堆和集合重复原理的方式 , 每过来一个数据 , 跟堆顶数据进行比较 , 如果比最小的大 , 则 =踢掉换新的 , 否则直接跳过数据 . 以此对数据进行排序 .
- 利用MepReduce高级API编程,定义分区器和分组比较器.
具体样例实现参考：
MapReduce求TopN的三种方法 , 以电影数据为例
3.9 Hadoop的缓存机制(DistributedCache)
分布式缓存一个最重要的应用就是在进行join操作的时候，如果一个表很大，另一个表很小，我们就可以将这个小表进行广播处理，即每个计算节点上都存一份，然后进行map端的连接操作，这种情况下处理效率大大高于一般的reduce端join，广播处理就运用到了分布式缓存的技术。
DistributedCache将拷贝缓存的文件到Slave节点。在任何Job在节点上执行之前，文件在每个Job中只会被拷贝一次，缓存的归档文件会被在Slave节点中解压缩。将本地文件复制到HDFS中去，接着Client会通过addCacheFile() 和addCacheArchive()方法告诉DistributedCache在HDFS中的位置。当文件存放到文地时，JobClient同样获得DistributedCache来创建符号链接，其形式为文件的URI加fragment标识。当用户需要获得缓存中所有有效文件的列表时，JobConf 的方法 getLocalCacheFiles() 和getLocalArchives()都返回一个指向本地文件路径对象数组。
3.10 Combine和Partition的作用？
【2019.05.26更新如下：】
Combine分为map端和reduce端，作用是把同一个key的键值对合并在一起，他是可以自定义的。combine函数哪一个map函数产生的
partition是分割map各个节点的结果，按照key分别映射给不同的reduce，他也是开发者自定义的。默认情况下，mapreduce是按照HashPartition进行分类的
3.11 MapReduce的输入分片和输入格式
[2020.1.16 更新]
在Mapreduce作业中，一个输入分片就是一个由单个map操作来处理的输入快。每个map操作处理一个输入分片。每个分片被划分成为若干个记录，每条记录就是一个键值对，map一个接一个的处理记录。
InputSplit包含一个以字节为单位的长度和一组存储位置(即一组主机名)。注意：分片不包含数据本身，而是指向数据的引用(reference)。
接下来，我们主要讲讲MapReduce常见的输入类型：
一条路径可以表示一个文件、一个目录。路径是目录时，表示要包含这个目录下的所有的文件，这些文件都能作为作业的输入。
现在我们来讲述Hadoop提供的用于处理文本的不同InputFormat类：
TextInputFormat
TextInputFormat是默认的InputFormat。每条记录是一行输入。键是LongWritable类型，存储该行在整个文件中的字节偏移量。值是这行的内容，不包括任何行终止符(换行符和回车符)，它被打包成为一个Text对象。
注意：键不是行号。一般情况下，很难去的行号，因为文件按字节而不是按行切分为分片。每个分片单独处理。
MapReduce的输出格式
[2020.1.16 更新：]
上一节 我们对于输入格式进行一些描述后，这里我们就输出格式进行一个简单的描述。
默认的输出格式是TextOutputFormat，它把每条记录写为文本行。
4.Yarn
4.1 YARN的调度器总结
（1）先进先出调度器FIFO
它按照到达时间的先后选择被执行的作业。简单易懂，不需要进行集群配置，但是不适合共享集群。因为大的应用会占用集群中的所有资源，每个应用必须等待直到轮到自己运行。在使用FIFO时，小作业会一直被阻塞，直至大作业完成。
（2）容量调度器Capacity Scheduler
支持多个队列，每个队列可配置一定的资源量，每个队列采用FIFO调度策略，为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交的作业所占资源量进行限定。调度时，首先按以下策略选择一个合适队列：计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值，选择一个该比值最小的队列；然后按以下策略选择该队列中一个作业：按照作业优先级和提交时间顺序选择，同时考虑用户资源量限制和内存限制。容量调度器是YARN的默认调度器。
上图中，dev队列进一步被划分为eng和science两个容量相等的队列。由于dev队列的最大容量被设置为75%，因此即使prod队列空闲，dev队列也不会占用全部集群资源。换句话说，prod队列能即刻使用的可用资源比例总是能达到25%。
（3）公平调度器Fair Scheduler
同容量调度器类似，支持多队列多用户，每个队列中的资源量可以配置，同一队列中的作业公平共享队列中所有资源。
实际上，Hadoop的调度器远不止以上三种，最近，出现了很多针对新型应用的YARN调度器。
4.2 MapReduce 2.0的容错机制
在现实世界中，难免遇到用户代码错误、进程崩溃、机器宕机等情况。使用Hadoop的一个好处是它有能力处理这些失败，使你的job能够成功完成。我们需要考虑以下实体的失败：task、application master、node manager 、resource manager。
1.Task Failure
最常见的task 失败是在map或reduce task中的用户代码抛出一个运行时异常。如果发生这种情况，JVM在退出之前将向父application master报告一个错误，错误最终会被写进用户的日志中。application master将task标记为失败，并且释放container，以便其资源可用于其它的task。
对于Streaming task，如果Streaming Process以非零代码退出（即非正常退出），它将被标记为失败。这种行为有stream.non.zero.exit.is.failure属性控制（默认为true）。
另一种失败的情况是JVM突然退出——也许有一个JVM bug导致JVM的退出。在这种情况下，node manager通知application master task进程已经退出，然后application master尝试标记task为失败状态。
2.Application Master Failure
就像MapReduce的task，对于失败的task会尝试几次重新调度，同样在YARN中的应用如果失败了也会重新尝试运行。尝试运行MapReduce application master的最大次数是由mapreduce.am.max-attempts属性控制的，默认值为2。所以如果一个MapReduce application master失败了两次，那么它将不会被再次尝试，MapReduce Job将失败。
3.Node Manager Failure
如果一个node manage节点因中断或运行缓慢而失败，那么它将不会发送心跳到resource manager（或者发送次数较少）。如果resource manage在10分钟内（这个配置可以通过yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms属性设置，以毫秒为单位）没有接收到一个心跳，它会感知到node manager已经停了，并把它冲节点集群中移除。
4.Resource Manager Failure
Resource manager出现故障是比较严重的，因为没有它，job 和 task都不能被启动。默认配置，resource manager是一个单点故障，因为在机器出现故障时，所有的job都会失败，并且不能被恢复。
为了实现高可用（HA），有必要以一种active-standby（活动-备用）配置模式运行一对resource manager。如果活动的resource manager出现故障，备用的resource manager可以很开的接管，并且对客户端来说没有明显的中断现象。
这部分详细内容 参考资料：MapReduce的容错机制
4.3 谈谈你对container的理解？
[2019.05.26更新如下：]
- container作为资源分配和调度的基本单位，其中封装的资源如同内存，cpu，磁盘，网络带宽等。目前yarn仅仅封装内存和cpu
- container由ApplicationMaster向ResourceManager申请的，由ResourceManager中的资源调度异步分配给ApplicationMaster.
- container的运行是由ApplicationMaster向资源所在的NodeManager发起的，container运行时需提供内部执行的任务命令。
Yarn中的container是由ApplicationMaster负责销毁的。container在MapReduce中不可以复用，在Spark on Yarn中可以复用。
未完待续。。。。
以上内容是我平日里学习过程中结合自己的学习笔记以及网上的资料总结而成。如有错误，还请看到的读者指出，谢谢~