資料傾斜是進行大資料計算時最經常遇到的問題之一。當我們在執行HiveQL或者執行MapReduce作業時候，如果遇到一直卡在map100%,reduce99%一般就是遇到了資料傾斜的問題。資料傾斜其實是進行分散式計算的時候，某些節點的計算能力比較強或者需要計算的資料比較少，早早執行完了，某些節點計算的能力較差或者由於此節點需要計算的資料比較多，導致出現其他節點的reduce階段任務執行完成，但是這種節點的資料處理任務還沒有執行完成。

　　在hive中產生資料傾斜的原因和解決方法：

　　1）group by,我使用Hive對資料做一些型別統計的時候遇到過某種型別的資料量特別多，而其他型別資料的資料量特別少。當按照型別進行group by的時候，會將相同的group by欄位的reduce任務需要的資料拉取到同一個節點進行聚合，而當其中每一組的資料量過大時，會出現其他組的計算已經完成而這裡還沒計算完成，其他節點的一直等待這個節點的任務執行完成，所以會看到一直map 100%  reduce 99%的情況。

　　解決方法：set hive.map.aggr=true

　　　　　　　set hive.groupby.skewindata=true

　　原理：hive.map.aggr=true 這個配置項代表是否在map端進行聚合

　　　　　hive.groupby.skwindata=true 當選項設定為 true，生成的查詢計劃會有兩個 MR Job。第一個 MR Job 中，Map 的輸出結果集合會隨機分佈到 Reduce 中，每個 Reduce 做部分聚合操作，並輸出結果，這樣處理的結果是相同的 Group By Key 有可能被分發到不同的 Reduce 中，從而達到負載均衡的目的；第二個 MR Job 再根據預處理的資料結果按照 Group By Key 分佈到 Reduce 中（這個過程可以保證相同的 Group By Key 被分佈到同一個 Reduce 中），最後完成最終的聚合操作。

　　2）map和reduce優化。

　　　　1.當出現小檔案過多，需要合併小檔案。可以通過set hive.merge.mapfiles=true來解決。

 　　　   2.單個檔案大小稍稍大於配置的block塊的大寫，此時需要適當增加map的個數。解決方法：set mapred.map.tasks個數

　   　　 3.檔案大小適中，但map端計算量非常大，如select id,count(*),sum(case when...),sum(case when...)...需要增加map個數。解決方法：set mapred.map.tasks個數，set mapred.reduce.tasks個數

　　3）當HiveQL中包含count（distinct）時

         如果資料量非常大，執行如select a,count(distinct b) from t group by a;型別的SQL時，會出現資料傾斜的問題。

         解決方法：使用sum...group by代替。如select a,sum(1) from (select a, b from t group by a,b) group by a;

　　4）當遇到一個大表和一個小表進行join操作時。

　　  解決方法：使用mapjoin 將小表載入到記憶體中。

　  　如：select /*+ MAPJOIN(a) */ 

    　　　　　　a.c1, b.c1 ,b.c2

　　　　　from a join b 

　　　　　where a.c1 = b.c1; 

　　5）遇到需要進行join的但是關聯欄位有資料為空，如表一的id需要和表二的id進行關聯

　　   解決方法1：id為空的不參與關聯

　　　　比如：select * from log a 

join users b 

on a.id is not null and a.id = b.id 

　　　　　　　union all 

　　　　　　　select * from log a 

where a.id is null; 

　　　解決方法2：給空值分配隨機的key值

　　　　　　如：select * from log a 

left outer join users b 

on 

case when a.user_id is null 

then concat(‘hive’,rand() ) 

else a.user_id end = b.user_id; 

以上是在工作和學習中遇到的資料傾斜的情況，也希望各位能夠提供更多的建議，後續遇到會更新補充。