hive之调优

1、简单的查询，就是只是select，不带count,sum,group by这样的，都不走map/reduce，直接读取hdfs文件进行filter过滤，即尽量让fetch task(当开启一个Fetch Task功能，就执行一个简单的查询语句不会生成MapRreduce作业，而是直接使用FetchTask，从hdfs文件系统中进行查询输出数据，从而提高效率)任务不走MapReduce。

2、遵循hive的严格模式，禁止以下3种情况的查询模式

（1）当表为分区表时，where子句后无分区字段和限制字段禁止执行

（2）使用order by子句时，必须使用limit语句，因为order by子句只会产生一个reducer任务

（3）限制笛卡尔乘积的查询，尽量将限制条件放在from语句后面的on后面。因为在关系型数据库执行 from join查询的时候不使用on语句而是使用where语句，关系型数据库中优化器可以高效的将where语句转化成那个on语句，但是hive不会执行此优化。故在hive中join操作时尽量将条件放在on后面。

3、优化HiveQL语句，先过滤等。

4、在mapreduce过程中尽量使用压缩，即在map，shuffle，reducer使用snappy压缩。

5、设计好分区表和外部表，创建外部表尽量指定数据所在的文件夹，而不用load去加载。

6、设置map和reducer的任务个数，默认情况是一个块对应一个map任务，一般来说map任务个数不会去调整，而调整reducer的任务个数。reduce处理的数据量大小进行适当调整体现“分而治之”的思想。

7、JVM重用：一个job可能有多个map和reducer任务，每个任务会开启一个jvm虚拟机，默认情况下一个task对应一个jvm，任务完成就销毁jvm，我们可以设置jvm重用参数，这样一个jvm可以连续运行对个任务。

　　　　　　缺点：开启JVM重用将会一直占用使用到的task插槽，以便进行重用，若某个job中的reduce task执行时间要比其他reduce task消耗时间多的话，那么保留的插槽却空闲，无法被其他的job使用，直到所有task都结束才会释放．

8、推测执行：木桶效应，若一个job有10个mapreduce任务，其中9个任务已经完成，那么application Master会在另外一个空闲的容器中运行最后一个相同的任务，哪个运行的快就使用哪个结果，运行慢的就被终止。

9、对表进行join时，要将大表放在后面，小表放在前面或者使用标记来告诉系统谁是大表or谁是小表

　　SELECT /*streamtable(b)*/ a.key, a.value
　　FROM a JOIN b ON a.key = b.key

10、在map端完成join（shuffle比较浪费时间，如果没有了reduce也就没有了shuffle）

（1）实现方式

　　1、在SQL语句中添加Map join标记

　　　select /*+MapJoin(smallTable)*/smallTable.key, bigTable.value

　　　from smallTable JOIN bigTable ON smallTable.key = bigTable.key

　　会优先将一张小表（默认小于25M，可以需要适当调节）的数据加载进内存中，然后大表的数据通过map端进行读取，然后和内存进行匹配，内存的计算速度很高，这样就在内存端进行了操作，不需要shuffle，不需要reduce

　　2、自动的mapjoin

　　　set hive.auto.convert.join = true;(该参数为true时，Hive自动对左边的表统计量，如果是小表就加入内存，即对小表使用Map join)，其中hive.mapjoin.smalltable.filesize是大小表判断的阈值。