Hadoop1的一些配置项

原创

Daisy8867 2014-09-17 17:16:08 博主文章分类：MR（Hadoop） ©著作权

©著作权归作者所有：来自51CTO博客作者Daisy8867的原创作品，请联系作者获取转载授权，否则将追究法律责任

mapred.min.split.size

意思和字面上的一样，折腾了半天，发现发起任务的机子上，而非只是主机需要配置该项。。

mapred.map.tasks

job的总map任务数，本来以为总文件数/实际的SplitSize就可以了，不太明白还要这项有什么用。。不过下面这个例子应该可以说明些问题：

我所在公司所使用的生产Hive环境的几个参数配置如下：
dfs.block.size=268435456
hive.merge.mapredfiles=true
hive.merge.mapfiles=true
hive.merge.size.per.task=256000000
mapred.map.tasks=2

因为合并小文件默认为true，而dfs.block.size与hive.merge.size.per.task的搭配使得合并后的绝大部分文件都在300MB左右。

CASE 1：

现在我们假设有3个300MB大小的文件，那么goalsize = min(900MB/2,256MB) = 256MB (具体如何计算map数请参见http://blog.sina.com.cn/s/blog_6ff05a2c010178qd.html)
所以整个JOB会有6个map，其中3个map分别处理256MB的数据，还有3个map分别处理44MB的数据。
这时候木桶效应就来了，整个JOB的map阶段的执行时间不是看最短的1个map的执行时间，而是看最长的1个map的执行时间。所以，虽然有3个map分别只处理44MB的数据，可以很快跑完，但它们还是要等待另外3个处理256MB的map。显然，处理256MB的3个map拖了整个JOB的后腿。

CASE 2：

如果我们把mapred.map.tasks设置成6，再来看一下有什么变化：
goalsize = min(900MB/6,256MB) = 150MB
整个JOB同样会分配6个map来处理，每个map处理150MB的数据，非常均匀，谁都不会拖后腿，最合理地分配了资源，执行时间大约为CASE 1的59%(150/256)

案例分析：

虽然mapred.map.tasks从2调整到了6，但是CASE 2并没有比CASE 1多用map资源，同样都是使用6个map。而CASE 2的执行时间约为CASE 1执行时间的59%。
从这个案例可以看出，对mapred.map.tasks进行自动化的优化设置其实是可以很明显地提高作业执行效率的。