Spark Shuffle的Write階段和Read階段

Spark在DAG調度階段會將一個Job劃分為多個Stage，上游Stage做map工作，下游Stage做reduce工作，其本質上還是MapReduce計算框架。Shuffle是連接map和reduce之間的橋梁，它將map的輸出對應到reduce輸入中，涉及到序列化反序列化、跨節(jié)點網絡IO以及磁盤讀寫IO等。

Spark的Shuffle分為Write和Read兩個階段，分屬于兩個不同的Stage，前者是Parent Stage的最后一步，后者是Child Stage的第一步。

Spark在1.1以前的版本一直是采用Hash Shuffle的實現(xiàn)的方式，到1.1版本時參考Hadoop MapReduce的實現(xiàn)開始引入Sort Shuffle，在1.5版本時開始Tungsten鎢絲計劃，引入UnSafe Shuffle優(yōu)化內存及CPU的使用，在1.6中將Tungsten統(tǒng)一到Sort Shuffle中，實現(xiàn)自我感知選擇最佳Shuffle方式，到的2.0版本，Hash Shuffle已被刪除，所有Shuffle方式全部統(tǒng)一到Sort Shuffle一個實現(xiàn)中。

在Spark的中，負責shuffle過程的執(zhí)行、計算和處理的組件主要就是ShuffleManager，也即shuffle管理器。ShuffleManager隨著Spark的發(fā)展有兩種實現(xiàn)的方式，分別為HashShuffleManager和SortShuffleManager，因此spark的Shuffle有Hash Shuffle和Sort Shuffle兩種。

在Spark 1.2以前，默認的shuffle計算引擎是HashShuffleManager。該ShuffleManager而HashShuffleManager有著一個非常嚴重的弊端，就是會產生大量的中間磁盤文件，進而由大量的磁盤IO操作影響了性能。

因此在Spark 1.2以后的版本中，默認的ShuffleManager改成了SortShuffleManager。SortShuffleManager相較于HashShuffleManager來說，有了一定的改進。主要就在于，每個Task在進行shuffle操作時，雖然也會產生較多的臨時磁盤文件，但

是最后會將所有的臨時文件合并(merge)成一個磁盤文件，因此每個Task就只有一個磁盤文件。在下一個stage的shuffle read task拉取自己的數(shù)據(jù)時，只要根據(jù)索引讀取每個磁盤文件中的部分數(shù)據(jù)即可。

Shuffle階段劃分：

shuffle write：mapper階段，上一個stage得到最后的結果寫出

shuffle read ：reduce階段，下一個stage拉取上一個stage進行合并

1)未經優(yōu)化的hashShuffleManager：

HashShuffle是根據(jù)task的計算結果的key值的hashcode%ReduceTask來決定放入哪一個區(qū)分，這樣保證相同的數(shù)據(jù)一定放入一個分區(qū)，Hash Shuffle過程如下：

根據(jù)下游的task決定生成幾個文件，先生成緩沖區(qū)文件在寫入磁盤文件，再將block文件進行合并。

未經優(yōu)化的shuffle write操作所產生的磁盤文件的數(shù)量是極其驚人的。提出如下解決方案

2)經過優(yōu)化的hashShuffleManager：

在shuffle write過程中，task就不是為下游stage的每個task創(chuàng)建一個磁盤文件了。此時會出現(xiàn)shuffleFileGroup的概念，每個shuffleFileGroup會對應一批磁盤文件，每一個Group磁盤文件的數(shù)量與下游stage的task數(shù)量是相同的。