Hive中小表與大表關(guān)聯(lián)(join)的性能分析_第1頁
Hive中小表與大表關(guān)聯(lián)(join)的性能分析_第2頁
全文預(yù)覽已結(jié)束

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)

文檔簡介

1、經(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)有可能是多次的,因此有可能會生成多個臨時文件,但是最終都要合并成一個文件,即

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

3、高效率”這種說法是錯誤的。正確的說法應(yīng)該是“把重復(fù)關(guān)聯(lián)鍵少的表放在join前面做關(guān)聯(lián)可以提高join的效率?!狈治鲆幌翲ive對于兩表關(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)鍵進行主排序,當(dāng)關(guān)聯(lián)鍵相同時,再按照標(biāo)識位進行

4、輔助排序。而在分區(qū)段時,只用關(guān)聯(lián)鍵中的關(guān)聯(lián)鍵進行分區(qū)段/這樣關(guān)聯(lián)鍵相同的記錄就會放在同一個valuelist中,同時保證了join左邊的表的記錄在valuelist的前面,而join右邊的表的記錄在valuelist的后面。例如AjoinBON(A.id=b.id),假設(shè)A表和B表都有1條id=3的記錄,那么A表這條記錄的組合鍵是(3,0),B表這條記錄的組合鍵是(3,1)。排序時可以保證A表的記錄在B表的記錄的前面。而在reduce做處理時,把id=3的放在同一個valuelist中,形成key=3,valuelist=A表id=3的記錄,B表id=3的記錄接下來我們再來看當(dāng)兩個表做關(guān)聯(lián)時r

5、educe做了什么。Reduce會一起處理id相同的所有記錄。我們把valuelist用數(shù)組來表示。1) Reduce先讀取第一條記錄v0,如果發(fā)現(xiàn)v0是B表的記錄,那說明沒有A表的記錄,最終不會關(guān)聯(lián)輸出,因此不用再繼續(xù)處理這個id了,讀取v0用了1次讀取操作。2) 如果發(fā)現(xiàn)v0到vlength-1全部是A表的記錄,那說明沒有B表的記錄,同樣最終不會關(guān)聯(lián)輸出,但是這里注意,已經(jīng)對value做了length次的讀取操作。3) 例如A表id=3有1條記錄,B表id=3有10條記錄。首先讀取v0發(fā)現(xiàn)是A表的記錄,用了1次讀取操作。然后再讀取v1發(fā)現(xiàn)是B表的操作,這時v0和v1可以直接關(guān)聯(lián)輸出了,累計

6、用了2次操作。這時候reduce已經(jīng)知道從v1開始后面都是B表的記錄了,因此可以直接用v0依次和v2,v3v10做關(guān)聯(lián)操作并輸出,累計用了11次操作。4) 換過來,假設(shè)A表id=3有10條記錄,B表id=3有1條記錄。首先讀取v0發(fā)現(xiàn)是A表的記錄,用了1次讀取操作。然后再讀取v1發(fā)現(xiàn)依然是A表的記錄,累計用了2次讀取操作。以此類推,讀取v9時發(fā)現(xiàn)還是A表的記錄,累計用了10次讀取操作。然后讀取最后1條記錄v10發(fā)現(xiàn)是B表的記錄,可以將v0和v10進行關(guān)聯(lián)輸出,累計用了11次操作。接下來可以直接把v1v9分別與v10進行關(guān)聯(lián)輸出,累計用了20次操作。5) 再復(fù)雜一點,假設(shè)A表id=3有2條記錄,

7、B表id=3有5條記錄。首先讀取v0發(fā)現(xiàn)是A表的記錄,用了1次讀取操作。然后再讀取v1發(fā)現(xiàn)依然是A表的記錄,累計用了2次讀取操作。然后讀取v2發(fā)現(xiàn)是B表的記錄,此時v0和v2可以直接關(guān)聯(lián)輸出,累計用了3次操作。接下來v0可以依次和v3v6進行關(guān)聯(lián)輸出累計用了7次操作。接下來v1再依次和v2v6進行關(guān)聯(lián)輸出,累計用了12次操作。6) 把5的例子調(diào)過來,假設(shè)A表id=3有5條記錄,B表id=3有2條記錄。先讀取v0發(fā)現(xiàn)是A表的記錄,用了1次讀取操作。然后再讀取v1發(fā)現(xiàn)依然是A表的記錄,累計用了2次讀取操作。以此類推,讀取到v4發(fā)現(xiàn)依然是A表的記錄,累計用了5次讀取操作。接下來讀取v5,發(fā)現(xiàn)是B表的記錄,此時v0和v5可以直接關(guān)聯(lián)輸出,累計用了6次操作。然后v0和v6進行關(guān)聯(lián)輸出,累計用了7次操作。然后v1分別與v5、v6關(guān)聯(lián)輸出,累計用了9次操作。V2分別與v5、v6關(guān)聯(lián)輸出,累計用了11次操作。以此類推,最后v4分別與v5、v6關(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,并

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論