shuffle調優

調優概述

      大多數Spark作業的效能主要就是消耗在了shuffle環節，因為該環節包含了大量的磁碟IO、序列化、網路資料傳輸等操作。因此，如果要讓作業的效能更上一層樓，就有必要對shuffle過程進行調優。但是也必須提醒大家的是，影響一個Spark作業效能的因素，主要還是程式碼開發、資源引數以及資料傾斜，shuffle調優只能在整個Spark的效能調優中佔到一小部分而已。因此大家務必把握住調優的基本原則，千萬不要捨本逐末。下面我們就給大家詳細講解shuffle的原理，以及相關引數的說明，同時給出各個引數的調優建議。

ShuffleManager發展概述

      在Spark的原始碼中，負責shuffle過程的執行、計算和處理的元件主要就是ShuffleManager，也即shuffle管理器。而隨著Spark的版本的發展，ShuffleManager也在不斷迭代，變得越來越先進。

      在Spark 1.2以前，預設的shuffle計算引擎是HashShuffleManager。該ShuffleManager而HashShuffleManager有著一個非常嚴重的弊端，就是會產生大量的中間磁碟檔案，進而由大量的磁碟IO操作影響了效能。

      因此在Spark 1.2以後的版本中，預設的ShuffleManager改成了SortShuffleManager。SortShuffleManager相較於HashShuffleManager來說，有了一定的改進。主要就在於，每個Task在進行shuffle操作時，雖然也會產生較多的臨時磁碟檔案，但是最後會將所有的臨時檔案合併（merge）成一個磁碟檔案，因此每個Task就只有一個磁碟檔案。在下一個stage的shuffle read task拉取自己的資料時，只要根據索引讀取每個磁碟檔案中的部分資料即可。

      下面我們詳細分析一下HashShuffleManager和SortShuffleManager的原理。

HashShuffleManager執行原理

未經優化的HashShuffleManager

      下圖說明了未經優化的HashShuffleManager的原理。這裡我們先明確一個假設前提：每個Executor只有1個CPU core，也就是說，無論這個Executor上分配多少個task執行緒，同一時間都只能執行一個task執行緒。

      我們先從shuffle write開始說起。shuffle write階段，主要就是在一個stage結束計算之後，為了下一個stage可以執行shuffle類的運算元（比如reduceByKey），而將每個task處理的資料按key進行“分類”。所謂“分類”，就是對相同的key執行hash演算法，從而將相同key都寫入同一個磁碟檔案中，而每一個磁碟檔案都只屬於下游stage的一個task。在將資料寫入磁碟之前，會先將資料寫入記憶體緩衝中，當記憶體緩衝填滿之後，才會溢寫到磁碟檔案中去。

      那麼每個執行shuffle write的task，要為下一個stage建立多少個磁碟檔案呢？很簡單，下一個stage的task有多少個，當前stage的每個task就要建立多少份磁碟檔案。比如下一個stage總共有100個task，那麼當前stage的每個task都要建立100份磁碟檔案。如果當前stage有50個task，總共有10個Executor，每個Executor執行5個Task，那麼每個Executor上總共就要建立500個磁碟檔案，所有Executor上會建立5000個磁碟檔案。由此可見，未經優化的shuffle write操作所產生的磁碟檔案的數量是極其驚人的。

      接著我們來說說shuffle read。shuffle read，通常就是一個stage剛開始時要做的事情。此時該stage的每一個task就需要將上一個stage的計算結果中的所有相同key，從各個節點上通過網路都拉取到自己所在的節點上，然後進行key的聚合或連線等操作。由於shuffle write的過程中，task給下游stage的每個task都建立了一個磁碟檔案，因此shuffle read的過程中，每個task只要從上游stage的所有task所在節點上，拉取屬於自己的那一個磁碟檔案即可。

      shuffle read的拉取過程是一邊拉取一邊進行聚合的。每個shuffle read task都會有一個自己的buffer緩衝，每次都只能拉取與buffer緩衝相同大小的資料，然後通過記憶體中的一個Map進行聚合等操作。聚合完一批資料後，再拉取下一批資料，並放到buffer緩衝中進行聚合操作。以此類推，直到最後將所有資料到拉取完，並得到最終的結果。

優化後的HashShuffleManager

      下圖說明了優化後的HashShuffleManager的原理。這裡說的優化，是指我們可以設定一個引數，spark.shuffle.consolidateFiles。該引數預設值為false，將其設定為true即可開啟優化機制。通常來說，如果我們使用HashShuffleManager，那麼都建議開啟這個選項。

      開啟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的效能。

      假設第二個stage有100個task，第一個stage有50個task，總共還是有10個Executor，每個Executor執行5個task。那麼原本使用未經優化的HashShuffleManager時，每個Executor會產生500個磁碟檔案，所有Executor會產生5000個磁碟檔案的。但是此時經過優化之後，每個Executor建立的磁碟檔案的數量的計算公式為：CPU core的數量 * 下一個stage的task數量。也就是說，每個Executor此時只會建立100個磁碟檔案，所有Executor只會建立1000個磁碟檔案。

SortShuffleManager執行原理

      SortShuffleManager的執行機制主要分成兩種，一種是普通執行機制，另一種是bypass執行機制。當shuffle read task的數量小於等於spark.shuffle.sort.bypassMergeThreshold引數的值時（預設為200），就會啟用bypass機制。

普通執行機制

      下圖說明了普通的SortShuffleManager的原理。在該模式下，資料會先寫入一個記憶體資料結構中，此時根據不同的shuffle運算元，可能選用不同的資料結構。如果是reduceByKey這種聚合類的shuffle運算元，那麼會選用Map資料結構，一邊通過Map進行聚合，一邊寫入記憶體；如果是join這種普通的shuffle運算元，那麼會選用Array資料結構，直接寫入記憶體。接著，每寫一條資料進入記憶體資料結構之後，就會判斷一下，是否達到了某個臨界閾值。如果達到臨界閾值的話，那麼就會嘗試將記憶體資料結構中的資料溢寫到磁碟，然後清空記憶體資料結構。

      在溢寫到磁碟檔案之前，會先根據key對記憶體資料結構中已有的資料進行排序。排序過後，會分批將資料寫入磁碟檔案。預設的batch數量是10000條，也就是說，排序好的資料，會以每批1萬條資料的形式分批寫入磁碟檔案。寫入磁碟檔案是通過Java的BufferedOutputStream實現的。BufferedOutputStream是Java的緩衝輸出流，首先會將資料緩衝在記憶體中，當記憶體緩衝滿溢之後再一次寫入磁碟檔案中，這樣可以減少磁碟IO次數，提升效能。

      一個task將所有資料寫入記憶體資料結構的過程中，會發生多次磁碟溢寫操作，也就會產生多個臨時檔案。最後會將之前所有的臨時磁碟檔案都進行合併，這就是merge過程，此時會將之前所有臨時磁碟檔案中的資料讀取出來，然後依次寫入最終的磁碟檔案之中。此外，由於一個task就只對應一個磁碟檔案，也就意味著該task為下游stage的task準備的資料都在這一個檔案中，因此還會單獨寫一份索引檔案，其中標識了下游各個task的資料在檔案中的start offset與end offset。

      SortShuffleManager由於有一個磁碟檔案merge的過程，因此大大減少了檔案數量。比如第一個stage有50個task，總共有10個Executor，每個Executor執行5個task，而第二個stage有100個task。由於每個task最終只有一個磁碟檔案，因此此時每個Executor上只有5個磁碟檔案，所有Executor只有50個磁碟檔案。

bypass執行機制

下圖說明了bypass SortShuffleManager的原理。bypass執行機制的觸發條件如下：

• shuffle map task數量小於spark.shuffle.sort.bypassMergeThreshold引數的值。
• 不是聚合類的shuffle運算元（比如reduceByKey）。

      此時task會為每個下游task都建立一個臨時磁碟檔案，並將資料按key進行hash然後根據key的hash值，將key寫入對應的磁碟檔案之中。當然，寫入磁碟檔案時也是先寫入記憶體緩衝，緩衝寫滿之後再溢寫到磁碟檔案的。最後，同樣會將所有臨時磁碟檔案都合併成一個磁碟檔案，並建立一個單獨的索引檔案。

      該過程的磁碟寫機制其實跟未經優化的HashShuffleManager是一模一樣的，因為都要建立數量驚人的磁碟檔案，只是在最後會做一個磁碟檔案的合併而已。因此少量的最終磁碟檔案，也讓該機制相對未經優化的HashShuffleManager來說，shuffle read的效能會更好。

      而該機制與普通SortShuffleManager執行機制的不同在於：第一，磁碟寫機制不同；第二，不會進行排序。也就是說，啟用該機制的最大好處在於，shuffle write過程中，不需要進行資料的排序操作，也就節省掉了這部分的效能開銷。

shuffle相關引數調優

      以下是Shffule過程中的一些主要引數，這裡詳細講解了各個引數的功能、預設值以及基於實踐經驗給出的調優建議。

spark.shuffle.file.buffer

• 預設值：32k
• 引數說明：該引數用於設定shuffle write task的BufferedOutputStream的buffer緩衝大小。將資料寫到磁碟檔案之前，會先寫入buffer緩衝中，待緩衝寫滿之後，才會溢寫到磁碟。
• 調優建議：如果作業可用的記憶體資源較為充足的話，可以適當增加這個引數的大小（比如64k），從而減少shuffle write過程中溢寫磁碟檔案的次數，也就可以減少磁碟IO次數，進而提升效能。在實踐中發現，合理調節該引數，效能會有1%~5%的提升。

spark.reducer.maxSizeInFlight

• 預設值：48m
• 引數說明：該引數用於設定shuffle read task的buffer緩衝大小，而這個buffer緩衝決定了每次能夠拉取多少資料。
• 調優建議：如果作業可用的記憶體資源較為充足的話，可以適當增加這個引數的大小（比如96m），從而減少拉取資料的次數，也就可以減少網路傳輸的次數，進而提升效能。在實踐中發現，合理調節該引數，效能會有1%~5%的提升。

spark.shuffle.io.maxRetries

• 預設值：3
• 引數說明：shuffle read task從shuffle write task所在節點拉取屬於自己的資料時，如果因為網路異常導致拉取失敗，是會自動進行重試的。該引數就代表了可以重試的最大次數。如果在指定次數之內拉取還是沒有成功，就可能會導致作業執行失敗。
• 調優建議：對於那些包含了特別耗時的shuffle操作的作業，建議增加重試最大次數（比如60次），以避免由於JVM的full gc或者網路不穩定等因素導致的資料拉取失敗。在實踐中發現，對於針對超大資料量（數十億~上百億）的shuffle過程，調節該引數可以大幅度提升穩定性。

spark.shuffle.io.retryWait

• 預設值：5s
• 引數說明：具體解釋同上，該引數代表了每次重試拉取資料的等待間隔，預設是5s。
• 調優建議：建議加大間隔時長（比如60s），以增加shuffle操作的穩定性。

spark.shuffle.memoryFraction

• 預設值：0.2
• 引數說明：該引數代表了Executor記憶體中，分配給shuffle read task進行聚合操作的記憶體比例，預設是20%。
• 調優建議：在資源引數調優中講解過這個引數。如果記憶體充足，而且很少使用持久化操作，建議調高這個比例，給shuffle read的聚合操作更多記憶體，以避免由於記憶體不足導致聚合過程中頻繁讀寫磁碟。在實踐中發現，合理調節該引數可以將效能提升10%左右。

spark.shuffle.manager

• 預設值：sort
• 引數說明：該引數用於設定ShuffleManager的型別。Spark 1.5以後，有三個可選項：hash、sort和tungsten-sort。HashShuffleManager是Spark 1.2以前的預設選項，但是Spark 1.2以及之後的版本預設都是SortShuffleManager了。tungsten-sort與sort類似，但是使用了tungsten計劃中的堆外記憶體管理機制，記憶體使用效率更高。
• 調優建議：由於SortShuffleManager預設會對資料進行排序，因此如果你的業務邏輯中需要該排序機制的話，則使用預設的SortShuffleManager就可以；而如果你的業務邏輯不需要對資料進行排序，那麼建議參考後面的幾個引數調優，通過bypass機制或優化的HashShuffleManager來避免排序操作，同時提供較好的磁碟讀寫效能。這裡要注意的是，tungsten-sort要慎用，因為之前發現了一些相應的bug。

spark.shuffle.sort.bypassMergeThreshold

• 預設值：200
• 引數說明：當ShuffleManager為SortShuffleManager時，如果shuffle read task的數量小於這個閾值（預設是200），則shuffle write過程中不會進行排序操作，而是直接按照未經優化的HashShuffleManager的方式去寫資料，但是最後會將每個task產生的所有臨時磁碟檔案都合併成一個檔案，並會建立單獨的索引檔案。
• 調優建議：當你使用SortShuffleManager時，如果的確不需要排序操作，那麼建議將這個引數調大一些，大於shuffle read task的數量。那麼此時就會自動啟用bypass機制，map-side就不會進行排序了，減少了排序的效能開銷。但是這種方式下，依然會產生大量的磁碟檔案，因此shuffle write效能有待提高。

spark.shuffle.consolidateFiles

• 預設值：false
• 引數說明：如果使用HashShuffleManager，該引數有效。如果設定為true，那麼就會開啟consolidate機制，會大幅度合併shuffle write的輸出檔案，對於shuffle read task數量特別多的情況下，這種方法可以極大地減少磁碟IO開銷，提升效能。
• 調優建議：如果的確不需要SortShuffleManager的排序機制，那麼除了使用bypass機制，還可以嘗試將spark.shffle.manager引數手動指定為hash，使用HashShuffleManager，同時開啟consolidate機制。在實踐中嘗試過，發現其效能比開啟了bypass機制的SortShuffleManager要高出10%~30%。

寫在最後的話

      本文分別講解了開發過程中的優化原則、執行前的資源引數設定調優、執行中的資料傾斜的解決方案、為了精益求精的shuffle調優。希望大家能夠在閱讀本文之後，記住這些效能調優的原則以及方案，在Spark作業開發、測試以及執行的過程中多嘗試，只有這樣，我們才能開發出更優的Spark作業，不斷提升其效能。