智能運維大數據處理時發生數據傾斜的解決方案

爲什麼會發生數據傾斜？

19世紀末意大利經濟學家帕累託發如今任何一組東西中，最重要的只佔其中一小部分，約20%，其他80%儘管是多數，倒是次要的，所以又稱二八定律，又叫帕累托法則。

所以，正常的數據分佈理論上來講都是會發生傾斜的，例如，在進行運維大數據分析時，80%的故障異常都是由20%的常見運維問題致使的，所以，會致使少數的問題有很是多的記錄。

數據傾斜產生緣由：

MapReduce模型中，數據傾斜問題是很常見的，由於同一個Key的Values，在進行groupByKey、countByKey、reduceByKey、join等操做時必定是分配到某一個節點上的一個Task中進行處理的，若是某個Key對應的數據量特別大的話，就會形成某個節點的堵塞甚至宕機的狀況。在並行計算的做業中，整個做業的進度是由運行時間最長的那個Task決定的，在出現數據傾斜時，整個做業的運行將會很是緩慢，甚至會發生OOM異常。

解決方案

1、使用Hive ETL(提取、轉換和加載) 預處理數據

Spark做業數據一般來源於Hive中，若是發生傾斜的數據來源於Hive表，能夠經過Hive來進行數據預處理。直接經過Hive ETL，對數據預先進行聚合或join等操做，直接生成結果數據表，這樣在Spark做業中針對的數據源就是預處理事後的Hive表，就不須要再去執行Shuffle類的算子了，從根源上解決了數據傾斜。

可是，由於數據自己就存在着分佈不均的問題，因此在Hive ETL進行數據處理時，仍是會發生數據傾斜，做業速度變慢的問題，這種解決方案只是避免的Spark做業時的數據傾斜問題。

2、提升Reduce任務的並行度

將Reduce Task的數量變多，就可讓每一個Reduce Task分配到更少的數據量，這樣能夠緩解數據傾斜的問題。

在調用groupByKey、countByKey、reduceByKey時，傳入Reduce端的並行度參數，這樣在進行Shuffle操做時，會建立指定的Reduce Task，可讓每一個Reduce Task分配到更少許的數據，避免了Spark做業時OOM的狀況。

3、使用隨機Key進行分步聚合

在groupByKey、reduceByKey操做時，第一次聚合的時候，對Key加一個隨機前綴，例如10之內的隨機數，將Key進行打散操做，將Key分爲多組後，先進行局部聚合，在第二次聚合的時候，去除掉每一個Key的前綴，再全部Key進行全局的聚合。

4、使用廣播數據避免Reduce操做

當兩個RDD要進行join操做時，其中一個RDD是比較小的，將較小的那個RDD進行Broadcast操做後，不使用join進行兩個RDD的鏈接，由於普通的join操做是會觸發Shuffle過程的，一旦觸發Shuffle會將相同Key的數據都拉取到同一個Task中進行處理，而使用map join從廣播變量中獲取較小的RDD中的數據進行鏈接操做，不會觸發Shuffle，避免了數據傾斜的發生。

可是，若是兩個RDD都比較大，將其中一個RDD的數據進行Broadcast後，數據將會在每一個Executor的Block Manger中都駐留一份，頗有可能致使內存溢出，程序崩潰。

5、將發生數據傾斜的key單獨進行join

首先經過Spark中的sample算子對數據進行隨機抽樣，而後對抽樣出的數據中Key出現的次數進行排序，這樣就能夠找到致使數據傾斜的一個或多個Key，而後對數據進行Filter操做，能夠將產生數據傾斜的Key和普通Key的數據分離，生成兩個RDD。

對於可能產生數據傾斜的RDD，給每條數據都打上隨機數進行打散操做後，再去進行join，而後去除前綴後再跟普通RDD進行join後的結果，進行union操做。

這種方案只須要針對數據中有少許致使數據傾斜的Key，若是致使數據傾斜的Key特別多，則不適用。

6、使用隨機數和擴容表進行join

若在join操做時，RDD中有大量的Key致使了數據傾斜，能夠考慮選擇一個RDD進行擴容，將每條數據映射爲多條數據，每條數據都帶有0~n的前綴。另外一個RDD的每條數據都打上一個n之內的隨機值前綴。而後，將兩個RDD進行join操做後，再去掉前綴。

此方案與方案五的區別在於，當有大量致使數據傾斜Key的狀況時，無法將部分Key拆分出來單獨處理，所以只能對整個RDD 進行數據擴容，對資源要求很高。

總結

方案1使用Hive進行數據預處理，適用於對Spark做業執行性能要求較高的場景，將數據傾斜在Hive ETL中解決，只有在Hive ETL週期性處理數據時做業速度較慢，其他的每次Spark做業速度都將很快；

方案2提升Reduce任務的並行度，指標不治本，由於，沒有從根本上改變數據傾斜的本質和問題，只是緩解了執行Reduce Task時的壓力；

方案3使用隨機Key進行分步聚合，適用於groupByKey、reduceByKey等聚合類的操做；

方案四、五、6都是針對於join操做時發生的數據傾斜，方案4使用廣播數據避免Reduce操做適用於其中一個RDD是比較小的狀況，方案5將發生數據傾斜的key單獨進行join適用於少許數據傾斜是由少許的Key致使的，方案6使用隨機數和擴容表進行join對資源要求很高，適用於大量的Key致使了數據傾斜。