mapreduce資料傾斜

前言：資料傾斜是日常大資料查詢中**的乙個bug，遇不到它時你覺得資料傾斜也就是書本部落格上的乙個無病呻吟的偶然案例，但當你遇到它是你就會懊悔當初怎麼不多了解一下這個赫赫有名的事故。

當然你和資料傾斜的緣分深淺還是看你公司的業務邏輯和資料量有沒有步入資料傾斜的領地。

說明：關於資料傾斜的產生原因我將結合 map 和 reduce 階段中的 shuffle 來講解，若是對 shuffle 有所忘記需要溫故的請到 mapreduce:詳解shuffle(copy,sort,merge)過程 進行相關了解。另本人能力有限，僅根據自己所了解的知識回答，若有誤處或不足之處望不吝指出。

一、什麼是資料傾斜以及資料傾斜是怎麼產生的？

簡單來說資料傾斜就是資料的key 的分化嚴重不均，造成一部分資料很多，一部分資料很少的局面。

舉個 word count 的入門例子，它的map 階段就是形成 （「aaa」,1）的形式，然後在reduce 階段進行 value 相加，得出 「aaa」 出現的次數。若進行 word count 的文字有100g，其中 80g 全部是 「aaa」 剩下 20g 是其餘單詞，那就會形成 80g 的資料量交給乙個 reduce 進行相加，其餘 20g 根據 key 不同分散到不同 reduce 進行相加的情況。如此就造成了資料傾斜，臨床反應就是 reduce 跑到 99%然後一直在原地等著 那80g 的reduce 跑完。

簡化了的 shuffle 圖就是這樣。

這樣就能清楚看到，資料經過 map後，由於不同key 的資料量分布不均，在shuffle 階段中通過 partition 將相同的 key 的資料打上發往同乙個 reducer 的標記，然後開始 spill （溢寫）寫入磁碟，最後merge成最終map階段輸出檔案。

如此一來 80g 的 aaa 將發往同乙個 reducer ，由此就可以知道 reduce 最後 1% 的工作在等什麼了。

二、為什麼說資料傾斜與業務邏輯和資料量有關？

從另外角度看資料傾斜，其本質還是在單台節點在執行那一部分資料reduce任務的時候，由於資料量大，跑不動，造成任務卡住。若是這台節點機器記憶體夠大，cpu、網路等資源充足，跑 80g 左右的資料量和跑10m 資料量所耗時間不是很大差距，那麼也就不存在問題，傾斜就傾斜吧，反正機器跑的動。所以機器配置和資料量存在乙個合理的比例，一旦資料量遠超機器的極限，那麼不管每個key的資料如何分布，總會有乙個key的資料量超出機器的能力，造成 reduce 緩慢甚至卡頓。

分組 注：group by 優於distinct group

情形：group by 維度過小，某值的數量過多

後果：處理某值的reduce非常耗時

去重 distinct count(distinct xx)

情形：某特殊值過多

後果：處理此特殊值的reduce耗時

連線 join

情形1：其中乙個表較小，但是key集中

後果1：分發到某乙個或幾個reduce上的資料遠高於平均值

情形2：大表與大表，但是分桶的判斷欄位0值或空值過多

後果2：這些空值都由乙個reduce處理，非常慢

1、調優引數

set hive.map.aggr=true；

set hive.groupby.skewindata=true;

好多同學使用這兩個引數的次數真的很多，但是他們不了解這兩個引數是怎麼解決資料傾斜的，從哪個角度著手的。

hive.groupby.skewindata=true：資料傾斜時負載均衡，當選項設定為true，生成的查詢計畫會有兩個mrjob。第乙個mrjob 中，map的輸出結果集合會隨機分布到reduce中，每個reduce做部分聚合操作，並輸出結果，這樣處理的結果是相同的groupby key有可能被分發到不同的reduce中，從而達到負載均衡的目的；第二個mrjob再根據預處理的資料結果按照groupby key分布到reduce中（這個過程可以保證相同的groupby key被分布到同乙個reduce中），最後完成最終的聚合操作。

由上面可以看出起到至關重要的作用的其實是第二個引數的設定，它使計算變成了兩個mapreduce，先在第乙個中在 shuffle 過程 partition 時隨機給 key 打標記，使每個key 隨機均勻分布到各個 reduce 上計算，但是這樣只能完成部分計算，因為相同key沒有分配到相同reduce上，所以需要第二次的mapreduce,這次就回歸正常 shuffle,但是資料分布不均勻的問題在第一次mapreduce已經有了很大的改善，因此基本解決資料傾斜。

2、在 key 上面做文章，在 map 階段將造成傾斜的key 先分成多組，例如 aaa 這個 key,map 時隨機在 aaa 後面加上 1,2,3,4 這四個數字之一，把 key 先分成四組，先進行一次運算，之後再恢復 key 進行最終運算。

3、能先進行 group 操作的時候先進行 group 操作，把 key 先進行一次 reduce,之後再進行 count 或者 distinct count 操作。

4、join 操作中，使用 map join 在 map 端就先進行 join ，免得到reduce 時卡住。

以上4中方式，都是根據資料傾斜形成的原因進行的一些變化。要麼將 reduce 端的隱患在 map 端就解決，要麼就是對 key 的操作，以減緩reduce 的壓力。總之了解了原因再去尋找解決之道就相對思路多了些，方法肯定不止這4種。

四、總結

資料key分布不均的問題導致了之後一系列變化，如何使最後的結果變得有利，那就得先了解過程，然後自己引導變化使它朝有利的方向走去。

解決 MapReduce資料傾斜問題

技術最近在做資料溯源重構優化，計畫使用業務方的資料跑資料任務，以解決資料質量問題。過程中，碰到這樣乙個case 某資料需要join n張hive表提資料，其中有這樣乙個業務邏輯要關聯出mmm文章的mmm賬號資訊，文章表記錄數 億 賬號表yyy萬 這種資料關係導致在跑mr任務時資料傾斜，某個reduc...

用mapreduce處理資料傾斜問題

資料傾斜 map reduce程式執行時，reduce節點大部分執行完畢，但是有乙個或者幾個reduce節點執行很慢，導致整個程式的處理時間很長，這是因為某乙個key的條數比其他key多很多 有時是百倍或者千倍之多 這條key所在的reduce節點所處理的資料量比其他節點就大很多，從而導致某幾個節點...

MapReduce如何解決資料傾斜問題

前言 資料傾斜是日常大資料查詢中 的乙個bug，遇不到它時你覺得資料傾斜也就是書本部落格上的乙個無病呻吟的偶然案例，但當你遇到它是你就會懊悔當初怎麼不多了解一下這個赫赫有名的事故。當然你和資料傾斜的緣分深淺還是看你公司的業務邏輯和資料量有沒有步入資料傾斜的領地。說明 關於資料傾斜的產生原因我將結合 ...