Hadoop3：MapReduce源码解读之Map阶段的CombineFileInputFormat切片机制（4）

本文主要是介绍Hadoop3：MapReduce源码解读之Map阶段的CombineFileInputFormat切片机制（4），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Job那块的断点代码截图省略，直接进入切片逻辑
参考：Hadoop3：MapReduce源码解读之Map阶段的Job任务提交流程（1）

6、CombineFileInputFormat原理解析

类的继承关系
在这里插入图片描述
与TextInputFormat切片机制的区别

框架默认的TextInputFormat切片机制是对任务按文件规划切片，不管文件多小，都会是一个单独的切片，都会交给一个MapTask，这样如果有大量小文件，就会产生大量的MapTask，处理效率极其低下。
CombineTextInputFormat用于小文件过多的场景，它可以将多个小文件从逻辑上规划到一个切片中，这样，多个小文件就可以交给一个MapTask处理。

所以，这个切片机制是针对处理大量小文件的，效率比TextInputFormat更高。

切片过程说明
生成切片过程包括：虚拟存储过程和切片过程二部分。
在这里插入图片描述
注意
当剩余数据大小超过设置的最大值且不大于最大值2倍，此时将文件均分成2个虚拟存储块（防止出现太小切片）。
例如setMaxInputSplitSize值为4M，输入文件大小为8.02M，则先逻辑上分成一个4M。剩余的大小为4.02M，如果按照4M逻辑划分，就会出现0.02M的小的虚拟存储文件，所以将剩余的4.02M文件切分成（2.01M和2.01M）两个文件。

案例

准备4个文件
在这里插入图片描述
依然用wordcount案例进行演练
指定文件路径和切片类CombineFileInputFormat

		// 如果不设置InputFormat，它默认用的是TextInputFormat.classjob.setInputFormatClass(CombineTextInputFormat.class);//虚拟存储切片最大值设置4mCombineTextInputFormat.setMaxInputSplitSize(job, 4194304);