hive join 資料傾斜 真實案例

2021-10-17 08:58:55 字數 2903 閱讀 4142

hive或者mr處理資料,不怕資料量大,就怕傾斜。hive裡大表join的時候,資料傾斜就是個很頭疼的問題。本博主就遇到了乙個真實案例,特意記錄下來,有需要的同學可以參考

set mapred.reduce.tasks = 30;

insert overwrite directory '***'

select

cus.ida,cus.name,addr.bb from tablea as cus

join tableb as addr

on cus.ida = addr.idb

很簡單的乙個hql語句,優化的空間也不是很大(例子中的addr資料量比cus小,應該講addr放在前面驅動join)。tablea的量級為億級,tableb的量級為幾百萬級別。就這麼乙個簡單的sql,尼瑪從上午十點半開始跑,跑到下午三點半還沒有跑完。實在受不了了,kill掉了。

首先上個查詢過程中的圖

看到這種情況,稍微有點經驗的同學第一反應肯定就是:臥槽,這尼瑪肯定是資料傾斜了。沒錯,map早就完工了,reduce階段一直卡在99%,而且cumulative cpu的時間還一直在增長,說明整個job還在後台跑著。這種情況下,99%的可能性就是資料發生了傾斜,整個查詢任務都在等某個節點完成。。。

問題既然已經定位了,那接下來就是需要解決問題了。正好不巧的是,集群這幾天還出了一些狀況。so,首先為了確認到底是集群本身的問題,還是**的問題,先找了另外兩個表,都是億級資料。這兩個表不存在資料傾斜的情況,join一把試了試,兩分鐘之內結果就出來了。萬幸,說明這會集群已經沒有問題了,還是查查資料跟**吧。

**本身很簡單,那就沿著資料傾斜的方向查查吧。因為上面的兩個表是根據id關聯的,那如果傾斜的話,肯定就是id傾斜了哇。

set mapred.reduce.tasks = 5;

select ida,count(*) as num

from tablea

group by ida

distribute by ida

sort by num desc limit 10

結果為:

192928	5828529

2000000000496592833 2406289

18000 1706031

4000288 1386324

2000000003624295444 1201178

2000000001720892923 1029475

2000000002292880478 991299

2000000000736661289 881954

2000000000740899183 873487

2000000000575115116 803250

對於有上億資料的乙個表來說,這資料也算不上傾斜多厲害嘛。最多的乙個key也就五百多萬不到六百萬。好吧,先不管了,再查一把另外乙個表

set mapred.reduce.tasks = 5;

select idb,count(*) as num

from tableb

group by idb

distribute by idb

sort by num desc limit 10

結果也很快出來

192928	383412

18000 60318

617279581 23028

51010262 4643

4000286 3528

2000000000575115116 3218

1366173280 3012

4212339 2972

2000000002025620390 2704

2000000001312577574 2622

這資料傾斜,也不是特別嚴重嘛。

不過再把這兩個結果一對比,尼瑪恍然大悟。兩個表裡最多的乙個key都是192928,乙個出現了將近600萬次,乙個出現了將近40萬次。這兩個表再一join,尼瑪這乙個key就是600萬40萬的計算量。最要命的是,這計算量都分配給了乙個節點。我數學不太好,600萬40萬是多少,跪求數學好的同學幫忙計算一下。不過根據經驗來看的話,別說5個小時,再添個0也未必能算得完。。。

##4.如何解決

既然找到了資料傾斜的位置,那解決起來也就好辦了。因為本博主的真正需求並不是真正要算兩個表的笛卡爾積(估計實際中也極少有真正的需求算600萬*40萬資料的笛卡爾積。如果有,那畫面太美我不敢看),所以最easy的解決方案,就是將這些key給過濾掉完事:

set mapred.reduce.tasks = 30;

insert overwrite directory '***'

select

cus.ida,cus.name,addr.bb from tablea as cus

join tableb as addr

on cus.ida = addr.idb

where cus.ida not in (192928,2000000000496592833,18000,4000288,2000000003624295444,2000000001720892923,2000000002292880478,2000000000736661289,2000000000740899183,2000000000575115116,617279581,51010262,4000286,1366173280,2000000002025620390,2000000001312577574)

將此**重新提交,5min時間,job跑完收工!

Hive資料傾斜案列(大表join大表)

使用者軌跡工程的效能瓶頸一直是etract track info,其中耗時大戶主要在於trackinfo與pm info進行左關聯的環節,trackinfo與pm info兩張表均為gb級別,左關聯 塊如下 from trackinfo a left outer join pm info b on ...

mysql資料傾斜 Hive SQL 資料傾斜總結

在海量資料下的資料查詢中,資料傾斜是乙個很恐怖的場景。常常看似很普通的資料查詢,執行了幾個小時也沒有結果,其原因往往是發生了資料傾斜。如果真對資料傾斜採取相應的解決方法,那麼查詢效率將會大大提高。所以,分析資料傾斜是一件相當有意義的任務。本文總結不同情況下的資料傾斜,並分別給出解決方法。資料傾斜 資...

什麼是資料傾斜,怎麼解決資料傾斜?

相信很多接觸mapreduce的朋友對 資料傾斜 這四個字並不陌生,那麼究竟什麼是資料傾斜?又改怎樣解決這種該死的情況呢?何為資料傾斜?正常的資料分布理論上都是傾斜的,就是我們所說的2 8原理 80 的財富集中在20 的人手中,80 的使用者只使用20 的功能,20 的使用者貢獻了80 的訪問量,不...