前段時間，小編的一些從事大數(shù)據(jù)開發(fā)的朋友在市場寒流和年終評比上敗下陣來。不過痛定思痛，為了來年招聘黃金季做準備，小編的朋友們都選擇在這時去招聘市場先試試水，好針對性的準備面試。通過與他們的聊天中，小編發(fā)現(xiàn)，他們在面試過程中幾乎都被問到了同一個問題或關鍵詞，那就是“數(shù)據(jù)傾斜”。

小編本著獨樂樂不如眾樂樂的原則，為了同學們能夠在面試場上取得好成績，給同學們押一次題，小編今天就來好好講講前幾天補課學習完的“數(shù)據(jù)傾斜”到底是怎么回事兒。

什么是數(shù)據(jù)傾斜？

數(shù)據(jù)傾斜，指的是并行處理的過程中，某些分區(qū)或節(jié)點處理的數(shù)據(jù)，顯著高于其他分區(qū)或節(jié)點，導致這部分的數(shù)據(jù)處理任務比其他任務要大很多，從而成為這個階段執(zhí)行最慢的部分，進而成為整個作業(yè)執(zhí)行的瓶頸，甚至直接導致作業(yè)失敗。

通俗的說，就是大量的數(shù)據(jù)計算任務被分配到了一個節(jié)點上，造成“一個人說忙死了，其他人說閑著沒事兒干”的場景。

數(shù)據(jù)傾斜是如何表現(xiàn)出來的？

當我們看任務進度長時間維持在99%，有一個或者幾個reduce節(jié)點運行很慢，導致整個作業(yè)的處理時間很長，reduce進度停留在某個值，有時百分比甚至會回退，最終導致作業(yè)失敗的這種情況，大概率是出現(xiàn)了數(shù)據(jù)傾斜。

數(shù)據(jù)傾斜產(chǎn)生的原因？

俗話說，解鈴還須系鈴人，我們首先需要知道數(shù)據(jù)傾斜是如何產(chǎn)生的，才好最終對癥下藥，最終解決這個棘手問題。

產(chǎn)生數(shù)據(jù)傾斜的原因較多較雜，比較常見的有shuffle過程導致的，還有過濾時導致的。例如在處理數(shù)據(jù)時，當數(shù)據(jù)某一個key值過多時，在進行join或groupby操作時容易導致數(shù)據(jù)傾斜。還如，有些場景下，數(shù)據(jù)原本是均衡的，但是由于進行了一系列的數(shù)據(jù)剔除操作，可能在過濾掉大量數(shù)據(jù)后，造成數(shù)據(jù)的傾斜。

數(shù)據(jù)傾斜發(fā)生后如何優(yōu)化解決？

拿Hive優(yōu)化數(shù)據(jù)傾斜來說，在不同的情形下可以有不同的解決辦法。

1. 通常情況下產(chǎn)生數(shù)據(jù)傾斜可以考慮的方法

• 了解數(shù)據(jù)分布，尋找分布更加均勻的字段作為key值

• 增加節(jié)點JVM內(nèi)存，起碼遇到數(shù)據(jù)傾斜時，不至于程序崩潰

• 對key值“加鹽”，有一種方案是在map階段時給key加上一個隨機數(shù)，有了隨機數(shù)的key就不會被大量的分配到同一節(jié)點(小幾率)，待到reduce后再把隨機數(shù)去掉即可。

2. 當使用groupby產(chǎn)生數(shù)據(jù)傾斜時

• 設置map端聚合，hive.map.aggr=true。它減輕了map端向reduce端發(fā)送的數(shù)據(jù)量，也就是減輕了數(shù)據(jù)I/O

• 設置負載均衡，hive.groupby.skewindata=true，它會讓整個MR任務變成兩個任務，第一個任務中，Map 的輸出結果集合會隨機分布到 Reduce 中，每個 Reduce 做部分聚合操作，并輸出結果，這樣處理的結果是相同的 Group By Key 有可能被分發(fā)到不同的 Reduce 中，從而達到負載均衡的目的。第二個 MR Job 再根據(jù)預處理的數(shù)據(jù)結果按照 Group By Key 分布到 Reduce 中，最后完成最終的聚合操作。

3. 當使用Join產(chǎn)生數(shù)據(jù)傾斜時

• 選用join key分布最均勻的表作為驅(qū)動表

• 小表join大表時，使用map join操作

總結一下，數(shù)據(jù)傾斜是真實工作中常遇見的一個問題，也是大數(shù)據(jù)面試中經(jīng)常遇到的問題，了解數(shù)據(jù)傾斜以及它產(chǎn)生的原因才能更好的對癥下藥去解決。在實際工作中往往需要對所遇見的場景進行具體的分析，找出解決對策。以上介紹的解決對策足以解決80%Hive數(shù)據(jù)傾斜的問題啦。