1. 程式人生 > >四、Spark效能優化:shuffle調優

四、Spark效能優化:shuffle調優

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作業,不斷提升其效能。