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

csdn推荐

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.class
		job.setInputFormatClass(CombineTextInputFormat.class);
		//虚拟存储切片最大值设置4m
		CombineTextInputFormat.setMaxInputSplitSize(job, 4194304);

查看执行日志：

number of splits:3

所以，对应的MapTask线程数量就是3个，Reducer线程数是1个。

文章来源:https://blog.csdn.net/Brave_heart4pzj/article/details/139493060