spark-shuffle與MapReduce shuffle
MR shuffle
shuffle屬於不斷被優化和改進的代碼庫，是MapReduce的“心臟”。
shuffle可以將其定義爲：map的輸出到reduce的輸入(在一些語境中，代表reduce接受map輸出的這部分)
1、map端
我們知道map產生的輸出是臨時寫到本地磁盤的，但是他並不是簡單的寫到本地磁盤中，這個過程更爲複雜，如圖：
① 分區partition
② 寫入環形內存緩衝區
③ 執行溢出寫
排序sort—>合併combiner—>生成溢出寫文件
④ 歸併merge
- 分區Partition
在將map()函數處理後得到的（key,value）對寫入到緩衝區之前，需要先進行分區操作，這樣就能把map任務處理的結果發送給指定的reducer去執行，從而達到負載均衡，避免數據傾斜 - 寫入緩存
頻繁的磁盤I/O操作,“中間結果”優先存儲到map節點的“環形內存緩衝區”.當寫入的數據量(被緩衝的（key,value）對已經被序列化)達到預先設置的闕值(80%)後便會執行一次I/O操作將數據寫入到磁盤. - 執行溢寫出
緩衝區內容達到閾值,並在每個分區中對其中的鍵值對按鍵進行sort排序，具體是將數據按照partition和key兩個關鍵字進行排序，排序結果爲緩衝區內的數據按照partition爲單位聚集在一起，同一個partition內的數據按照key有序。
（如果客戶端自定義了Combiner（相當於map階段的reduce），則會在分區排序後到溢寫出前自動調用combiner，將相同的key的value相加，這樣的好處就是減少溢寫到磁盤的數據量。這個過程叫“合併”） - 歸併merge
一個map task處理的數據很大,就會生成多個spill文件.這時進行歸併生成最終的一個已分區且已排序的大文件.Copy階段分區輸出文件通過http的方式提供給reducer）
他會首先使用緩衝的方式寫入到內存中，並且處於效率的考慮進行預排序。每個map都有一個緩衝區用於存儲任務輸出，這個緩衝區的大小默認爲100MB，可以通過io.sort.mb屬性調整。一旦緩衝的內容達到預設的閥值(通過io.sort.spill.percent,默認是0.8或80%)，一個後臺進程便把內容溢出(spill)到磁盤。在溢出過程map輸出會繼續寫到緩衝區，如果在此期間被填滿，則發生堵塞，直到寫磁盤過程完成。這個溢出寫的過程會將數據寫到mapreduce.cluster.local.dir指定的目錄內。在寫硬盤之前會根據輸出的reduce進行分區(partition)，然後對每個分區內容進行排序，如果有combiner函數，則在排序之後執行combiner。每次內存緩衝區達到溢出的閥值，就會新建一個溢出文件(spill file)。最終會有幾個溢出文件，這些溢出文件會被合併成一個已分區且已排序的輸出文件，io.sort.factor控制一次最多能夠合併多少流，默認是10。如果至少有3個溢出文件（這個值由min.num.spills.for.combine屬性設置）則就會在輸出文件寫到磁盤之前在此運行以此combiner。將輸出進行壓縮可以減少輸出及傳遞到reduce的網絡開銷，可以設置mapreduce.compress.map.output設置爲true，使用mapreduce.map.output.compression.codec指定壓縮方法。
2、reduce端
①複製copy
②歸併merge
③reduce
- 複製copy
Reduce進程啓動一些數據copy線程，使用心跳機制通知它們的application master通過HTTP方式請求MapTask所在的NodeManager以獲取(只需拷貝與自己對應的partition中的數據即可)的輸出文件。 - 歸併merge 和sort
Copy 過來的數據會先放入內存緩衝區中,Map的輸出數據已經是有序的，Merge進行一次合併排序，所謂Reduce端的sort過程就是這個合併的過程，採取的排序方法跟map階段一樣，針對鍵進行排序。
最終Reduce shuffle過程會輸出一個整體有序的數據塊。
reduce任務需要集羣中若干個map的輸出作爲其輸入，但是每個map的完成時間並不一樣，所以只要有一個map輸出，reduce就開始複製其輸出，這就是reduce端的複製階段。reduce有少量的複製線程，默認是5個，這個值由mapreduce.reduce.parallel.copies屬性改變。
那麼reduce如何知道從哪臺機器獲取map輸出呢？
map任務完成後，會通知其父tasktracker，tasktracker會通知jobtracker(在MR2中是applicationMaster)，從而jobtracker(applicationMaster)知道了tasktracker與map的映射關係，reduce中的一個線程會定期向applicationMaster（或者jobtracker）進行詢問，以便獲取map輸出的位置。
複製完成後，reduce開始進入排序階段(其實是合併節階段，因爲排序是在map端進行的)，這個階段合併map輸出，保持其排好的順序。這個合併是循環進行的，可以設置合併因子io.sort.factor,默認是10，即每趟合併10個文件，假設總共50個map，總共進行5趟，最終有5箇中文文件。之後是reduce階段，直接把數據輸入到reduce函數，而不用將這5個文件合併稱一個大文件。reduce函數輸出直接寫到HDFS上。
配置調優
map端的調優屬性：
| 屬性名稱 | 類型 | 默認值 | 說明 |
|---|---|---|---|
| io.sort.mb | int | 100 | map輸出所使用的內存緩衝區大小，以MB爲單位 |
| io.sort.spill.percent | float | 0.80 | 緩衝區預設的閥值，超過這個百分比開始將內容溢到磁盤 |
| io.sort.factory | int | 10 | 排序文件時一次最多合併的流數，在reduce端也是用 |
| min.num.spills.for.combine | int | 3 | 運行combiner所需要最少溢出文件數 |
| mapreduce.compress.map.output | Boolean | false | 壓縮map輸出 mapreduce.map.output.compression.codec Class Name org.apache.hadoop.io.compress.DefaultCodec 用於map輸出的壓縮編碼器 |
| tasktracker.http.threads | int | 40 | 每個tasktracker運行的線程數，用於將map輸出到reduce，在YARN不適用 |
這個過程總的來說就是要爲shuffle分配更多的內存，但是這時候可能還需要考慮到map函數和reduce函數能夠得到足夠運行的內。所以一般map函數和reduce函數在編寫的時候儘量少佔內存。map端可以通過避免多次溢出寫磁盤來獲得最佳性能，一次是最佳的情況。
reduce端的調優屬性
| 屬性名稱 | 類型 | 默認值 | 說明 |
|---|---|---|---|
| mapreduce.reduce.parallel.copies | int | 5 | 用於把map的輸出複製到reduce的線程數 |
| mapreduce.reduce.copy.backoff | int | 300 | 在聲明失敗之前，reducer獲取一個map輸出所花的最大時間，以秒爲單位，如果失敗，reducer可以在此時間內嘗試重傳 |
| io.sort.factor | int | 10 | 排序合併時的合併因子 |
| mapreduce.iob.shuffle.merge.percent | float | 0.66 | map輸出緩衝區(上面定義的那個)的閥值使用比例，用於啓動合併輸出和磁盤溢出寫的過程 |
| mapreduce.inmem.merge.threshold | int | 1000 | 啓動合併輸出和磁盤溢出寫過程的map的輸出的閥值數。0或更小，意味着沒有閥值限制 |
| mapreduce.iob.reduce.input.buffer.percent | float | 0.0 | 在reduce過程，在內存中保存map輸出的空間佔整個堆空間的比例。reduce階段開始時，內存中的map輸出不能大於這個值 |
spark shuffle
一.定義
Shuffle的本意是洗牌，目的是爲了把牌弄亂。
Spark、Hadoop中的shuffle可不是爲了把數據弄亂，而是爲了將隨機排列的數據轉換成具有一定規則的數據.
二.演變
Spark1.1.x addSortShuffle 有排序
Spark1.5 addd unsafe shuffle
spark1.6 hash+sort +unsafe => interagrate
spark2.0 remove hash
三.Hash Shuffle V1
有多少個reduce任務就會產生多少箇中間文件（一個task—>所產生的文件數量=== reduce task數量）
Hash Shuffle V1 過程
1：shuffle write階段
主要就是在一個stage結束計算之後，爲了下一個stage可以執行shuffle類的算子(比如reduceByKey，groupByKey)，而將每個task處理的數據按key進行“分區”。所謂“分區”，就是對相同的key執行hash算法，從而將相同key都寫入同一個磁盤文件中，而每一個磁盤文件都只屬於reduce端的stage的一個task。在將數據寫入磁盤之前，會先將數據寫入內存緩衝中，當內存緩衝填滿之後，纔會溢寫到磁盤文件中去。
2：shuffle read階段
shuffle read，通常就是一個stage剛開始時要做的事情。此時該stage的每一個task就需要將上一個stage的計算結果中的所有相同key，從各個節點上通過網絡都拉取到自己所在的節點上，然後進行key的聚合或連接等操作。由於shuffle write的過程中，task給Reduce端的stage的每個task都創建了一個磁盤文件，因此shuffle read的過程中，每個task只要從上游stage的所有task所在節點上，拉取屬於自己的那一個磁盤文件即可。
shuffle read的拉取過程是一邊拉取一邊進行聚合的。每個shuffle read task都會有一個自己的buffer緩衝，每次都只能拉取與buffer緩衝相同大小的數據，然後通過內存中的一個Map進行聚合等操作。聚合完一批數據後，再拉取下一批數據，並放到buffer緩衝中進行聚合操作。以此類推，直到最後將所有數據到拉取完，並得到最終的結果。
注意：
1).buffer起到的是緩存作用，緩存能夠加速寫磁盤，提高計算的效率,buffer的默認大小32k。
分區器：根據hash/numRedcue取模決定數據由幾個Reduce處理，也決定了寫入幾個buffer中
block file：磁盤小文件，從圖中我們可以知道磁盤小文件的個數計算公式：
block file=M*R
2).M爲map task的數量，R爲Reduce的數量，一般Reduce的數量等於buffer的數量，都是由分區器決定的
Hash shuffle普通機制的問題
1).Shuffle前在磁盤上會產生海量的小文件，建立通信和拉取數據的次數變多,此時會產生大量耗時低效的 IO 操作 (因為產生過多的小文件)
2).可能導致OOM，大量耗時低效的 IO 操作 ，導致寫磁盤時的對象過多，讀磁盤時候的對象也過多，這些對象存儲在堆內存中，會導致堆內存不足，相應會導致頻繁的GC，GC會導致OOM。由於內存中需要保存海量文件操作句柄和臨時信息，如果數據處理的規模比較龐大的話，內存不可承受，會出現 OOM 等問題。
四.Hash Shuffle V2（ spark.shuffle.consolidateFiles = true）
一個Executor—>所產生的文件數量=== reduce task數量
Hash Shuffle V2 過程：
- 開啓consolidate機制之後，在shuffle write過程中，task就不是爲下游stage的每個task創建一個磁盤文件了。此時會出現shuffleFileGroup的概念，每個shuffleFileGroup會對應一批磁盤文件，磁盤文件的數量與下游stage的task數量是相同的。一個Executor上有多少個CPU core，就可以並行執行多少個task。而第一批並行執行的每個task都會創建一個shuffleFileGroup，並將數據寫入對應的磁盤文件內。
- Executor的CPU core執行完一批task，接着執行下一批task時，下一批task就會複用之前已有的shuffleFileGroup，包括其中的磁盤文件。也就是說，此時task會將數據寫入已有的磁盤文件中，而不會寫入新的磁盤文件中。因此，consolidate機制允許不同的task複用同一批磁盤文件，這樣就可以有效將多個task的磁盤文件進行一定程度上的合併，從而大幅度減少磁盤文件的數量，進而提升shuffle write的性能。
注意：
1).啓動HashShuffle的合併機制ConsolidatedShuffle的配置:
spark.shuffle.consolidateFiles=true
2).block file=Core*R
Core爲CPU的核數，R爲Reduce的數量
Hash shuffle合併機制的問題
如果 Reducer 端的並行任務或者是數據分片過多的話則 Core * Reducer Task 依舊過大，也會產生很多小文件。
五.Sort Shuffle
一個task—>所產生的文件數量===2
Sort Shuffle 過程
該圖說明了普通的SortShuffleManager的原理。在該模式下，數據會先寫入一個內存數據結構中(默認5M)，此時根據不同的shuffle算子，可能選用不同的數據結構。如果是reduceByKey這種聚合類的shuffle算子，那麼會選用Map數據結構，一邊通過Map進行聚合，一邊寫入內存;如果是join這種普通的shuffle算子，那麼會選用Array數據結構，直接寫入內存。接着，每寫一條數據進入內存數據結構之後，就會判斷一下，是否達到了某個臨界閾值。如果達到臨界閾值的話，那麼就會嘗試將內存數據結構中的數據溢寫到磁盤，然後清空內存數據結構。
注意：
shuffle中的定時器：定時器會檢查內存數據結構的大小，如果內存數據結構空間不夠，那麼會申請額外的內存，申請的大小滿足如下公式：
applyMemory=nowMenory2-oldMemory
**申請的內存=當前的內存情況2-上一次的內嵌情況**
意思就是說內存數據結構的大小的動態變化，如果存儲的數據超出內存數據結構的大小，將申請內存數據結構存儲的數據*2-內存數據結構的設定值的內存大小空間。申請到了，內存數據結構的大小變大，內存不夠，申請不到，則發生溢寫
- 排序
在溢寫到磁盤文件之前，會先根據key對內存數據結構中已有的數據進行排序。 - 溢寫
排序過後，會分批將數據寫入磁盤文件。默認的batch數量是10000條，也就是說，排序好的數據，會以每批1萬條數據的形式分批寫入磁盤文件。寫入磁盤文件是通過Java的BufferedOutputStream實現的。BufferedOutputStream是Java的緩衝輸出流，首先會將數據緩衝在內存中，當內存緩衝滿溢之後再一次寫入磁盤文件中，這樣可以減少磁盤IO次數，提升性能。 - merge
一個task將所有數據寫入內存數據結構的過程中，會發生多次磁盤溢寫操作，也就會產生多個臨時文件。最後會將之前所有的臨時磁盤文件都進行合併，這就是merge過程，此時會將之前所有臨時磁盤文件中的數據讀取出來，然後依次寫入最終的磁盤文件之中。此外，由於一個task就只對應一個磁盤文件，也就意味着該task爲Reduce端的stage的task準備的數據都在這一個文件中，因此還會單獨寫一份索引文件，其中標識了下游各個task的數據在文件中的start offset與end offset。
注意：
- block file= 2M
一個map task會產生一個索引文件和一個數據大文件 - m*r>2m(r>2)：SortShuffle會使得磁盤小文件的個數再次的減少
Sort Shuffle–bypass
也可以無排序,按照key做hash節省了性能開銷—Sort Shuffle–bypass
一個task—>所產生的文件數量===2
bypass運行機制的觸發條件如下：
- shuffle map task數量小於spark.shuffle.sort.bypassMergeThreshold參數的值。
- 不是聚合類的shuffle算子(比如reduceByKey)。
Sort Shuffle–bypass過程：
- 此時task會爲每個reduce端的task都創建一個臨時磁盤文件，並將數據按key進行hash然後根據key的hash值，將key寫入對應的磁盤文件之中。當然，寫入磁盤文件時也是先寫入內存緩衝，緩衝寫滿之後再溢寫到磁盤文件的。最後，同樣會將所有臨時磁盤文件都合併成一個磁盤文件，並創建一個單獨的索引文件。
- 該過程的磁盤寫機制其實跟未經優化的HashShuffleManager是一模一樣的，因爲都要創建數量驚人的磁盤文件，只是在最後會做一個磁盤文件的合併而已。因此少量的最終磁盤文件，也讓該機制相對未經優化的HashShuffleManager來說，shuffle read的性能會更好。
而該機制與普通SortShuffleManager運行機制的不同在於：
第一，磁盤寫機制不同;
第二，不會進行排序。也就是說，啓用該機制的最大好處在於，shuffle write過程中，不需要進行數據的排序操作，也就節省掉了這部分的性能開銷。
shuffle過程中的臨時文件寫到哪裏？
1.在 /tmp 下
2.配置路徑
SPARK_LOCAL_DIRS=/hom/lyb/spark_log1,/hom/lyb/spark_log1,
備註：
1、需在每個worker節點上設置，可設置成不一樣的值
2、worker節點的磁盤不做raid磁盤列陣
3、可設置以逗號分隔的多個值，提高IO性能。
總結：
- Shuffle 過程本質上都是將 Map 端獲得的數據使用分區器進行劃分，並將數據發送給對應的 Reducer 的過程。
- shuffle作爲處理連接map端和reduce端的樞紐，其shuffle的性能高低直接影響了整個程序的性能和吞吐量。map端的shuffle一般爲shuffle的Write階段，reduce端的shuffle一般爲shuffle的read階段。Hadoop和spark的shuffle在實現上面存在很大的不同，spark的shuffle分爲兩種實現，分別爲HashShuffle和SortShuffle，
HashShuffle又分爲普通機制和合並機制，普通機制因爲其會產生MR個數的巨量磁盤小文件而產生大量性能低下的Io操作，從而性能較低，因爲其巨量的磁盤小文件還可能導致OOM，HashShuffle的合併機制通過重複利用buffer從而將磁盤小文件的數量降低到CoreR個，但是當Reducer 端的並行任務或者是數據分片過多的時候，依然會產生大量的磁盤小文件。 - SortShuffle也分爲普通機制和bypass機制，普通機制在內存數據結構(默認爲5M)完成排序，會產生2M個磁盤小文件。而當shuffle map task數量小於spark.shuffle.sort.bypassMergeThreshold參數的值。或者算子不是聚合類的shuffle算子(比如reduceByKey)的時候會觸發SortShuffle的bypass機制，SortShuffle的bypass機制不會進行排序，極大的提高了其性能
- 在Spark 1.2以前，默認的shuffle計算引擎是HashShuffleManager，因爲HashShuffleManager會產生大量的磁盤小文件而性能低下，在Spark 1.2以後的版本中，默認的ShuffleManager改成了SortShuffleManager。SortShuffleManager相較於HashShuffleManager來說，有了一定的改進。主要就在於，每個Task在進行shuffle操作時，雖然也會產生較多的臨時磁盤文件，但是最後會將所有的臨時文件合併(merge)成一個磁盤文件，因此每個Task就只有一個磁盤文件。在下一個stage的shuffle read task拉取自己的數據時，只要根據索引讀取每個磁盤文件中的部分數據即可。
