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
set hive.auto.convert.join=true;
解释: hive是否会根据输入文件大小将普通的join转为mapjoin，默认是true
测试：
|
|
Q22
|
Q23
|
Q24
|
|
True
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
False
|
9m44.347s
|
45m1.006s
|
5m23.501s
|
b.
set hive.auto.convert.join.noconditionaltask = true; set hive.auto.convert.join.noconditionaltask.size = 10000000;
解释：hive.auto.convert.join.noconditionaltask.size表明可以转化为MapJoin的表的大小总合。例如有A、B两个表，他们的大小都小于该属性值，那么他们都会都会分别被转化为MapJoin，如果两个表大小总和加起来也小于该属性值，那么这两个表会被合并为一个MapJoin。
测试：
1.
set hive.auto.convert.join=false;
set hive.auto.convert.join.noconditionaltask = true;
|
Q22
|
Q23
|
Q24
|
|
9m22.254s
|
44m56.032s
|
5m26.398s
|
set hive.auto.convert.join=True;
set hive.auto.convert.join.noconditionaltask=false;
|
Q22
|
Q23
|
Q24
|
|
9m5.161s
|
18m6.333s |
4m45.650s
|
set hive.auto.convert.join.noconditionaltask=True;
set hive.auto.convert.join.noconditionaltask.size=10000;
结论：
结论：
出错
结论：
性能未见明显提升
结论：
性能显著下降
|
|
Q22
|
Q23
|
Q24
|
|
10000 (10K)
|
9m17.021s
|
16m8.071s
|
4m46.207s
|
|
10000000 (10M Default)
|
2m11.891s
|
13m38.050s
|
4m33.742s
|
|
100000000 （100M）
|
1m34.005s
|
10m43.252s
|
4m39.885s
|
|
1000000000 (1G)
|
1m30.704s
|
10m49.992s
|
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at org.apache.log4j.spi.LoggingEvent.
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:229)
at org.apache.hadoop.hive.ql.exec.mr.MapredLocalTask.executeInProcess(MapredLocalTask.java:349)
at org.apache.hadoop.hive.ql.exec.mr.ExecDriver.main(ExecDriver.java:744)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.hadoop.util.RunJar.main(RunJar.java:212)
Execution failed with exit status: 1
Obtaining error information
Task failed!
|
|
1000000000 (1G)
export HADOOP_CLIENT_OPTS="-Xmx2g" |
1m35.893s
|
10m45.741s
|
10m26.837s
|
1）
hive.auto.convert.join会覆盖hive.auto.convert.join.noconditionaltask
2） 第二个测试说明需要将两个都设为True
2） 第二个测试说明需要将两个都设为True
3）
hive.auto.convert.join.noconditionaltask.size应该设置的较大一点
4 ) Job 数目变少了
4 ) Job 数目变少了
set hive.mapjoin.localtask.max.memory.usage=0.90;
解释：该属性值表示本地任务将key/value保存在内存中的hash table中需要占用多少内存，如果Local任务的内存使用比这个数值大，任务则会终止，这意味着小的hive表中的数据由于太多了而不能保存在内存中。默认值是0.9.
结论：
该属性对性能没有多少影响
set hive.optimize.mapjoin.mapreduce=true;
解释：该属性决定一个Map-only任务是否会被合并到后续的Map-reduce任务中。但是，HIVE-4827对此做了改进，它不管该属性是True还是False，都会将Map-only任务合并到后续的map-reduce任务中，因此这个属性对性能影响不大。
测试：
|
|
Q22
|
Q23
|
Q24
|
|
Undefined
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
True
|
Query returned non-zero code: 1, cause: hive configuration hive.optimize.mapjoin.mapreduce does not exists.
|
|
|
set hive.mapred.local.mem=1024;
解释：本地模式下，mapper和reducer的内存，默认为0
测试：
结论：
性能未见明显提升
|
|
Q22
|
Q23
|
Q24
|
|
0
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
1024
|
2m11.625s
|
13m41.085s
|
4m39.853s
|
- SMB Map Join
set hive.auto.convert.sortmerge.join=true;
set hive.auto.convert.sortmerge.join.noconditionaltask=true; //此属性不存在
set hive.optimize.bucketmapjoin = true;
set hive.optimize.bucketmapjoin.sortedmerge = true;
解释：
Sort-Merge-Bucket (SMB) joins可以被转化为SMB Map Join。这种join归结于将已排好序的表进行合并，使得该操作比传统的map join更加快速。但是如果表是划分表，速度会慢上一些，因为每一个mapper都需要获取一个划分的一小块，这些小块具有一个单一的key。
测试：
|
|
Q22
|
Q23
|
Q24
|
|
Origin
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
After
|
2m12.891s
|
13m50.629s
|
4m39.853s
|
- Skewjoin
hive.optimize.skewjoin.compiletime=false
测试：
hive.groupby.skewindata=false
|
|
Q22
|
Q23
|
Q24
|
|
Origin
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
After
|
FAILED: ParseException line 2:4 missing KW_ROLE at 'hive' near 'hive'
line 2:8 missing EOF at '.' near 'hive'
|
|
|
hive.groupby.skewindata=false
解释：优化group by子句是否在数据中有偏差
测试：
|
|
Q22
|
Q23
|
Q24
|
|
False
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
True
|
2m48.965s
|
17m2.289s
|
5m59.542s
|
- 并行
hive.exec.parallel.thread.number=8
解释：是否并行的执行job以及并行执行job的最大数量
结论：
Q23/Q24性能显著提升，Q22未见明显提升
测试：
|
|
Q22
|
Q23
|
Q24
|
|
False
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
True
|
2m16.959s
|
9m32.682s
|
3m12.682s
|
- 其他
hive.optimize.ppd=true
解释：是否enable预测pushdown，以及是否将预测pushdown到存储器。
测试：
|
|
Q22
|
Q23
|
Q24
|
|
False
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
True
|
2m13.427s
|
14m7.106s
|
4m50.376s
|
hive.optimize.index.filter=false
解释：是否自动使用索引
测试：
|
|
Q22
|
Q23
|
Q24
|
|
False
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
True
|
2m15.132s
|
14m10.505s
|
4m49.860s
|
hive.mapjoin.smalltable.filesize=5000000
解释：小表文件大小的阈值，如果表大小小于该阈值，则会将普通join转化为map join。
测试：
|
|
Q22
|
Q23
|
Q24
|
|
1M
|
2m17.173s
|
14m11.657s
|
4m57.931s
|
|
5M
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
10M
|
2m15.576s
|
14m20.439s
|
5m0.655s
|
- 综合性能提升配置：
set mapred.max.split.size=8388608;
set hive.auto.convert.join=True;
set hive.auto.convert.join.noconditionaltask=
True
;
set hive.auto.convert.join.noconditionaltask.size=100000000 ;
set hive.groupby.skewindata=
false
set hive.exec.parallel=
True
set hive.exec.parallel.thread.number=8
|
|
Q22
|
Q23
|
Q24
|
|
Origin
|
2m9.787s
|
14m19.011s |
4m41.635s
|
|
After
|
1m20.856s (37.7% up) |
7m22.865s (48.4% up)
|
3m42.101s (21.1 % up)
|
1T Data:
|
|
Q22
|
Q23
|
Q24
|
|
Origin
|
20m8.207s
|
24m50.490s |
12m47.515s
|
hive.auto.convert.join.noconditionaltask.size=100000000 ;
|
|
Q22
|
Q23
|
Q24
|
|
8388608 (8MB)
|
10m57.554s
|
40+m
|
(
skip
)
|
|
16777216 (16MB)
|
7m27.275s
|
40+m
|
(skip)
|
33554432 (32MB)
|
6m9.236s
|
36m27.416s
|
(skip)
|
|
67108864 (64MB default)
|
5m36.872s
|
31m55.655s
|
远大于12min
|
|
134217728 (128MB)
|
4m49.397s
|
29m44.575s
|
20m17.109s
|
|
268435456 (256MB)
|
5m43.634
|
skip
|
skip |
|
|
Q22
|
Q23
|
Q24
|
|
10M（default）
|
40min+
|
|
|
|
100M
|
4m49.397s |
29m44.575s |
20m17.109s
|
|
500M
|
4m57.060s
|
29min左右
|
同上
|
| 1G (export HADOOP_CLIENT_OPTS="-Xmx2g") |
4m56.741s
|
29min左右
|
同上
|
1T Data配置：
set mapred.max.split.size=134217728 ;
set hive.auto.convert.join=True;
set hive.auto.convert.join.noconditionaltask=
True
;
set hive.auto.convert.join.noconditionaltask.size=100000000 ;
set hive.groupby.skewindata=
false
set hive.exec.parallel=
True
set hive.exec.parallel.thread.number=8
ps: 集群越来越慢，在最初的配置下rerun跟上面的配置进行对比：
|
|
Q22
|
Q23
|
Q24
|
|
Origin
|
44m56.835s
|
45m18.217s
|
34m43.947s
|
|
After
|
4m49.397s |
29m44.575s
|
20m17.109s
|
Q22在此配置下有接近10/11性能提升
重启集群之后，rerun：
|
|
Q22
|
Q23
|
Q24
|
|
Origin
|
23m7.372s
|
26m49.460s
|
15m57.590s
|
|
After
|
2m31.808 (89% up) |
18m18.278s (31.8% up)
|
12m55.900s (19.0% up)
|