Hive的多种JOIN优化

案例一：

select
	a.id,a.number,b.number,c.number
from table_tmp a 
join table_tmp b on a.id = b.id 
join table_tmp c on a.id = c.id
where a.business = 'A'
and b.business = 'B'
and c.business = 'C'

如上例中，Hive会对每对join连接对象启动一个MaoReduce任务。首先启动一个MapReduce job对表a和表b进行连接操作，然后再启动一个MapReduce job将第一个MapReudce job的输出和表c进行连接操作。

这里可能有的同学就提出疑问了？为什么不是表b和表c先进行连接操作呢？

因为Hive总是按照从左到右的顺序执行的。

补充：前边的例子中，每个on子句都用到了a.id作为其中一个join连接键。这种情况下，Hive中有个优化：当对3个表或者更多个表进行join连接时，如果每个on子句都使用相同的连接键的话，那么只会产生一个MapReduce job。

案例二（JOIN优化）：

select
	a.id,a.number,b.number
from big_table_tmp a 
join small_table_tmp b on a.id = b.id 

表a为大表，表b为小表，我们错误的将小表，放在了后边。

优化：

应该交换下表a和表b的位置，如下：

select
	a.id,a.number,b.number
from small_table_tmp a 
join big_table_tmp b on a.id = b.id 

这样在查询中最后一个表为最大的那个表，在对每行记录进行操作时，它会尝试将其他表缓存起来，然后扫描最后那个表进行计算。因此，我们在编写SQL时需保证查询中表的大小从左到右是依次增加的。同时Hive也提供了一个“标记”机制来显式的告知查询优化器哪张表是大表，使用如下：

select /* STREAMTABLE(a)*/
	a.id,a.number,b.number
from big_table_tmp a 
join small_table_tmp b on a.id = b.id 

这里，Hive通过标记，会将表a 作为驱动表，即使其在查询中不是位于最后面的。

案例三（map-side JOIN）: 

 如果所有表中只有一张表是小表，那么可以在最大的表通过mapper的时候将小表完全放到内存中。Hive可以在map端执行连接的过程我们称之为map-side JOIN。这是因为Hive可以和内存中的小表进行逐一匹配，从而省略掉常规连接操作所需要的reduce过程。即使对于很小的数据集，这个优化也明显地要快于常规的连接操作，这样不仅减少了reduce过程，而且有时还可以同时减少map过程的执行步骤。

select /* +MAPJOIN(b)*/
	a.id,a.number,b.number
from big_table_tmp a 
join small_table_tmp b on a.id = b.id 

注意：从Hive v0.7开始，废弃了这种标记的方式，不过如果增加这个标记也是有效的。如果不增加这个标记，用户需要设置属性 hive.auto.convert.join=true,这样Hive才会在必要的时候启动这个优化，默认情况下为false。

set hive.auto.convert.join=true;
select
	a.id,a.number,b.number
from big_table_tmp a 
join small_table_tmp b on a.id = b.id 

 同时需要注意的是，用户也可以配置能够使用这个优化的小表的大小，默认值如下：

hive.mapjoin.smalltable.filesize=25000000

如果用户期望Hive在必要的时候自动启动这个优化的话，也可以将这个（或其他优化配置）设置在${HIVE_HOME}/bin目录下有个.hiverc文件中。