在做shuffle階段的優化過程中，遇到了資料傾斜的問題，造成了對一些情況下優化效果不明顯。主要是因為在job完成後的所得到的counters是整個job的總和，優化是基於這些counters得出的平均值，而由於資料傾斜的原因造成map處理資料量的差異過大，使得這些平均值能代表的價值降低。hive的執行是分階段的，map處理資料量的差異取決於上乙個stage的reduce輸出，所以如何將資料均勻的分配到各個reduce中，就是解決資料傾斜的根本所在。規避錯誤來更好的執行比解決錯誤更高效。在檢視了一些資料後，總結如下。
1)、key分布不均勻
2)、業務資料本身的特性
3)、建表時考慮不周
4)、某些sql語句本身就有資料傾斜
任務進度長時間維持在99%（或100%），檢視任務監控頁面，發現只有少量（1個或幾個）reduce子任務未完成。因為其處理的資料量和其他reduce差異過大。
單一reduce的記錄數與平均記錄數差異過大，通常可能達到3倍甚至更多。 最長時長遠大於平均時長。
hive.map.aggr=true
map 端部分聚合，相當於combiner
hive.groupby.skewindata=true
有資料傾斜的時候進行負載均衡，當選項設定為 true，生成的查詢計畫會有兩個 mr job。
第乙個 mr job 中，map 的輸出結果集合會隨機分布到 reduce 中，每個 reduce 做部分聚合操作，並輸出結果，這樣處理的結果是相同的 group by key 有可能被分發到不同的 reduce 中，從而達到負載均衡的目的；
第二個 mr job 再根據預處理的資料結果按照 group by key 分布到 reduce 中（這個過程可以保證相同的 group by key 被分布到同乙個 reduce 中），最後完成最終的聚合操作。
如何join：
關於驅動表的選取，選用join key分布最均勻的表作為驅動表
做好列裁剪和filter操作，以達到兩表做join的時候，資料量相對變小的效果。
大小表join：
使用map join讓小的維度表（1000條以下的記錄條數） 先進記憶體。在map端完成reduce.
大表join大表：
把空值的key變成乙個字串加上隨機數，把傾斜的資料分到不同的reduce上，由於null值關聯不上，處理後並不影響最終結果。
count distinct大量相同特殊值
count distinct時，將值為空的情況單獨處理，如果是計算count distinct，可以不用處理，直接過濾，在最後結果中加1。如果還有其他計算，需要進行group by，可以先將值為空的記錄單獨處理，再和其他計算結果進行union。
group by維度過小：
採用sum() group by的方式來替換count(distinct)完成計算。
特殊情況特殊處理：
在業務邏輯優化效果的不大情況下，有些時候是可以將傾斜的資料單獨拿出來處理。最後union回去。
使map的輸出資料更均勻的分布到reduce中去，是我們的最終目標。由於hash演算法的侷限性，按key hash會或多或少的造成資料傾斜。大量經驗表明資料傾斜的原因是人為的建表疏忽或業務邏輯可以規避的。在此給出較為通用的步驟：
1、取樣log表，哪些user_id比較傾斜，得到乙個結果表tmp1。由於對計算框架來說，所有的資料過來，他都是不知道資料分布情況的，所以取樣是並不可少的。
2、資料的分布符合社會學統計規則，貧富不均。傾斜的key不會太多，就像乙個社會的富人不多，奇特的人不多一樣。所以tmp1記錄數會很少。把tmp1和users做map join生成tmp2,把tmp2讀到distribute file cache。這是乙個map過程。
3、map讀入users和log，假如記錄來自log,則檢查user_id是否在tmp2裡，如果是，輸出到本地檔案a,否則生成的key,value對，假如記錄來自member,生成的key,value對，進入reduce階段。
4、最終把a檔案，把stage3 reduce階段輸出的檔案合併起寫到hdfs。
如果確認業務需要這樣傾斜的邏輯，考慮以下的優化方案：
1、對於join，在判斷小表不大於1g的情況下，使用map join
2、對於group by或distinct，設定 hive.groupby.skewindata=true
3、盡量使用上述的sql語句調節進行優化
Hive資料傾斜問題
資料傾斜問題一直是大資料計算中普遍存在的現象，針對這種現象一般都是從兩方面解決，從資料本身和應用軟體進行優化。由於hive中計算任務是轉化成mapreduce進行的，當sql執行緩慢或者某幾個reduce任務一直卡在99 時，說明資料有傾斜現象。根本原因就是資料在map或者reduce中分布不均勻，...
hive資料傾斜問題
背景 資料傾斜是大資料領域繞經常遇到的問題，當你所需處理的資料量到達了上億甚至是千億條的時候，資料傾斜將是橫在你面前一道巨大的坎，這也是大資料處理的乙個 的bug。最近在用hadoop跑批的時候經常遇到，一條hivesql要跑好久才能跑完。相信大部分做資料的童鞋們都會遇到資料傾斜，資料傾斜會發生在資...
解決hive中資料傾斜問題
平常工作中我們在使用hive處理業務問題的時候不可避免的會遇到資料傾斜的問題，資料傾斜的本質就是key的分布不均勻，導致分到不同reduce上的資料量差距或大或小，當資料量差距過大的時候就造成了資料傾斜，使得某乙個reduce的負擔過大，導致任務遲遲不能完成。1.key分布不均勻。2.map端資料傾...