1.jvm重用：详见Hadoop性能调优
2.并行执行
即同时执行hive的多个阶段。hive在执行过程，将一个查询转化成一个或者多个阶段，而这些阶段可能并非完全相互依赖的，也就是说可以并行执行的，这样可能使得整个job的执行时间缩短hive执行开启：set hive.exec.parallel=true;
3.调整Reducer个数
参数1：hive.exec.reducers.bytes.per.reducer=256000000：每个reduce任务处理的数据量
参数2：hive.exec.reducers.max=1009：每个任务最大的reduce数目
计算公式：reducer个数=min(参数2,总输入数据量/参数1)
set mapred.reduce.tasks = N：每个任务默认的reduce数目。典型为0.99*reduce槽数，hive默认为-1，即自动确定reduce数目。
4.调整Map个数
dfs.block.size=268435456 hive.merge.mapfiles=true hive.merge.mapredfiles=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
所以整个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进行自动化的优化设置其实是可以很明显地提高作业执行效率的。