Hive中就是把Map，Reduce的Join拿過來，通過SQL來表示。
參考鏈接：https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Joins
Common/Shuffle/Reduce Join
Reduce Join在Hive中也叫Common Join或Shuffle Join
如果兩邊數據量都很大，它會進行把相同key的value合在一起，正好符合我們在sql中的join，然後再去組合，如圖所示。
Map Join
- 1） 大小表連接：
-
如果一張表的數據很大，另外一張表很少(<1000行)，那麼我們可以將數據量少的那張表放到內存裏面，在map端做join。
Hive支持Map Join，用法如下
select /*+ MAPJOIN(time_dim) */ count(1) from
store_sales join time_dim on (ss_sold_time_sk = t_time_sk)
- 2） 需要做不等值join操作（a.x < b.y 或者 a.x like b.y等）
-
這種操作如果直接使用join的話語法不支持不等於操作，hive語法解析會直接拋出錯誤
如果把不等於寫到where裏會造成笛卡爾積，數據異常增大，速度會很慢。甚至會任務無法跑成功~
根據mapjoin的計算原理，MapJoin會把小表全部讀入內存中，在map階段直接拿另外一個表的數據和內存中表數據做匹配。這種情況下即使笛卡爾積也不會對任務運行速度造成太大的效率影響。
而且hive的where條件本身就是在map階段進行的操作，所以在where裏寫入不等值比對的話，也不會造成額外負擔。
select /*+ MAPJOIN(a) */
a.start_level, b.*
from dim_level a
join (select * from test) b
where b.xx>=a.start_level and b.xx<end_level;
3） MAPJOIN 結合 UNIONALL
原始sql：
select a.*,coalesce(c.categoryid,’NA’) as app_category
from (select * from t_aa_pvid_ctr_hour_js_mes1
) a
left outer join
(select * fromt_qd_cmfu_book_info_mes
) c
on a.app_id=c.book_id;
速度很慢，老辦法，先查下數據分佈:
select *
from
(selectapp_id,count(1) cnt
fromt_aa_pvid_ctr_hour_js_mes1
group by app_id) t
order by cnt DESC
limit 50;
數據分佈如下：
NA 617370129
2 118293314
1 40673814
d 20151236
b 1846306
s 1124246
5 675240
8 642231
6 611104
t 596973
4 579473
3 489516
7 475999
9 373395
107580 10508
我們可以看到除了NA是有問題的異常值，還有appid=1~9的數據也很多，而這些數據是可以關聯到的，所以這裏不能簡單的隨機函數了。而t_qd_cmfu_book_info_mes這張app庫表，又有幾百萬數據，太大以致不能放入內存使用mapjoin。
解決方：首先將appid=NA和1到9的數據存入一組，並使用mapjoin與維表（維表也限定appid=1~9，這樣內存就放得下了）關聯，而除此之外的數據存入另一組，使用普通的join，最後使用union all 放到一起。
select a.*,coalesce(c.categoryid,’NA’) as app_category
from --if app_id isnot number value or <=9,then not join
(select * fromt_aa_pvid_ctr_hour_js_mes1
where cast(app_id asint)>9
) a
left outer join
(select * fromt_qd_cmfu_book_info_mes
where cast(book_id asint)>9) c
on a.app_id=c.book_id
union all
select /*+ MAPJOIN(c)*/
a.*,coalesce(c.categoryid,’NA’) as app_category
from –if app_id<=9,use map join
(select * fromt_aa_pvid_ctr_hour_js_mes1
where coalesce(cast(app_id as int),-999)<=9) a
left outer join
(select * fromt_qd_cmfu_book_info_mes
where cast(book_id asint)<=9) c
--if app_id is notnumber value,then not join
on a.app_id=c.book_id
- 設置：
-
當然也可以讓hive自動識別，把join變成合適的Map Join如下所示
注：當設置爲true的時候，hive會自動獲取兩張表的數據，判定哪個是小表，然後放在內存中
set hive.auto.convert.join=true;
select count(*) from store_sales join time_dim on (ss_sold_time_sk = t_time_sk)
SMB(Sort-Merge-Buket) Join
- 場景：
-
大表對小表應該使用MapJoin，但是如果是大表對大表，如果進行shuffle，那就要人命了啊，第一個慢不用說，第二個容易出異常，既然是兩個表進行join，肯定有相同的字段吧。
-
tb_a - 5億（按排序分成五份，每份1億放在指定的數值範圍內,類似於分區表）
a_id
100001 ~ 110000 - bucket-01-a -1億
110001 ~ 120000
120001 ~ 130000
130001 ~ 140000
140001 ~ 150000 -
tb_b - 5億（同上，同一個桶只能和對應的桶內數據做join）
b_id
100001 ~ 110000 - bucket-01-b -1億
110001 ~ 120000
120001 ~ 130000
130001 ~ 140000
140001 ~ 150000 -
注：實際生產環境中，一天的數據可能有50G（舉例子可以把數據弄大點，比如說10億分成1000個bucket）。
- 原理：
-
在運行SMB Join的時候會重新創建兩張表，當然這是在後臺默認做的，不需要用戶主動去創建，如下所示：
-
![SMB Join]()
設置（默認是false）：
set hive.auto.convert.sortmerge.join=true
set hive.optimize.bucketmapjoin=true;
set hive.optimize.bucketmapjoin.sortedmerge=true;
- 總結：
-
其實在寫程序的時候，我們就可以知道哪些是大表哪些是小表，注意調優。
-
轉自：http://www.cnblogs.com/raymoc/p/5323824.html