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);
查看执行日志:
number of splits:3
所以,对应的MapTask
线程数量就是3个,Reducer
线程数是1个。