hive join 數(shù)據(jù)傾斜 真實(shí)案例

hive或者M(jìn)R處理數(shù)據(jù)，不怕數(shù)據(jù)量大，就怕傾斜。hive里大表join的時(shí)候，數(shù)據(jù)傾斜就是個(gè)很頭疼的問(wèn)題。本博主就遇到了一個(gè)真實(shí)案例，特意記錄下來(lái)，有需要的同學(xué)可以參考

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

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

2.初步分析

首先上個(gè)查詢(xún)過(guò)程中的圖

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

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

問(wèn)題既然已經(jīng)定位了，那接下來(lái)就是需要解決問(wèn)題了。正好不巧的是，集群這幾天還出了一些狀況。so，首先為了確認(rèn)到底是集群本身的問(wèn)題，還是代碼的問(wèn)題，先找了另外兩個(gè)表，都是億級(jí)數(shù)據(jù)。這兩個(gè)表不存在數(shù)據(jù)傾斜的情況，join一把試了試，兩分鐘之內(nèi)結(jié)果就出來(lái)了。萬(wàn)幸，說(shuō)明這會(huì)集群已經(jīng)沒(méi)有問(wèn)題了，還是查查數(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è)表來(lái)說(shuō)，這數(shù)據(jù)也算不上傾斜多厲害嘛。最多的一個(gè)key也就五百多萬(wàn)不到六百萬(wàn)。好吧，先不管了，再查一把另外一個(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é)果也很快出來(lái)

192928  38341218000   60318617279581   2302851010262    46434000286 35282000000000575115116 32181366173280  30124212339 29722000000002025620390 27042000000001312577574 2622

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

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

4.如何解決

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

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跑完收工！

--end--

掃描下方二維碼
添加好友，備注【交流】
可私聊交流，也可進(jìn)資源豐富學(xué)習(xí)群