2017-10-23
細柳條小秀才翻譯鋪
前言：資料傾斜是日常大資料查詢中**的乙個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 緩慢甚至卡頓。
三、如何處理資料傾斜問題呢？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分布不均的問題導致了之後一系列變化，如何使最後的結果變得有利，那就得先了解過程，然後自己引導變化使它朝有利的方向走去。
大資料中的資料傾斜
文章結構 先大致解釋一下什麼是資料傾斜 再根據幾個場景來描述一下資料傾斜產生的情況 詳細分析一下在hadoop和spark中產生資料傾斜的原因 如何解決 優化 資料傾斜問題？簡單的講，資料傾斜就是我們在計算資料的時候，資料的分散度不夠，導致大量的資料集中到了一台或者幾台機器上計算，這些資料的計算速度...
大資料 「資料傾斜」的問題
解決資料傾斜的辦法，前輩已經寫得非常完整了，我這裡就直接搬磚吧 建議先看這個鏈結文章，非常好 下面是自己的總結 什麼是資料傾斜？見下圖 簡單來說資料傾斜就是資料的key 的分化嚴重不均，造成一部分資料很多，一部分資料很少的局面。舉個 word count 的入門例子 它的map 階段就是形成 aaa...
hive大資料傾斜總結
在做shuffle階段的優化過程中，遇到了資料傾斜的問題，造成了對一些情況下優化效果不明顯。主要是因為在job完成後的所得到的 counters是整個job的總和，優化是基於這些counters得出的平均值，而由於資料傾斜的原因造成map處理資料量的差異過大，使得這些平均 值能代表的價值降低。hiv...