原網址：https://blog.csdn.net/liyaohhh/article/details/50697519
hive在實際的應用過程中，大部份分情況都會涉及到不同的表格的連接，
例如在進行兩個table的join的時候，利用MR的思想會消耗大量的內存，磁盤的IO，大幅度的影響性能，因為shuffle真的好令人擔心啊，總之，就是各種問題都是由他產生的。
下面介紹一下涉及hive在join的時候的優化方式。
第一：在map端產生join
mapJoin的主要意思就是，當鏈接的兩個表是一個比較小的表和一個特別大的表的時候，我們把比較小的table直接放到內存中去，然后再對比較大的表格進行map操作。
join就發生在map操作的時候，每當掃描一個大的table中的數據，就要去去查看小表的數據，哪條與之相符，繼而進行連接。
這里的join並不會涉及reduce操作。map端join的優勢就是在於沒有shuffle，真好。在實際的應用中，我們這樣設置：
set hive.auto.convert.join=true;
這樣設置，hive就會自動的識別比較小的表，繼而用mapJoin來實現兩個表的聯合。
看看下面的兩個表格的連接。這里的dept相對來講是比較小的。我們看看會發生什么，如圖所示：
注意看啦，這里的第一句話就是運行本地的map join任務，繼而轉存文件到XXX.hashtable下面，在給這個文件里面上傳一個文件進行map join，之后才運行了MR代碼去運行計數任務。
說白了，在本質上map join根本就沒有運行MR進程，僅僅是在內存就進行了兩個表的聯合。具體運行如下圖：
第二：common join
common join也叫做shuffle join，reduce join操作。這種情況下生再兩個table的大小相當，但是又不是很大的情況下使用的。
具體流程就是在map端進行數據的切分，一個block對應一個map操作，然后進行shuffle操作，把對應的block shuffle到reduce端去，再逐個進行聯合，
這里優勢會涉及到數據的傾斜，大幅度的影響性能有可能會運行speculation，
這塊兒在后續的數據傾斜會講到。因為平常我們用到的數據量小，所以這里就不具體演示了。
第三：SMBJoin
smb是sort merge bucket操作，首先進行排序，繼而合並，然后放到所對應的bucket中去，bucket是hive中和分區表類似的技術，就是按照key進行hash，相同的hash值都放到相同的buck中去。在進行兩個表聯合的時候。我們首先進行分桶，在join會大幅度的對性能進行優化。也就是說，在進行聯合的時候，是table1中的一小部分和table1中的一小部分進行聯合，table聯合都是等值連接，相同的key都放到了同一個bucket中去了，那么在聯合的時候就會大幅度的減小無關項的掃描。
具體的看看一個例子：
set hive.auto.convert.sortmerge.join=true;
set hive.optimize.bucketmapjoin = true;
set hive.optimize.bucketmapjoin.sortedmerge = true;
set hive.auto.convert.sortmerge.join.noconditionaltask=true;
create table emp_info_bucket(ename string,deptno int)
partitioned by (empno string)
clustered by(deptno) into 4 buckets;
insert overwrite table emp_info_bucket
partition (empno=7369)
select ename ,deptno from emp
create table dept_info_bucket(deptno string,dname string,loc string)
clustered by (deptno) into 4 buckets;
insert overwrite table dept_info_bucket
select * from dept;
select * from emp_info_bucket emp join dept_info_bucket dept
on(emp.deptno==dept.deptno);//正常的情況下，應該是啟動smbjoin的但是這里的數據量太小啦，還是啟動了mapjoin