資料傾斜的解決辦法

產生原因

• 資料的key分化嚴重不均，造成一部分資料很多，一部分資料很少的局面
• 機器配置和資料量比例不合理，總會有key的數量超出機器處理能力，導致reduce卡頓
• 業務邏輯不合理導致:

1. 分組 注：group by 優於distinct group 情形：group by 維度過小，某值的數過多 後果：處理某值的reduce非常耗時
2. 去重 distinct count(distinct xx) 情形：某特殊值過多 後果：處理此特殊值的reduce耗時
3. 連線 join 情形1：其中一個表較小，但是key集中 後果1：分發到某一個或幾Reduce上的資料遠高於平均值
4. 連線 join 情形2：大表與大表，但是分桶的判斷欄位0值或空值過多 後果2：這些空值都由一個reduce處理，非常慢

具體表現（以常見的平臺Hadoop和Spark為例）

1. Hadoop中的資料傾斜

   Hadoop中直接貼近使用者使用使用的時Mapreduce程式和Hive程式，雖說Hive最後也是用MR來執行（至少目前Hive記憶體計算並不普及），但是畢竟寫的內容邏輯區別很大，一個是程式，一個是Sql，因此這裡稍作區分。Hadoop中的資料傾斜主要表現在ruduce階段卡在99.99%，一直99.99%不能結束。 這裡如果詳細的看日誌或者和監控介面的話會發現：

• 有一個多幾個reduce卡住
• 各種container報錯OOM
• 讀寫的資料量極大，至少遠遠超過其它正常的reduce
• 伴隨著資料傾斜，會出現任務被kill等各種詭異的表現。
• Hive的資料傾斜，一般都發生在Sql中Group和On上，而且和資料邏輯繫結比較深。

2. Spark中的資料傾斜

   Spark中的資料傾斜也很常見，這裡包括Spark Streaming和Spark Sql，表現主要有下面幾種：

• Executor lost，OOM，Shuffle過程出錯
• Driver OOM
• 單個Executor執行時間特別久，整體任務卡在某個階段不能結束
• 正常執行的任務突然失敗

• 補充：在Spark streaming程式中，資料傾斜更容易出現，特別是在程式中包含一些類似sql的join、group這種操作的時候。 因為Spark Streaming程式在執行的時候，我們一般不會分配特別多的記憶體，因此一旦在這個過程中出現一些資料傾斜，就十分容易造成OOM。

如何解決傾斜問題

1. 調優引數

• hive.map.aggr=true：在map中會做部分聚集操作，效率更高但需要更多的記憶體。
• hive.groupby.skewindata=true：資料傾斜時負載均衡，當選項設定為true，生成的查詢計劃會有兩個MRJob。第一個MRJob 中，Map的輸出結果集合會隨機分佈到Reduce中，每個Reduce做部分聚合操作，並輸出結果，這樣處理的結果是相同的GroupBy Key有可能被分發到不同的Reduce中，從而達到負載均衡的目的；第二個MRJob再根據預處理的資料結果按照GroupBy Key分佈到Reduce中（這個過程可以保證相同的GroupBy Key被分佈到同一個Reduce中），最後完成最終的聚合操作。
• 起至關作用的是第二項，他分為了兩個mapreduce，第一個在shuffle過程中partition時隨機給key打標記，使其分佈在不同的reduce上計算，但不能完成全部運算，所以需要第二次mapreduce整合迴歸正常的shuffle，由於資料分佈不均問題在第一次時得到改善，所以基本解決資料傾斜問題。

2. 針對key

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

3. group操作

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

4. join操作

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

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