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=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进行自动化的优化设置其实是可以很明显地提高作业执行效率的。

案例二(处理小文件):

最近仓库里面新建了一张分区表,数据量大约是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数的一个重要环节

处理的不好 会大大影响任务的执行效率

posted @ 2018-04-19 10:06  wq920  阅读(2102)  评论(0编辑  收藏  举报