Shuffle過程
在MapReduce框架中，shuffle是連接Map和Reduce之間的橋梁，Map的輸出要用到Reduce中必須經過shuffle這個環節，shuffle的性能高低直接影響了整個程序的性能和吞吐量。Spark作為MapReduce框架的一種實現，也實現了shuffle的邏輯。
Shuffle
Shuffle是MapReduce框架中的一個特定的phase，介於Map phase和Reduce phase之間，當Map的輸出結果要被Reduce使用時，輸出結果需要按key哈希，並且分發到每一個Reducer上去，這個過程就是shuffle。由於shuffle涉及到了磁盤的讀寫和網絡的傳輸，因此shuffle性能的高低直接影響到了整個程序的運行效率。
下面這幅圖清晰地描述了MapReduce算法的整個流程，其中shuffle phase是介於Map phase和Reduce phase之間。
概念上shuffle就是一個溝通數據連接的橋梁，那么實際上shuffle（partition）這一部分實現的機制如下。
1、Spark Shuffle
以圖為例簡單描述一下Spark中shuffle的整一個流程：
l 首先每一個Mapper會根據Reducer的數量創建出相應的bucket，bucket的數量是M×RM×R，其中MM是Map的個數，RR是Reduce的個數。
l 其次Mapper產生的結果會根據設置的partition算法填充到每個bucket中去。這里的partition算法是可以自定義的，當然默認的算法是根據key哈希到不同的bucket中去。
l 當Reducer啟動時，它會根據自己task的id和所依賴的Mapper的id從遠端或是本地的block manager中取得相應的bucket作為Reducer的輸入進行處理。
這里的bucket是一個抽象概念，在實現中每個bucket可以對應一個文件，可以對應文件的一部分或是其他等。
Apache Spark 的 Shuffle 過程與 Apache Hadoop 的 Shuffle 過程有着諸多類似，一些概念可直接套用，例如，Shuffle 過程中，提供數據的一端，被稱作 Map 端，Map 端每個生成數據的任務稱為 Mapper，對應的，接收數據的一端，被稱作 Reduce 端，Reduce 端每個拉取數據的任務稱為 Reducer，Shuffle 過程本質上都是將 Map 端獲得的數據使用分區器進行划分，並將數據發送給對應的 Reducer 的過程。
2、Shuffle Write
在Spark 0.6和0.7的版本中，對於shuffle數據的存儲是以文件的方式存儲在block manager中，與rdd.persist(StorageLevel.DISk_ONLY)采取相同的策略，可以參看：
可以看到Spark在每一個Mapper中為每個Reducer創建一個bucket，並將RDD計算結果放進bucket中。需要注意的是每個bucket是一個ArrayBuffer，也就是說Map的輸出結果是會先存儲在內存。
接着Spark會將ArrayBuffer中的Map輸出結果寫入block manager所管理的磁盤中，這里文件的命名方式為：shuffle_ + shuffle_id + "_" + map partition id + "_" + shuffle partition id。
早期的shuffle write有兩個比較大的問題：
l Map的輸出必須先全部存儲到內存中，然后寫入磁盤。這對內存是一個非常大的開銷，當內存不足以存儲所有的Map output時就會出現OOM。
l 每一個Mapper都會產生Reducer number個shuffle文件，如果Mapper個數是1k，Reducer個數也是1k，那么就會產生1M個shuffle文件，這對於文件系統是一個非常大的負擔。同時在shuffle數據量不大而shuffle文件又非常多的情況下，隨機寫也會嚴重降低IO的性能。
在Spark 0.8版本中，shuffle write采用了與RDD block write不同的方式，同時也為shuffle write單獨創建了ShuffleBlockManager，部分解決了0.6和0.7版本中遇到的問題。
首先來看一下Spark 0.8的具體實現：
在這個版本中為shuffle write添加了一個新的類ShuffleBlockManager，由ShuffleBlockManager來分配和管理bucket。同時ShuffleBlockManager為每一個bucket分配一個DiskObjectWriter，每個write handler擁有默認100KB的緩存，使用這個write handler將Map output寫入文件中。可以看到現在的寫入方式變為buckets.writers(bucketId).write(pair)，也就是說Map output的key-value pair是逐個寫入到磁盤而不是預先把所有數據存儲在內存中在整體flush到磁盤中去。
ShuffleBlockManager的代碼如下所示：
Spark 0.8顯著減少了shuffle的內存壓力，現在Map output不需要先全部存儲在內存中，再flush到硬盤，而是record-by-record寫入到磁盤中。同時對於shuffle文件的管理也獨立出新的ShuffleBlockManager進行管理，而不是與rdd cache文件在一起了。
但是這一版Spark 0.8的shuffle write仍然有兩個大的問題沒有解決：
l 首先依舊是shuffle文件過多的問題，shuffle文件過多一是會造成文件系統的壓力過大，二是會降低IO的吞吐量。
l 其次雖然Map output數據不再需要預先在內存中evaluate顯著減少了內存壓力，但是新引入的DiskObjectWriter所帶來的buffer開銷也是一個不容小視的內存開銷。假定有1k個Mapper和1k個Reducer，那么就會有1M個bucket，於此同時就會有1M個write handler，而每一個write handler默認需要100KB內存，那么總共需要100GB的內存。這樣的話僅僅是buffer就需要這么多的內存，內存的開銷是驚人的。當然實際情況下這1k個Mapper是分時運行的話，所需的內存就只有cores * reducer numbers * 100KB大小了。但是reducer數量很多的話，這個buffer的內存開銷也是蠻厲害的。
為了解決shuffle文件過多的情況，Spark 0.8.1引入了新的shuffle consolidation，以期顯著減少shuffle文件的數量。
首先以圖例來介紹一下shuffle consolidation的原理。
假定該job有4個Mapper和4個Reducer，有2個core，也就是能並行運行兩個task。可以算出Spark的shuffle write共需要16個bucket，也就有了16個write handler。在之前的Spark版本中，每一個bucket對應的是一個文件，因此在這里會產生16個shuffle文件。
而在shuffle consolidation中每一個bucket並非對應一個文件，而是對應文件中的一個segment，同時shuffle consolidation所產生的shuffle文件數量與Spark core的個數也有關系。在上面的圖例中，job的4個Mapper分為兩批運行，在第一批2個Mapper運行時會申請8個bucket，產生8個shuffle文件；而在第二批Mapper運行時，申請的8個bucket並不會再產生8個新的文件，而是追加寫到之前的8個文件后面，這樣一共就只有8個shuffle文件，而在文件內部這有16個不同的segment。因此從理論上講shuffle consolidation所產生的shuffle文件數量為C×R，其中C是Spark集群的core number，R是Reducer的個數。
需要注意的是當 M=C時shuffle consolidation所產生的文件數和之前的實現是一樣的。
Shuffle consolidation顯著減少了shuffle文件的數量，解決了之前版本一個比較嚴重的問題，但是writer handler的buffer開銷過大依然沒有減少，若要減少writer handler的buffer開銷，只能減少Reducer的數量，但是這又會引入新的問題，下文將會有詳細介紹。
3、Shuffle Fetch and Aggregator
Shuffle write寫出去的數據要被Reducer使用，就需要shuffle fetcher將所需的數據fetch過來，這里的fetch包括本地和遠端，因為shuffle數據有可能一部分是存儲在本地的。Spark對shuffle fetcher實現了兩套不同的框架：NIO通過socket連接去fetch數據；OIO通過netty server去fetch數據。分別對應的類是BasicBlockFetcherIterator和NettyBlockFetcherIterator。
在Spark 0.7和更早的版本中，只支持BasicBlockFetcherIterator，而BasicBlockFetcherIterator在shuffle數據量比較大的情況下performance始終不是很好，無法充分利用網絡帶寬，為了解決這個問題，添加了新的shuffle fetcher來試圖取得更好的性能。都知道在hadoop MapReduce的shuffle過程中，shuffle fetch過來的數據會進行merge sort，使得相同key下的不同value按序歸並到一起供Reducer使用，這個過程可以參看下圖：
所有的merge sort都是在磁盤上進行的，有效地控制了內存的使用，但是代價是更多的磁盤IO。
那么Spark是否也有merge sort呢？
首先雖然Spark屬於MapReduce體系，但是對傳統的MapReduce算法進行了一定的改變。Spark假定在大多數用戶的case中，shuffle數據的sort不是必須的，比如word count，強制地進行排序只會使性能變差，因此Spark並不在Reducer端做merge sort。既然沒有merge sort那Spark是如何進行reduce的呢？
在Spark中存在aggregator，aggregator本質上是一個hashmap，它是以map output的key為key，以任意所要combine的類型為value的hashmap。當在做word count reduce計算count值的時候，它會將shuffle fetch到的每一個key-value pair更新或是插入到hashmap中(若在hashmap中沒有查找到，則插入其中；若查找到則更新value值)。這樣就不需要預先把所有的key-value進行merge sort，而是來一個處理一個，省下了外部排序這一步驟。但同時需要注意的是reducer的內存必須足以存放這個partition的所有key和count值，因此對內存有一定的要求。
在上面word count的例子中，因為value會不斷地更新，而不需要將其全部記錄在內存中，因此內存的使用還是比較少的。考慮一下如果是group by key這樣的操作，Reducer需要得到key對應的所有value。在Hadoop MapReduce中，由於有了merge sort，因此給予Reducer的數據已經是group by key了，而Spark沒有這一步，因此需要將key和對應的value全部存放在hashmap中，並將value合並成一個array。可以想象為了能夠存放所有數據，用戶必須確保每一個partition足夠小到內存能夠容納，這對於內存是一個非常嚴峻的考驗。因此Spark文檔中建議用戶涉及到這類操作的時候盡量增加partition，也就是增加Mapper和Reducer的數量。
增加Mapper和Reducer的數量固然可以減小partition的大小，使得內存可以容納這個partition。但是在shuffle write中提到，bucket和對應於bucket的write handler是由Mapper和Reducer的數量決定的，task越多，bucket就會增加的更多，由此帶來write handler所需的buffer也會更多。在一方面為了減少內存的使用采取了增加task數量的策略，另一方面task數量增多又會帶來buffer開銷更大的問題，因此陷入了內存使用的兩難境地。
為了減少內存的使用，只能將aggregator的操作從內存移到磁盤上進行，Spark社區也意識到了Spark在處理數據規模遠遠大於內存大小時所帶來的問題。因此PR303提供了外部排序的實現方案。