Etl之HiveSql调优(left join where的位置)

hive> desc sight;
OK
area                    string                  None                
city                    string                  None                
country                 string                  None                
county                  string                  None                
id                      string                  None                
name                    string                  None                
region                  string                  None     

景区订单明细表：order_sight，1040W条记录，数据表结构：

hive> desc order_sight;    
OK
create_time             string                  None                
id                      string                  None                
order_id                string                  None                
sight_id                bigint                  None  

 三、分析

3.1 where条件

那么咱们希望看见景区id是9718，日期是2015-10-10的所有订单id，那么sql需要如下书写：

select s.id,o.order_id from sight s left join order_sight o on o.sight_id=s.id where s.id=9718 and o.create_time = ‘2015-10-10‘; 

需要的时间是52秒，如果咱们换一个sql的书写方式：

select s.id,o.order_id from sight s left join (select order_id,sight_id from order_sight where create_time = ‘2015-10-10‘) o on o.sight_id=s.id where s.id=9718；

实用43秒，快了一些。当然咱们并不是仅仅分析说快了20%（我还多次测试，这次的差距最小），而是分析原因！

单从两个sql的写法上看的出来，特别是第二条的红色部分，我将left的条件写到里面了。那么执行的结果随之不一样，第二条的Reduce时间明显小于第一条的Reduce时间。

原因是这两个sql都分解成8个Map任务和1个Reduce任务，如果left的条件写在后面，那么这些关联操作会放在Reduce阶段，1个Reduce操作的时间必然大于8个Map的执行时间，造成执行时间超长。

结论：当使用外关联时，如果将副表的过滤条件写在Where后面，那么就会先全表关联，之后再过滤

Etl之HiveSql调优(left join where的位置)

标签：sel   注意   select   避免   img   int   数据仓库   问题   toolbar