【无标题】

Hive 查询优化总结

一、join优化

Join查找操作的基本原则：应该将条目少的表/子查询放在 Join 操作符的左边。原因是在 Join 操作的 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生内存溢出错误的几率。

Join查找操作中如果存在多个join，且所有参与join的表中其参与join的key都相同，则会将所有的join合并到一个mapred程序中。

案例：

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)  在一个mapre程序中执行join```

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2)   在两个mapred程序中执行join

join操作是在where操作之前执行，所以当你在执行join时，where条件并不能起到减少join数据的作用；案例：

SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key) WHERE a.ds=‘2009-07-07’ AND b.ds=‘2009-07-07’

最好修改为：

SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key AND b.ds=‘2009-07-07’ AND a.ds=‘2009-07-07’)

二、group by 优化

数据倾斜聚合优化，设置参数hive.groupby.skewindata = true，默认为false,当选项设定为 true，生成的查询计划会有两个 MR Job。
第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；
第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。

三、合并小文件

文件数目过多，会给 HDFS 带来压力，并且会影响处理效率，可以通过合并 Map 和 Reduce 的结果文件来消除这样的影响：
hive.merge.mapfiles = true是否和并 Map 输出文件，默认为 True
hive.merge.mapredfiles = false是否合并 Reduce 输出文件，默认为 False
hive.merge.size.per.task = 25610001000合并文件的大小

四、Hive实现 in 和 not in

left semi join 实现 in
SELECT a.key, a.val FROM a LEFT SEMI JOIN b on a.key = b.key
Left semi join 的限制：join条件中右边的表只能出现在join条件中

五、排序优化

Order by 实现全局排序，一个reduce实现，效率低
Sort by 实现部分有序，单个reduce输出的结果是有序的，效率高，通常和DISTRIBUTE BY关键字一起使用
CLUSTER BY col1 等价于DISTRIBUTE BY col1 SORT BY col1

六、使用分区

Hive中的每个分区都对应hdfs上的一个目录，分区列也不是表中的一个实际的字段，而是一个或者多个伪列，在表的数据文件中实际上并不保存分区列的信息与数据。
Partition关键字中排在前面的为主分区（只有一个），后面的为副分区

七、Distinct

distinct会被hive翻译成一个全局唯一reduce任务来做去重操作，因而并行度为1。
而group by则会被hive翻译成分组聚合运算，会有多个reduce任务并行处理，每个reduce对收到的一部分数据组，进行每组聚合（去重）