公司的資料倉庫和離線資料分析是建立在Hadoop + Hive基礎上的，現在的工作主要是資料分析，自然也就跟HQL查詢經常打交道了。剛來公司幾乎完全不懂資料庫知識，神馬結構化查詢語言也只是聽說而已，不過，這沒關係，實際工作一來，學習起來還是很快~~

        年前有一個同事叫幫忙查某個產品的月度留存UV這個資料，當時業務不熟，還去參照了一下別人是怎麼定義留存使用者這個指標的。。。然後根據自己的理解，用下面這種形式(其實剛開始的邏輯寫得比這個還拙計，我不會到處亂說)的指令碼邏輯去查：

SELECT
	t1.產品型別,
	COUNT(DISTINCT (IF(t2.使用者ID IS NULL, NULL, t1.使用者ID))) AS KEEP_UV
FROM
(
	SELECT
		產品型別,
		使用者ID
	FROM 事實表
	WHERE (`DATE` >= 20140201 AND `DATE` <= 20140228)
) t1
LEFT OUTER JOIN
(
	SELECT
		產品型別,
		使用者ID
	FROM 事實表
	WHERE (`DATE` >= 20140101 AND `DATE` <= 20140131)
) t2 ON (t1.產品型別 = t2.產品型別 AND t1.使用者ID = t2.使用者ID)
GROUP BY t1.產品型別
 

       但是，這個事實表本身所包含的欄位很多，資訊量很大，加上時間跨度為2個月，當時就想會不會略慢，結果跑起來果然慢得很，Map或者Reduce的任務經常卡在某個百分點比較久時間。

       看著MapReduce像蝸牛一樣行進著，我才忽然想到在官方Wiki上貌似看到過這種 IN / EXISTS子查詢（準確地說，這裡是非相關子查詢）有一種高效的實現，就是LEFT SEMI JOIN：

       LEFT SEMI JOIN implements the uncorrelated IN/EXISTS subquery semantics in an efficient way.

       於是抱著試一試的心態，馬上修改指令碼，用下面的形式去跑：

SELECT
	產品型別,
	COUNT(DISTINCT t1.使用者ID) AS KEEP_UV
FROM
(
	SELECT
		產品型別,
		使用者ID
	FROM 事實表
	WHERE (`DATE` >= 20140201 AND `DATE` <= 20140228)
) t1
LEFT SEMI JOIN
(
	SELECT
		產品型別,
		使用者ID
	FROM 事實表
	WHERE (`DATE` >= 20140101 AND `DATE` <= 20140131)
) t2 ON (t1.產品型別 = t2.產品型別 AND t1.使用者ID = t2.使用者ID)
GROUP BY 產品型別
 

       果然，第2種指令碼很快就出來結果了，而第1種指令碼還在某個百分點艱難地挪步。。。

       值得注意的是，用了LEFT SEMI JOIN子句以後，右邊的表在JOIN操作以外就不可見了，也就是說，右邊的表只能在對應的ON子句中被引用。
       以上只是直觀的感覺，從定性的層面感受到LEFT SEMI JOIN方式的效能真的是很不錯，不曉得這樣的效果除了來自Hive本身的官方高效實現外，與公司的生產環境有沒有關係。。。
       怎麼樣，是不是想看看Hive這種特有的方式究竟為我們的查詢帶來了多大的時間效能改進？是不是也想看看它在原始碼裡究竟是怎樣的實現？行動起來吧。