Spark Shuffle內幕解密（24）

  一、到底什么是Shuffle？

     Shuffle中文翻譯為“洗牌”，需要Shuffle的關鍵性原因是某種具有共同特征的數據需要最終匯聚到一個     計算節點上進行計算。

   二、Shuffle可能面臨的問題？

1， 數據量非常大；

2， 數據如何分類，即如何Partition，Hash、Sort、鎢絲計算；

3， 負載均衡（數據傾斜）；

4， 網絡傳輸效率，需要在壓縮和解壓縮之間做出權衡，序列化和反序列也是要考慮的問題；

說明：具體的Task進行計算的時候盡一切最大可能使得數據具備Process Locality的特性；退而求次是增加數據分片，減少每個Task處理的數據量。

三、Hash Shuffle

1， key不能是Array；

2， Hash Shuffle不需要排序，此時從理論上講就節省了Hadoop MapReduce中進行Shuffle需要排序時候的時間浪費，因為實際生產環境有大量的不需要排序的Shuffle類型；

思考：不需要排序的Hash Shuffle是否一定比需要排序的Sorted Shuffle速度更快？不一定！如果數據規模比的情形下，Hash Shuffle會比Sorted Shuffle速度快（很多）！但是如果數據量大，此時Sorted Shuffle一般都會比Hash Shuffle快（很多）

    3，每個ShuffleMapTask會根據key的哈希值計算出當前的key需要寫入的Partition，然后把決定后的結果寫入單 獨的文件，此時會導致每個Task產生R（指下一個Stage的并行度）個文件，如果當前的Stage中有M個ShuffleMapTask，則會M*R個文件！！！

     注意：Shuffle操作絕大多數情況下都要通過網絡，如果Mapper和Reducer在同一臺機器上，此時只需要讀取本地 磁盤即可。

     Hash Shuffle的兩大死穴：第一：Shuffle前會產生海量的小文件于磁盤之上，此時會產生大量耗時低效的IO操 作；第二：內存不共用！！！由于內存中需要保存海量的文件操作句柄和臨時緩存信息，如果數據處理規模比較龐大的話，內存不可承受，出現OOM等問題！

   四、Sorted Shuffle:

 為了改善上述的問題（同時打開過多文件導致Writer Handler內存使用過大以及產生過度文件導致大量的隨機讀寫 帶來的效率極為低下的磁盤IO操作），Spark后來推出了Consalidate機制，來把小文件合并，此時Shuffle時文件產生的數量為cores*R，對于ShuffleMapTask的數量明顯多于同時可用的并行Cores的數量的情況下，Shuffle產生的文件會大幅度減少，會極大降低OOM的可能；

   為此Spark推出了Shuffle Pluggable開放框架，方便系統升級的時候定制Shuffle功能模塊，也方便第三方系統改造人 員根據實際的業務場景來開放具體最佳的Shuffle模塊；核心接口ShuffleManager，具體默認實現               有HashShuffleManager、SortShuffleManager等，Spark 1.6.1中具體的配置如下：