Hive Setting调优

• 压缩

a. 

set hive.exec.compress.intermediate=true;

set mapred.map.output.compression.codec=org.apache.hadoop.io.compress.SnappyCodec;

解释：如果集群具有很好的CPU性能，但是网络带宽有限，这两个属性可以加速中间结果的交换。（如果集群具有很高的网络io延迟，那么这个选项应该被打开）

测试：

	Q22	Q23	Q24
未压缩	2m9.787s	14m19.011s	4m41.635s
压缩	2m22.371s	13m57.379s	4m43.945s

结论：性能未见明显提升

b.

set hive.exec.compress.output=false;

set mapred.output.compression.codec=org.apache.hadoop.io.compress.DefaultCodec;

解释：默认是使得创建的结果表是否进行压缩，关系到可读性

	Q22	Q23	Q24
未压缩	2m9.787s	14m19.011s	4m41.635s
压缩	2m14.084s	13m48.921s	4m40.755s

结论:  性能未见明显提升

c.

set hive.default.fileformat=TextFile;

解释：默认文件类型，未测试，应该影响不大。

• Mapper settings

a.

set mapred.max.split.size=67108864;

set mapred.min.split.size=1;

解释：一个hive表包含的物理文件的数量与hive预测启动多少mapper数量无关，因为hive使用HiveCombineInputFormat来合并文件。上面两个参数是最能影响hive预测生成的mapper数量的，降低这些值会导致过多的map task，太高会导致过少的map task，系统利用率不高。两个极端都会影响性能。对于小数据集（1-100G），128M可能是个好的值。作为预测的话，使用中等表的大小除以想要利用的集群的map task数量。

10G Data：

	Q22	Q23	Q24
8388608 (8MB)	1m40.767s	9m54.701s	4m54.342s
16777216 (16MB)	1m44.801s	10m45.015s	4m41.974s
33554432 (32MB)	2m0.222s	12m43.198s	4m36.464s
67108864 (64MB)	2m9.787s	14m19.011s	4m41.635s
134217728 (128MB)	2m51.450s	16m3.758s	4m43.410s

结论： 10G Data, Q22/Q23 随着mapred.max.split.size的减小而性能提升，Q24无明显性能提升

• Reducer Settings

a.

set hive.exec.reducers.bytes.per.reducer=256000000;

解释：每个reducer处理的数据大小，如果input size是10G， 设置为1G，那么就会启动10个reducer

10G Data：

	Q22	Q23	Q24
128000000	2m7.526s	13m44.007s	4m42.296s
256000000	2m9.787s	14m19.011s	4m41.635s
512000000	2m7.969s	13m45.184s	4m39.975s

结论： 性能未见明显提升

b.

set hive.exec.reducers.max=99999;

解释：可以使用的最大的reducer的数量，如果配置的是负值，hive将会使用999作为可以使用的最大的reducer数量。

结论： 从日志看，reducer数量远小于999，因此配置这个对性能影响应该不会太大。

• join

a.
set hive.auto.convert.join=true;

解释: hive是否会根据输入文件大小将普通的join转为mapjoin，默认是true

测试：

Q22