- 压缩
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
set hive.auto.convert.join=true;
解释: hive是否会根据输入文件大小将普通的join转为mapjoin,默认是true
测试:
|