經(jīng)?？吹揭恍〩ive優(yōu)化的建議中說當(dāng)小表與大表做關(guān)聯(lián)時，把小表寫在前面，這樣可以使Hive的關(guān)聯(lián)速度更快，提到的原因都是說因為小表可以先放到內(nèi)存中，然后大表的每條記錄再去內(nèi)存中檢測，最終完成關(guān)聯(lián)查詢。這樣的原因看似合理，但是仔細(xì)推敲，又站不住腳跟。

多小的表算小表？如果所謂的小表在內(nèi)存中放不下怎么辦？我用2個只有幾條記錄的表做關(guān)聯(lián)查詢，這應(yīng)該算是小表了，在查看reduce的執(zhí)行日志時依然是有寫磁盤的操作的。實際上reduce在接收全部map的輸出后一定會有一個排序所有鍵值對并合并寫入磁盤文件的操作。寫入磁盤（spill）有可能是多次的，因此有可能會生成多個臨時文件，但是最終都要合并成一個文件，即最終每一個reduce都只處理一個文件。

我做了一個實驗，用1條記錄的表和3億多條記錄的表做join，無論小表是放在join的前面還是join的后面，執(zhí)行的時間幾乎都是相同的。再去看reduce的執(zhí)行日志，1條記錄的表在join前或者join后兩次查詢的reduce日志幾乎也是一摸一樣的。如果按照上面的說法把join左側(cè)的表放內(nèi)存等待join右側(cè)的表到內(nèi)存中去檢測，那么當(dāng)3億多條記錄的表放在join左側(cè)時，內(nèi)存肯定是無法容下這么多記錄的，勢必要進(jìn)行寫磁盤的操作，那它的執(zhí)行時間應(yīng)該會比小表在join前時長很多才對，但事實并不是這樣，也就說明了上面說到的原因并不合理。

事實上“把小表放在前面做關(guān)聯(lián)可以提高效率”這種說法是錯誤的。正確的說法應(yīng)該是“把重復(fù)關(guān)聯(lián)鍵少的表放在join前面做關(guān)聯(lián)可以提高join的效率。”

分析一下Hive對于兩表關(guān)聯(lián)在底層是如何實現(xiàn)的。因為不論多復(fù)雜的Hive查詢，最終都要轉(zhuǎn)化成mapreduce的JOB去執(zhí)行，因此Hive對于關(guān)聯(lián)的實現(xiàn)應(yīng)該和mapreduce對于關(guān)聯(lián)的實現(xiàn)類似。而mapreduce對于關(guān)聯(lián)的實現(xiàn)，簡單來說，是把關(guān)聯(lián)鍵和標(biāo)記是在join左邊還是右邊的標(biāo)識位作為組合鍵(key)，把一條記錄以及標(biāo)記是在join左邊還是右邊的標(biāo)識位組合起來作為值(value)。在reduce的shuffle階段，按照組合鍵的關(guān)聯(lián)鍵進(jìn)行主排序，當(dāng)關(guān)聯(lián)鍵相同時，再按照標(biāo)識位進(jìn)行輔助排序。而在分區(qū)段時，只用關(guān)聯(lián)鍵中的關(guān)聯(lián)鍵進(jìn)行分區(qū)段，這樣關(guān)聯(lián)鍵相同的記錄就會放在同一個value list中，同時保證了join左邊的表的記錄在value list的前面，而join右邊的表的記錄在value list的后面。

例如A join B ON (A.id = b.id) ，假設(shè)A表和B表都有1條id = 3的記錄，那么A表這條記錄的組合鍵是(3,0)，B表這條記錄的組合鍵是(3,1)。排序時可以保證A表的記錄在B表的記錄的前面。而在reduce做處理時，把id=3的放在同一個value list中，形成 key = 3,value list = [A表id=3的記錄,B表id=3的記錄]

接下來我們再來看當(dāng)兩個表做關(guān)聯(lián)時reduce做了什么。Reduce會一起處理id相同的所有記錄。我們把value list用數(shù)組來表示。

1)   Reduce先讀取第一條記錄v[0],如果發(fā)現(xiàn)v[0]是B表的記錄，那說明沒有A表的記錄，最終不會關(guān)聯(lián)輸出，因此不用再繼續(xù)處理這個id了，讀取v[0]用了1次讀取操作。

2)   如果發(fā)現(xiàn)v[0]到v[length-1]全部是A表的記錄，那說明沒有B表的記錄，同樣最終不會關(guān)聯(lián)輸出，但是這里注意，已經(jīng)對value做了length次的讀取操作。

3)   例如A表id=3有1條記錄，B表id=3有10條記錄。首先讀取v[0]發(fā)現(xiàn)是A表的記錄，用了1次讀取操作。然后再讀取v[1]發(fā)現(xiàn)是B表的操作，這時v[0]和v[1]可以直接關(guān)聯(lián)輸出了，累計用了2次操作。這時候reduce已經(jīng)知道從v[1]開始后面都是B 表的記錄了，因此可以直接用v[0]依次和v[2],v[3]……v[10]做關(guān)聯(lián)操作并輸出，累計用了11次操作。

4)   換過來，假設(shè)A表id=3有10條記錄，B表id=3有1條記錄。首先讀取v[0]發(fā)現(xiàn)是A表的記錄，用了1次讀取操作。然后再讀取v[1]發(fā)現(xiàn)依然是A表的記錄，累計用了2次讀取操作。以此類推，讀取v[9]時發(fā)現(xiàn)還是A表的記錄，累計用了10次讀取操作。然后讀取最后1條記錄v[10]發(fā)現(xiàn)是B表的記錄，可以將v[0]和v[10]進(jìn)行關(guān)聯(lián)輸出，累計用了11次操作。接下來可以直接把v[1]~v[9]分別與v[10]進(jìn)行關(guān)聯(lián)輸出，累計用了20次操作。

5)   再復(fù)雜一點，假設(shè)A表id=3有2條記錄，B表id=3有5條記錄。首先讀取v[0]發(fā)現(xiàn)是A表的記錄，用了1次讀取操作。然后再讀取v[1]發(fā)現(xiàn)依然是A表的記錄，累計用了2次讀取操作。然后讀取v[2]發(fā)現(xiàn)是B表的記錄，此時v[0]和v[2]可以直接關(guān)聯(lián)輸出，累計用了3次操作。接下來v[0]可以依次和v[3]~v[6]進(jìn)行關(guān)聯(lián)輸出，累計用了7次操作。接下來v[1]再依次和v[2]~v[6]進(jìn)行關(guān)聯(lián)輸出，累計用了12次操作。

6)   把5的例子調(diào)過來，假設(shè)A表id=3有5條記錄，B表id=3有2條記錄。先讀取v[0]發(fā)現(xiàn)是A表的記錄，用了1次讀取操作。然后再讀取v[1]發(fā)現(xiàn)依然是A表的記錄，累計用了2次讀取操作。以此類推，讀取到v[4]發(fā)現(xiàn)依然是A表的記錄，累計用了5次讀取操作。接下來讀取v[5]，發(fā)現(xiàn)是B表的記錄，此時v[0]和v[5]可以直接關(guān)聯(lián)輸出，累計用了6次操作。然后v[0]和v[6]進(jìn)行關(guān)聯(lián)輸出，累計用了7次操作。然后v[1]分別與v[5]、v[6]關(guān)聯(lián)輸出，累計用了9次操作。V[2] 分別與v[5]、v[6]關(guān)聯(lián)輸出，累計用了11次操作。以此類推，最后v[4] 分別與v[5]、v[6]關(guān)聯(lián)輸出，累計用了15次操作。

7)   額外提一下，當(dāng)reduce檢測A表的記錄時，還要記錄A表同一個key的記錄的條數(shù)，當(dāng)發(fā)現(xiàn)同一個key的記錄個數(shù)超過hive.skewjoin.key的值（默認(rèn)為1000000）時，會在reduce的日志中打印出該key，并標(biāo)記為傾斜的關(guān)聯(lián)鍵。

最終得出的結(jié)論是：寫在關(guān)聯(lián)左側(cè)的表每有1條重復(fù)的關(guān)聯(lián)鍵時底層就會多1次運算處理。

假設(shè)A表有一千萬個id，平均每個id有3條重復(fù)值，那么把A表放在前面做關(guān)聯(lián)就會多做三千萬次的運算處理，這時候誰寫在前誰寫在后就看出性能的差別來了。