hive中join數(shù)據(jù)傾斜的實(shí)例分析

這篇文章給大家分享的是有關(guān)hive中join數(shù)據(jù)傾斜的實(shí)例分析的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。

1.查了5個(gè)小時(shí)還沒結(jié)束的sql語句

set mapred.reduce.tasks = 30;insert overwrite directory 'xxx' select cus.idA,cus.name,addr.bb from tableA as cus join tableB as addr on cus.idA = addr.idB

很簡(jiǎn)單的一個(gè)hql語句，優(yōu)化的空間也不是很大（例子中的addr數(shù)據(jù)量比cus小，應(yīng)該講addr放在前面驅(qū)動(dòng)join）。tableA的量級(jí)為億級(jí)，tableB的量級(jí)為幾百萬級(jí)別。就這么一個(gè)簡(jiǎn)單的sql，尼瑪從上午十點(diǎn)半開始跑，跑到下午三點(diǎn)半還沒有跑完。實(shí)在受不了了，kill掉了。

2.初步分析

首先上個(gè)查詢過程中的圖

看到這種情況，稍微有點(diǎn)經(jīng)驗(yàn)的同學(xué)第一反應(yīng)肯定就是：臥槽，這尼瑪肯定是數(shù)據(jù)傾斜了。沒錯(cuò)，map早就完工了，reduce階段一直卡在99%，而且cumulative cpu的時(shí)間還一直在增長(zhǎng)，說明整個(gè)job還在后臺(tái)跑著。這種情況下，99%的可能性就是數(shù)據(jù)發(fā)生了傾斜，整個(gè)查詢?nèi)蝿?wù)都在等某個(gè)節(jié)點(diǎn)完成。。。

3.分析那部分?jǐn)?shù)據(jù)產(chǎn)生了傾斜

問題既然已經(jīng)定位了，那接下來就是需要解決問題了。正好不巧的是，集群這幾天還出了一些狀況。so，首先為了確認(rèn)到底是集群本身的問題，還是代碼的問題，先找了另外兩個(gè)表，都是億級(jí)數(shù)據(jù)。這兩個(gè)表不存在數(shù)據(jù)傾斜的情況，join一把試了試，兩分鐘之內(nèi)結(jié)果就出來了。萬幸，說明這會(huì)集群已經(jīng)沒有問題了，還是查查數(shù)據(jù)跟代碼吧。

代碼本身很簡(jiǎn)單，那就沿著數(shù)據(jù)傾斜的方向查查吧。因?yàn)樯厦娴膬蓚€(gè)表是根據(jù)id關(guān)聯(lián)的，那如果傾斜的話，肯定就是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

結(jié)果為：

192928  58285292000000000496592833 240628918000   17060314000288 13863242000000003624295444 12011782000000001720892923 10294752000000002292880478 9912992000000000736661289 8819542000000000740899183 8734872000000000575115116 803250

對(duì)于有上億數(shù)據(jù)的一個(gè)表來說，這數(shù)據(jù)也算不上傾斜多厲害嘛。最多的一個(gè)key也就五百多萬不到六百萬。好吧，先不管了，再查一把另外一個(gè)表

set mapred.reduce.tasks = 5;select idB,count(*) as num from tableB group by idB distribute by idB sort by num desc limit 10

結(jié)果也很快出來

192928  38341218000   60318617279581   2302851010262    46434000286 35282000000000575115116 32181366173280  30124212339 29722000000002025620390 27042000000001312577574 2622

這數(shù)據(jù)傾斜，也不是特別嚴(yán)重嘛。

不過再把這兩個(gè)結(jié)果一對(duì)比，尼瑪恍然大悟。兩個(gè)表里最多的一個(gè)key都是192928，一個(gè)出現(xiàn)了將近600萬次，一個(gè)出現(xiàn)了將近40萬次。這兩個(gè)表再一join，尼瑪這一個(gè)key就是600萬*40萬的計(jì)算量。最要命的是，這計(jì)算量都分配給了一個(gè)節(jié)點(diǎn)。我數(shù)學(xué)不太好，600萬*40萬是多少，跪求數(shù)學(xué)好的同學(xué)幫忙計(jì)算一下。不過根據(jù)經(jīng)驗(yàn)來看的話，別說5個(gè)小時(shí)，再添個(gè)0也未必能算得完。。。

4.如何解決

既然找到了數(shù)據(jù)傾斜的位置，那解決起來也就好辦了。因?yàn)楸静┲鞯恼嬲枨蟛⒉皇钦嬲銉蓚€(gè)表的笛卡爾積（估計(jì)實(shí)際中也極少有真正的需求算600萬*40萬數(shù)據(jù)的笛卡爾積。如果有，那畫面太美我不敢看)，所以最easy的解決方案，就是將這些key給過濾掉完事：

set mapred.reduce.tasks = 30;insert overwrite directory 'xxx' 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時(shí)間，job跑完收工！

感謝各位的閱讀！關(guān)于“hive中join數(shù)據(jù)傾斜的實(shí)例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！