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数的一个重要环节

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