參考資料
https://tech.meituan.com/2016/05/12/spark-tuning-pro.html （美團的文章，獲益匪淺）
https://blog.csdn.net/yisun123456/article/details/86699502
前言
對於spark而言，出現傾斜之類的問題並不陌生。大部分task很快就能完成，但是極少部分的task耗費了大部分的時間，甚至會出現OOM的場景，今天來模擬這種場景並提出解決辦法
模擬場景
1、相關代碼
val session = SparkSession
.builder().enableHiveSupport().getOrCreate()
val frame = session.read.csv("/user/zgh/ceshi/data.csv")
val value = frame.rdd.map(x=>(x,1)).groupByKey().map(w => (w._1, w._2.sum))
value.saveAsHadoopFile("/user/zgh/result",classOf[Text],classOf[IntWritable],classOf[TextOutputFormat[Text,IntWritable]])
session.close()
其實就是單純的做了一個groupBykey並進行統計。
2、數據模擬和情景
我這邊造了2種數據
1、458M的數據，1條別的數據，1000W條其他相同的數據
2、4個G的數據, 1條別的數據，8000W條其他相同的數據
來模擬上述的情況
458M的數據很慢50S完成，shuffle write 38M，發生在stage2中，別的task都很快，而有一個耗時了26S，這就是數據傾斜造成的結果，數據的拉取和計算都發生在這個節點上。
4個G的數據更甚，直接發生了報錯，java.lang.OutOfMemoryError: Java heap space 這裏不貼詳細的圖，就是所需的內存不夠
解決方法
前提
我們在解決之前先說一下shuffle write和shuffle read(主要針對UI界面)，我在https://stackoverflow.com/questions/27276884/what-is-shuffle-read-shuffle-write-in-apache-spark 找到了參考
shuffle操作是spark stage階段數據的重新分配
Shuffle Write 是所有的executors 在一個stage結束時寫入的所有序列化數據的總和
Shuffle Read 是所有的executors在一個stage開始的時候讀取到的所有序列化數據的總和
1、提高shuffle操作的並行度
提高shuffle操作的並行度其實就是相當於增加分區數，相當於每個task中處理的數據變少，自然而然的也就減少了傾斜的情況。比如如果原本有5個key，每個key對應10條數據，這5個key都是分配給一個task的，那麼這個task就要處理50條數據。而增加了shuffle read task以後，每個task就分配到一個key，即每個task就處理10條數據，那麼自然每個task的執行時間都會變短了。
比如我將上述的代碼
val value = frame.rdd.map(x=>(x,1)).groupByKey().map(w => (w._1, w._2.sum))
變成了
val value = frame.rdd.map(x=>(x,1)).repartition(200).groupByKey().map(w => (w._1, w._2.sum))
這樣的話相當於將數據重分區爲200個分區，每個task處理的數據相應變少。但是我發現加上了這個條件，相應的並沒有得到優化，最後一步驟中，還是將最後的38M數據全部拉取到了一個task中執行。那其實說明一個問題，如果碰到我這種極端問題的話，單個Key對應了巨大的數據，增加並行度並不能解決這個問題。其實細想也能明白，重分區默認是hash分區，不管怎麼分配，相同的數據還是到一個分區裏面的。
2、過濾掉少數導致數據傾斜的key值
這種情況在我做電信項目的時候遇到過，使用的場景就是導致數據傾斜的key值本身沒有用或者對數據分析沒有影響，所以我們在使用前可以將key值過濾掉。
之前電信的項目項目是使用spark sql 做的，經常會有join的操作，由於數據的不規範性，所以在兩表關聯的時候兩邊都會有""。這樣的話，比如兩表均有1W個"“的話，那麼
就會造成join完以後有突然有了1W*1W行的數據，所以看UI界面，就會有task多了很大量的數據，造成了傾斜的現象。所以這種傾斜的情況可以通過提前過濾掉”" 字段來處理。
3、兩階段聚合(前綴或者後綴)
這種情況適合聚合操作。這裏我們採取的措施是給全部的數據加上前綴或者後綴。相當於在一階段先進行一次聚合統計，然後再二階段再對處理過的數據進行聚合操作。這樣的話，進行兩階段聚合將能大大的減少數據被拉取到一個task的數據量。也就解決了數據傾斜的問題。
如果上述的代碼被我改造成
val random=new Random()
val value_linshi = frame.rdd.map(x=>(x+"_"+random.nextInt(10),1)).groupByKey().map(w => (w._1, w._2.sum))
val value = value_linshi.map(x=>(x._1.split("_")(0),x._2)).groupByKey().map(w => (w._1, w._2.sum))
一項是UI的情況，改變明顯，只需要18S的時間，比之前縮短了很多。
傾斜爲什麼會OOM
傾斜會造成慢，爲什麼4G的數據會OOM呢，這激起了我的好奇心。
/opt/beh/core/spark/bin/spark-submit --master yarn --class com.example.sparklearn.Test --num-executors 1 --executor-memory 2g --executor-cores 2 /home/hadoop/zgh/sparklearn-0.0.1-SNAPSHOT.jar
這個是我的執行命令參數，每個core中相當於分配了1g的內存，而且shuffle write後寫出了321M的序列化數據，這些數據將會被一個core自己獨佔拉取到一個task中(看我之前自己的造的4G數據的情況可知)
然後報java.lang.OutOfMemoryError: Java heap space。這個和spark內存模型有關係，這塊我會專門開一章講解，這裏簡單說下原因
原因：
shuffer read去獲取數據是會邊拉取數據一邊聚合，這邊有一塊聚合內存（executor memory * 0.2）,也就是這塊內存不夠
所以當我吧executor-memory 設置成4G 也就是一個core佔用2g的時候就能跑成功任務了。因爲2g*0.2> 321M麼