HIVE 调优2
Hive中小表與大表關聯(join)的性能分析
經常看到一些Hive優化的建議中說當小表與大表做關聯時,把小表寫在前面,這樣可以使Hive的關聯速度更快,提到的原因都是說因為小表可以先放到內存中,然后大表的每條記錄再去內存中檢測,最終完成關聯查詢。這樣的原因看似合理,但是仔細推敲,又站不住腳跟。?
? ? ? ?多小的表算小表?如果所謂的小表在內存中放不下怎么辦?我用2個只有幾條記錄的表做關聯查詢,這應該算是小表了,在查看reduce的執行日志時依然是有寫磁盤的操作的。實際上reduce在接收全部map的輸出后一定會有一個排序所有鍵值對并合并寫入磁盤文件的操作。寫入磁盤(spill)有可能是多次的,因此有可能會生成多個臨時文件,但是最終都要合并成一個文件,即最終每一個reduce都只處理一個文件。?
? ? ? ?我做了一個實驗,用1條記錄的表和3億多條記錄的表做join,無論小表是放在join的前面還是join的后面,執行的時間幾乎都是相同的。再去看reduce的執行日志,1條記錄的表在join前或者join后兩次查詢的reduce日志幾乎也是一摸一樣的。如果按照上面的說法把join左側的表放內存等待join右側的表到內存中去檢測,那么當3億多條記錄的表放在join左側時,內存肯定是無法容下這么多記錄的,勢必要進行寫磁盤的操作,那它的執行時間應該會比小表在join前時長很多才對,但事實并不是這樣,也就說明了上面說到的原因并不合理。?
? ? ? ?事實上“把小表放在前面做關聯可以提高效率”這種說法是錯誤的。正確的說法應該是“把重復關聯鍵少的表放在join前面做關聯可以提高join的效率。”?
? ? ? ?分析一下Hive對于兩表關聯在底層是如何實現的。因為不論多復雜的Hive查詢,最終都要轉化成mapreduce的JOB去執行,因此Hive對于關聯的實現應該和mapreduce對于關聯的實現類似。而mapreduce對于關聯的實現,簡單來說,是把關聯鍵和標記是在join左邊還是右邊的標識位作為組合鍵(key),把一條記錄以及標記是在join左邊還是右邊的標識位組合起來作為值(value)。在reduce的shuffle階段,按照組合鍵的關聯鍵進行主排序,當關聯鍵相同時,再按照標識位進行輔助排序。而在分區段時,只用關聯鍵中的關聯鍵進行分區段,這樣關聯鍵相同的記錄就會放在同一個value list中,同時保證了join左邊的表的記錄在value list的前面,而join右邊的表的記錄在value list的后面。?
? ? ? ?例如A join B ON (A.id = b.id) ,假設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的記錄]?
? ? ? ?接下來我們再來看當兩個表做關聯時reduce做了什么。Reduce會一起處理id相同的所有記錄。我們把value list用數組來表示。?
? ? ? ?1)?? Reduce先讀取第一條記錄v[0],如果發現v[0]是B表的記錄,那說明沒有A表的記錄,最終不會關聯輸出,因此不用再繼續處理這個id了,讀取v[0]用了1次讀取操作。?
? ? ? ?2)?? 如果發現v[0]到v[length-1]全部是A表的記錄,那說明沒有B表的記錄,同樣最終不會關聯輸出,但是這里注意,已經對value做了length次的讀取操作。?
? ? ? ?3)?? 例如A表id=3有1條記錄,B表id=3有10條記錄。首先讀取v[0]發現是A表的記錄,用了1次讀取操作。然后再讀取v[1]發現是B表的操作,這時v[0]和v[1]可以直接關聯輸出了,累計用了2次操作。這時候reduce已經知道從v[1]開始后面都是B 表的記錄了,因此可以直接用v[0]依次和v[2],v[3]……v[10]做關聯操作并輸出,累計用了11次操作。?
? ? ? ?4)?? 換過來,假設A表id=3有10條記錄,B表id=3有1條記錄。首先讀取v[0]發現是A表的記錄,用了1次讀取操作。然后再讀取v[1]發現依然是A表的記錄,累計用了2次讀取操作。以此類推,讀取v[9]時發現還是A表的記錄,累計用了10次讀取操作。然后讀取最后1條記錄v[10]發現是B表的記錄,可以將v[0]和v[10]進行關聯輸出,累計用了11次操作。接下來可以直接把v[1]~v[9]分別與v[10]進行關聯輸出,累計用了20次操作。?
? ? ? ?5)?? 再復雜一點,假設A表id=3有2條記錄,B表id=3有5條記錄。首先讀取v[0]發現是A表的記錄,用了1次讀取操作。然后再讀取v[1]發現依然是A表的記錄,累計用了2次讀取操作。然后讀取v[2]發現是B表的記錄,此時v[0]和v[2]可以直接關聯輸出,累計用了3次操作。接下來v[0]可以依次和v[3]~v[6]進行關聯輸出,累計用了7次操作。接下來v[1]再依次和v[2]~v[6]進行關聯輸出,累計用了12次操作。?
? ? ? ?6)?? 把5的例子調過來,假設A表id=3有5條記錄,B表id=3有2條記錄。先讀取v[0]發現是A表的記錄,用了1次讀取操作。然后再讀取v[1]發現依然是A表的記錄,累計用了2次讀取操作。以此類推,讀取到v[4]發現依然是A表的記錄,累計用了5次讀取操作。接下來讀取v[5],發現是B表的記錄,此時v[0]和v[5]可以直接關聯輸出,累計用了6次操作。然后v[0]和v[6]進行關聯輸出,累計用了7次操作。然后v[1]分別與v[5]、v[6]關聯輸出,累計用了9次操作。V[2] 分別與v[5]、v[6]關聯輸出,累計用了11次操作。以此類推,最后v[4] 分別與v[5]、v[6]關聯輸出,累計用了15次操作。?
? ? ? ?7)?? 額外提一下,當reduce檢測A表的記錄時,還要記錄A表同一個key的記錄的條數,當發現同一個key的記錄個數超過hive.skewjoin.key的值(默認為1000000)時,會在reduce的日志中打印出該key,并標記為傾斜的關聯鍵。?
? ? ? ?最終得出的結論是:寫在關聯左側的表每有1條重復的關聯鍵時底層就會多1次運算處理。?
? ? ? ?假設A表有一千萬個id,平均每個id有3條重復值,那么把A表放在前面做關聯就會多做三千萬次的運算處理,這時候誰寫在前誰寫在后就看出性能的差別來了。?
總結
- 上一篇: HIVE 调优1
- 下一篇: Mysql 获取当月和上个月第一天和最后