Hive之數據傾斜
一、數據傾斜的原因
數據傾斜就是由於數據分布不均勻，數據大量集中到一點上，造成數據熱點。在Job完成後的所得到的Counters是整個Job的總和，優化是基於這些Counters得出的平均值，而由於數據傾斜的原因造成map處理數據量的差異過大，使得這些平均值能代表的價值降低。Hive的執行是分階段的，map處理數據量的差異取決於上一個stage的reduce輸出，所以如何將數據均勻的分配到各個reduce中，就是解決數據傾斜的根本所在。
1)、key分布不均勻
2)、業務數據本身的特性
3)、建表時考慮不周
4)、某些SQL語句本身就有數據傾斜
二、數據傾斜的表現
主要表現為以下三種情況：
1.map端執行比較快，reduce執行很慢，因為partition造成的數據傾斜。
2.某些reduce很快，某些reduce很慢，也是因為partition造成的數據傾斜。
3.某些map執行很快，某些map執行很慢，這是因為數據本身的分布的不合理性造成的。
造成上面reduce和map任務運行很緩慢本質上就兩種情況：
第一：reduce緩慢是因為partition造成滴；
第二：map端緩慢是因為數據本身的分布不合理性。
Reduce端緩慢：
兩個table的join操作會造成數據傾斜，會造成reduce緩慢
因為數據本身不是服從均勻分布，大多數還是高斯分布，有些情況下造成的reduce緩慢無法解決。
由於groupby操作導致的數據傾斜，而count(distinct)內部本質也是有groupby實現
map端緩慢：
這種情況是由於每條數據的相對位置造成的。
三、數據傾斜的操作
以下操作會產生
|
關鍵詞 |
情形 |
後果 |
|
Join |
其中一個表較小， 但是key集中 |
分發到某一個或幾個Reduce上的數據遠高於平均值 |
|
大表與大表，但是分桶的判斷字段0值或空值過多 |
這些空值都由一個reduce處理，灰常慢 |
|
|
group by |
group by 維度過小， 某值的數量過多 |
處理某值的reduce灰常耗時 |
|
Count Distinct |
某特殊值過多 |
處理此特殊值的reduce耗時 |
四、解決方法
1.參數調節
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 中），最後完成最終的聚合操作。
2.SQL語句調節：
如何Join：
關於驅動表的選取，選用join key分布最均勻的表作為驅動表
做好列裁剪和filter操作，以達到兩表做join的時候，數據量相對變小的效果。
大小表Join：
使用map join讓小的維度表（1000條以下的記錄條數） 先進內存，然後再對比較大的表格進行map操作。join就發生在map操作的時候，每當掃描一個大的table中的數據，就要去去查看小表的數據，哪條與之相符，繼而進行連接。這裏的join並不會涉及reduce操作。map端join的優勢就是在於沒有shuffle。（mapjoin，common join，smbJoin）
大表Join大表：
把空值的key變成一個字符串加上隨機數，把傾斜的數據分到不同的reduce上，由於null值關聯不上，處理後並不影響最終結果。
count distinct大量相同特殊值
count distinct時，將值為空的情況單獨處理，如果是計算count distinct，可以不用處理，直接過濾，在最後結果中加1。如果還有其他計算，需要進行group by，可以先將值為空的記錄單獨處理，再和其他計算結果進行union。
group by維度過小：
采用sum() group by的方式來替換count(distinct)完成計算。hive默認首先在map端聚合，然後在reduce端聚合，像sum、count，因為已經在map端做了聚合操作了，到reduce端的數據相對少一些，所以不存在這個問題。
特殊情況特殊處理：
在業務邏輯優化效果的不大情況下，有些時候是可以將傾斜的數據單獨拿出來處理。最後union回去。不同類型字段關聯要先轉換類型。
Hive之數據傾斜