測試資料準備1：

echo -e '1\tzhangsan\n2\tlisi\n3\twangwu'>/tmp/join_a.txt
echo -e '1\t30\n2\t29\n4\t21'>/tmp/join_b.txt

beeline -u "jdbc:hive2://127.0.0.1:10000" -n hadoop -p hadoop
use test1;
create table id_name(
id int, 
name string)
row format delimited fields terminated by '\t';
create table id_age(
id int, 
age int)
row format delimited fields terminated by
 
 '\t';
load data local inpath '/tmp/join_a.txt' overwrite into table id_name;
load data local inpath '/tmp/join_b.txt' overwrite into table id_age;

JOIN的幾種SQL：

-- 內連線
select * from id_name join id_age on id_name.id=id_age.id;

-- 外連線
select * from id_name left  join id_age on id_name.id=id_age.id;
select
 
 * from id_name right join id_age on id_name.id=id_age.id;
select * from id_name full  join id_age on id_name.id=id_age.id;

-- 笛卡爾積
select * from id_name cross join id_age;
select * from id_name cross join id_age    on id_name.id=id_age.id;
select * from id_name cross join id_age where id_name.id=id_age.id;
 

-- 笛卡爾積基礎上增加連結條件，其實就是內連線

測試資料準備2：

use test1;
create table emp(
empno int, 
ename string, 
job string, 
mgr int, 
hiredate string, 
sal double, 
comm double, 
deptno int)
row format delimited fields terminated by '\t';
create table dept(
deptno int,
dname  string,
loc    string)
row format delimited fields terminated by '\t';
load data local inpath '/tmp/emp' overwrite into table emp;
load data local inpath '/tmp/dept' overwrite into table dept;

hive的join相關分析：

hive常用的join有兩大類：

• common join/reduce join/shuffle join 一般的join
• mapjoin 優化器優化後的join

hive預設使用的join：

• 當 hive.auto.convert.join = true時，優化器預設將common join轉化成mapjoin
• 當 hive.auto.convert.join = false時，預設使用 common join

測試SQL：

select e.empno, e.ename, e.deptno, d.dname 
  from emp e join dept d on e.deptno=d.deptno;
-- shuffle：將相同的deptno分到一個reduce上去
-- emp表所需列 ：<deptno,(empno,ename)>
-- dept表所需列：<deptno,(dname)>
-- 正常的操作如以上分析，分別掃表取出emp表和dept表對應的列
-- 然後將列deptno相同的資料分配到一個reduce上去，查出資料

該SQL的common join執行計劃解讀：

set hive.auto.convert.join = false;
explain
select e.empno, e.ename, e.deptno, d.dname 
  from emp e join dept d on e.deptno=d.deptno;
-- 設定優化器引數為false，使用explain關鍵字檢視執行計劃

可以看出 common join 執行了兩步，第一步是map+reduce，第二部是展示資料，
第一步中，map操作分別對兩表進行掃描，根據deptno分組，查出需要的列資料，傳遞給reduce，
然後在reduce操作中進行join操作，最終得出結果資料集。

該SQL的mapjoin執行計劃解讀：

set hive.auto.convert.join = true;
explain
select e.empno, e.ename, e.deptno, d.dname 
  from emp e join dept d on e.deptno=d.deptno;

可以看出，mapjoin比common join多了一步，首先啟動了一個本地的Map Reduce作業，讀d表，
然後啟動了一個非本地的Map Reduce作業，是一個真實的Map操作，讀e表，
然後並沒有啟動真實的Reduce操作，而直接在Map端進行了join操作，最後展示資料。
使用優化器將commmon join 優化成mapjoin，省掉了Reduce操作，效率更高。

兩種join的進一步分析：

兩表進行common join，需要對兩表分別啟動一組map作業，將資料根據join的條件進行排序，
經過網路shuffle後傳輸到同一個reduce作業，然後啟動該reduce作業，進行join，然後查出資料。
這中join效能是較差的，因為兩表的資料map之後需要經過shuffle進行網路傳輸。

兩表進行mapjoin，首先啟動一個本地的MR Local Task，會去讀小表（根據表的元資料中的統計資訊確定），將小表的資料讀入之後生成一個HashTable檔案，將該檔案存入hadoop的分散式快取中；
然後啟動一個Map任務，將另外一個表的資料讀入之後和上一步存入到入hadoop的分散式快取中的HashTable檔案進行join操作，查出資料。
這種join是沒有shuffle進行網路傳輸的，是效能比較高的join方法。

從hive執行的日誌分析：

第一個紅框看到：啟動一個本地任務，Dump the side-table for tag 生成了hashtable，Uploaded 1 File to 將該hashtable上傳到了分散式快取中；
第二個紅框看到：number of mappers: 1; number of reducers: 0，即一個map操作，沒有reducer操作，map取得資料之後直接和分散式快取中的hashtable進行join，沒有shuffle操作，執行計劃比較高效。

先處理一張表，生成hashtable放入分散式快取，第二張表一遍map一遍和快取做join，不需要shuffle不需要reduce。

[TOC]