hive 处理小文件,减少map数
1、hive.merge.mapfiles,True时会合并map输出。
2、hive.merge.mapredfiles,True时会合并reduce输出。
3、hive.merge.size.per.task,合并操作后的单个文件大小。
4、hive.merge.size.smallfiles.avgsize,当输出文件平均大小小于设定值时,启动合并操作。这一设定只有当hive.merge.mapfiles或hive.merge.mapredfiles设定为true时,才会对相应的操作有效。
5、mapred.reduce.tasks=30; 设置Reduce Task个数
6、hive.exec.compress.output=’false’; 设置数据不作压缩,要是压缩了我们拿出来的文件就只能通过HIVE-JDBC来解析
7、mapred.map.tasks=1200;
8、hive.optimize.skewjoin=true;这个是给join优化的 0.6官方版本好像有个bug悲哀啊
9、hive.groupby.skewindata=true;这个是给groupby优化的
优化案例一:
使用的生产Hive环境的几个参数配置如下:
dfs.block.size=268435456hive.merge.mapredfiles=truehive.merge.mapfiles=truehive.merge.size.per.task=256000000mapred.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进行自动化的优化设置其实是可以很明显地提高作业执行效率的。
案例二(处理小文件):
最近仓库里面新建了一张分区表,数据量大约是12亿行,分区比较多,从2008年7月开始 一天一个分区。
配置了一个任务
对这个表进行group by 的时候 发现启动了2800多个maps .
执行的时间也高大10分钟。
然后我在hdfs文件里面看到 这个表的每个分区里面都有20多个小文件,每个文件都不大 300KB--1MB
之前的hive的参数:
hive.merge.mapfiles=true
hive.merge.mapredfiles=false
hive.merge.rcfile.block.level=true
hive.merge.size.per.task=256000000
hive.merge.smallfiles.avgsize=16000000
hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat
mapred.max.split.size=256000000
mapred.min.split.size=1
mapred.min.split.size.per.node=1
mapred.min.split.size.per.rack=1
hive.merge.mapredfiles 这个指的是 在Map-Reduce的任务结束时合并小文件
解决办法:
1.修改参数hive.merge.mapredfiles=true
2.通过map_reduece的办法生成一张新的表 此时生成的文件变成了每个分区一个文件
再次执行group by 发现效率得到了大大的提升。
小结:
正确处理hive小文件 是 控制map数的一个重要环节
处理的不好 会大大影响任务的执行效率