任務傾斜
一、Spark推測執行spark.speculation（謹慎使用）
task傾斜原因比較多，網絡io,cpu,mem都有可能造成這個節點上的任務執行緩慢，可以去看該節點的性能監控來分析原因。以前遇到過同事在spark的一臺worker上跑R的任務導致該節點spark task運行緩慢。
或者可以開啓spark的推測機制，開啓推測機制後如果某一臺機器的幾個task特別慢，推測機制會將任務分配到其他機器執行，最後Spark會選取最快的作爲最終結果。
spark.speculation true
spark.speculation.interval 100 - 檢測週期，單位毫秒，默認100ms;
spark.speculation.quantile 0.75 -參數的意思是同一個stage裏面有task完成的百分比，默認爲75%。
spark.speculation.multiplier 1.5 - 比其他的慢多少倍時啓動推測。意思是當task完成了75%的時候，取完成了的task的執行時間的中位數，再乘以這個時間比例，默認爲1.5。當未完成的task的執行時間超過了這個乘積值，就開啓推測執行
使用方式：
1，在spark-env.sh裏設置
spark.speculation=true # 這樣會作用到所有spark任務
2，在代碼裏通過sparkConf設置
conf.set("spark.speculation", true)
3,在用spark sql時
spark.sql("set spark.speculation = true")
4,map和reduce可以分開設置
sqlContext.sql("set mapreduce.map.speculative = true")
sqlContext.sql("set mapreduce.reduce.speculative = true")
二、提高shuffle操作中的reduce並行度
可以考慮提高shuffle過程中的reduce端並行度，reduce端並行度的提高就增加了reduce端task的數量，那麼每個task分配到的數據量就會相應減少，由此緩解數據傾斜問題。
- reduce端並行度的設置
在大部分的shuffle算子中，都可以傳入一個並行度的設置參數，比如reduceByKey(500)，這個參數會決定shuffle過程中reduce端的並行度，在進行shuffle操作的時候，就會對應着創建指定數量的reduce task。對於Spark SQL中的shuffle類語句，比如group by、join等，需要設置一個參數，即spark.sql.shuffle.partitions，該參數代表了shuffle read task的並行度，該值默認是200，對於很多場景來說都有點過小。
增加shuffle read task的數量，可以讓原本分配給一個task的多個key分配給多個task，從而讓每個task處理比原來更少的數據。舉例來說，如果原本有5個key，每個key對應10條數據，這5個key都是分配給一個task的，那麼這個task就要處理50條數據。而增加了shuffle read task以後，每個task就分配到一個key，即每個task就處理10條數據，那麼自然每個task的執行時間都會變短了。
- reduce端並行度設置存在的缺陷
提高reduce端並行度並沒有從根本上改變數據傾斜的本質和問題（方案一和方案二從根本上避免了數據傾斜的發生），只是儘可能地去緩解和減輕shuffle reduce task的數據壓力，以及數據傾斜的問題，適用於有較多key對應的數據量都比較大的情況。
該方案通常無法徹底解決數據傾斜，因爲如果出現一些極端情況，比如某個key對應的數據量有100萬，那麼無論你的task數量增加到多少，這個對應着100萬數據的key肯定還是會分配到一個task中去處理，因此註定還是會發生數據傾斜的。所以這種方案只能說是在發現數據傾斜時嘗試使用的第一種手段，嘗試去用嘴簡單的方法緩解數據傾斜而已，或者是和其他方案結合起來使用。
在理想情況下，reduce端並行度提升後，會在一定程度上減輕數據傾斜的問題，甚至基本消除數據傾斜；但是，在一些情況下，只會讓原來由於數據傾斜而運行緩慢的task運行速度稍有提升，或者避免了某些task的OOM問題，但是，仍然運行緩慢，此時，要及時放棄方案三，開始嘗試後面的方案。