Mapreduce中Mapper个数的确定
在Map阶段读取数据前,FileInputFormat会将输入文件分割成Split。Split的个数决定了Map的个数。 影响Map个数,即Split个数的因素主要有:
1)HDFS中dfs.block.size的值,默认为128M
2)文件的大小
3)文件的个数。FileInputFormat按照文件分割Split,并且只会分割那些大小超过Block块的大小的文件
4)SplitSize的大小。分片是按照SplitSzie的大小进行分割的,一个split的大小在没有设置的情况下,默认等于hdfs block的大小。但应用程序可以通过两个参数来对splitsize进行调节。 Mapper个数的计算如下:
Step1,splitsize=max(minimumsize,min(maximumsize,blocksize))。 如果没有设置minimumsize和maximumsize,splitsize的大小默认等于blocksize
Step2,计算过程可以简化为如下的公式,详细算法可以参照FileInputSplit类中的getSplits方法
total_split
for(file :输入目录中的每个文件){
file_split = 1;
if(file.size>splitsize){
file_split=file_size/splitsize;
}
total_split+=file_split;
}
举例:
a) 假设Input目录下有1个文件file_1,大小为780M,那么Hadoop会将该文件分隔成7个Block块(6个128M和1个12M),从而产生7个Map数
b) 假设Input目录下有3个文件file_1(10M),file_2(20M),file_3(130M),那么则Hadoop会分隔成4个块(10M,20M,128M,2M),从而产生4个Map数。
即:文件大于块大小(128m),那么会拆分,如果小于块大小,则把该文件当成一个块。
一些思考
【1】Map数目越多越好?
不是。如果一个任务有很多小文件(远远小于块大小128M),则每个小文件也会被当做一个块,用一个Map任务来完成,而一个Map任务启动和初始化的时间远远大于逻辑处理的时间,就会造成很大的资源浪费。而且,同时可执行的Map数是受限的。
【2】如果保证每个Map处理接近128M的文件块,就没有任何问题了?
不一定。比如有一个127M的文件,正常会用一个Map去完成,但这个文件只有一个或者两个小字段,却有几千万的记录,如果Map处理的逻辑比较复杂,用一个Map任务去做,会耗费大量时间。
针对上面的上面两个问题,需要采取两种方式来解决:即减少Map数和增加Map数。如何在Map端合并小文件,减少Map数?假设一个SQL任务:Select count(1) from tb_1 where datetime = ‘2012-07-04’;该任务的inputdir目录下共有194个文件,其中大多是小于128M的文件,总大小9G,正常执行会用194个Map任务。通过以下方法来在Map执行前合并小文件,减少Map数:
set mapred

本文详细介绍了如何确定Hive中Map和Reduce任务的数量。Map任务的数量由输入文件的Split个数决定,受HDFS块大小、文件大小和SplitSize影响。Reducer个数可通过公式N=min(参数2,总输入数据量/参数1)计算,并与集群资源和任务性质相关。合理控制Map和Reduce数量能提高任务执行效率。
最低0.47元/天 解锁文章
657

被折叠的 条评论
为什么被折叠?



