一、前言

公司實用Hadoop構建數據倉庫，期間不可避免的實用HiveSql，在Etl過程中，速度成了避無可避的問題。本人有過幾個數據表關聯跑1個小時的經歷，你可能覺得無所謂，可是多次Etl就要多個小時，非常浪費時間，所以HiveSql優化不可避免。

註：本文只是從sql層面介紹一下日常需要註意的點，不涉及Hadoop、MapReduce等層面，關於Hive的編譯過程，請參考文章：http://tech.meituan.com/hive-sql-to-mapreduce.html

二、準備數據

假設咱們有兩張數據表。

景區表：sight，12W條記錄，數據表結構：

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的位置)