Apache Spark 記憶體管理詳解

標籤：記憶體管理機制   啟動   form   out   設計   ext   依賴關係   還原序列化   實現原理   

Spark 作為一個基於記憶體的分散式運算引擎，其記憶體管理模組在整個系統中扮演著非常重要的角色。理解 Spark 記憶體管理的基本原理，有助於更好地開發 Spark 應用程式和進行效能調優。本文旨在梳理出 Spark 記憶體管理的脈絡，拋磚引玉，引出讀者對這個話題的深入探討。本文中闡述的原理基於 Spark 2.1 版本，閱讀本文需要讀者有一定的 Spark 和 Java 基礎，瞭解 RDD、Shuffle、JVM 等相關概念。

在執行 Spark 的應用程式時，Spark 叢集會啟動 Driver 和 Executor 兩種 JVM 進程，前者為主控進程，負責建立 Spark 上下文，提交 Spark 作業（Job），並將作業轉化為計算任務（Task），在各個 Executor 進程間協調任務的調度，後者負責在工作節點上執行具體的計算任務，並將結果返回給 Driver，同時為需要持久化的 RDD 提供儲存功能[1]。由於 Driver 的記憶體管理相對來說較為簡單，本文主要對 Executor 的記憶體管理進行分析，下文中的 Spark 記憶體均特指 Executor 的記憶體。

1. 堆內和堆外記憶體規劃

作為一個 JVM 進程，Executor 的記憶體管理建立在 JVM 的記憶體管理之上，Spark 對 JVM 的堆內（On-heap）空間進行了更為詳細的分配，以充分利用記憶體。同時，Spark 引入了堆外（Off-heap）記憶體，使之可以直接在工作節點的系統記憶體中開闢空間，進一步最佳化了記憶體的使用。

圖 1 . 堆內和堆外記憶體

 1.1 堆內記憶體

堆內記憶體的大小，由 Spark 應用程式啟動時的 –executor-memory 或 spark.executor.memory 參數配置。Executor 內啟動並執行並發任務共用 JVM 堆內記憶體，這些任務在緩衝 RDD 資料和廣播（Broadcast）資料時佔用的記憶體被規劃為儲存（Storage）記憶體，而這些任務在執行 Shuffle 時佔用的記憶體被規劃為執行（Execution）記憶體，剩餘的部分不做特殊規劃，那些 Spark 內部的對象執行個體，或者使用者定義的 Spark 應用程式中的對象執行個體，均佔用剩餘的空間。不同的管理員模式下，這三部分佔用的空間大小各不相同（下面第 2 小節會進行介紹）。

Spark 對堆內記憶體的管理是一種邏輯上的"規劃式"的管理，因為對象執行個體佔用記憶體的申請和釋放都由 JVM 完成，Spark 只能在申請後和釋放前記錄這些記憶體，我們來看其具體流程：

• 申請記憶體：

1. Spark 在代碼中 new 一個對象執行個體
2. JVM 從堆內記憶體配置空間，建立對象並返回對象引用
3. Spark 儲存該對象的引用，記錄該對象佔用的記憶體

• 釋放記憶體：

1. Spark 記錄該對象釋放的記憶體，刪除該對象的引用
2. 等待 JVM 的記憶體回收機制釋放該對象佔用的堆內記憶體

我們知道，JVM 的對象可以以序列化的方式儲存，序列化的過程是將對象轉換為二進位位元組流，本質上可以理解為將非連續空間的鏈式儲存轉化為連續空間或Block Storage，在訪問時則需要進行序列化的逆過程——還原序列化，將位元組流轉化為對象，序列化的方式可以節省儲存空間，但增加了儲存和讀取時候的計算開銷。

對於 Spark 中序列化的對象，由於是位元組流的形式，其佔用的記憶體大小可直接計算，而對於非序列化的對象，其佔用的記憶體是通過周期性地採樣近似估算而得，即並不是每次新增的資料項目都會計算一次佔用的記憶體大小，這種方法降低了時間開銷但是有可能誤差較大，導致某一時刻的實際記憶體有可能遠遠超出預期[2]。此外，在被 Spark 標記為釋放的對象執行個體，很有可能在實際上並沒有被 JVM 回收，導致實際可用的記憶體小於 Spark 記錄的可用記憶體。所以 Spark 並不能準確記錄實際可用的堆內記憶體，從而也就無法完全避免記憶體溢出（OOM, Out of Memory）的異常。

雖然不能精準控制堆內記憶體的申請和釋放，但 Spark 通過對儲存記憶體和執行記憶體各自獨立的規劃管理，可以決定是否要在儲存記憶體裡緩衝新的 RDD，以及是否為新的任務分配執行記憶體，在一定程度上可以提升記憶體的利用率，減少異常的出現。

1.2 堆外記憶體

為了進一步最佳化記憶體的使用以及提高 Shuffle 時排序的效率，Spark 引入了堆外（Off-heap）記憶體，使之可以直接在工作節點的系統記憶體中開闢空間，儲存經過序列化的位元據。利用 JDK Unsafe API（從 Spark 2.0 開始，在管理堆外的儲存記憶體時不再基於 Tachyon，而是與堆外的執行記憶體一樣，基於 JDK Unsafe API 實現[3]），Spark 可以直接作業系統堆外記憶體，減少了不必要的記憶體開銷，以及頻繁的 GC 掃描和回收，提升了處理效能。堆外記憶體可以被精確地申請和釋放，而且序列化的資料佔用的空間可以被精確計算，所以相比堆內記憶體來說降低了管理的難度，也降低了誤差。

在預設情況下堆外記憶體並不啟用，可通過配置 spark.memory.offHeap.enabled 參數啟用，並由 spark.memory.offHeap.size 參數設定堆外空間的大小。除了沒有 other 空間，堆外記憶體與堆內記憶體的劃分方式相同，所有運行中的並發任務共用儲存記憶體和執行記憶體。

1.3 記憶體管理介面

Spark 為儲存記憶體和執行記憶體的管理提供了統一的介面——MemoryManager，同一個 Executor 內的任務都調用這個介面的方法來申請或釋放記憶體:

清單 1 . 記憶體管理介面的主要方法

123456789101112

//申請儲存記憶體def acquireStorageMemory(blockId: BlockId, numBytes: Long, memoryMode: MemoryMode): Boolean//申請展開記憶體def acquireUnrollMemory(blockId: BlockId, numBytes: Long, memoryMode: MemoryMode): Boolean//申請執行記憶體def acquireExecutionMemory(numBytes: Long, taskAttemptId: Long, memoryMode: MemoryMode): Long//釋放儲存記憶體def releaseStorageMemory(numBytes: Long, memoryMode: MemoryMode): Unit//釋放執行記憶體def releaseExecutionMemory(numBytes: Long, taskAttemptId: Long, memoryMode: MemoryMode): Unit//釋放展開記憶體def releaseUnrollMemory(numBytes: Long, memoryMode: MemoryMode): Unit

我們看到，在調用這些方法時都需要指定其記憶體模式（MemoryMode），這個參數決定了是在堆內還是堆外完成這次操作。

MemoryManager 的具體實現上，Spark 1.6 之後預設為統一管理（Unified Memory Manager）方式，1.6 之前採用的靜態管理（Static Memory Manager）方式仍被保留，可通過配置 spark.memory.useLegacyMode 參數啟用。兩種方式的區別在於對空間分配的方式，下面的第 2 小節會分別對這兩種方式進行介紹。

2 . 記憶體空間分配2.1 靜態記憶體管理

在 Spark 最初採用的靜態記憶體管理機制下，儲存記憶體、執行記憶體和其他記憶體的大小在 Spark 應用程式運行期間均為固定的，但使用者可以應用程式啟動前進行配置，堆內記憶體的分配 2 所示：

圖 2 . 靜態記憶體管理圖示——堆內

 

可以看到，可用的堆內記憶體的大小需要按照下面的方式計算：

清單 2 . 可用堆內記憶體空間

12	可用的儲存記憶體 = systemMaxMemory * spark.storage.memoryFraction * spark.storage.safetyFraction可用的執行記憶體 = systemMaxMemory * spark.shuffle.memoryFraction * spark.shuffle.safetyFraction

其中 systemMaxMemory 取決於當前 JVM 堆內記憶體的大小，最後可用的執行記憶體或者儲存記憶體要在此基礎上與各自的 memoryFraction 參數和 safetyFraction 參數相乘得出。上述計算公式中的兩個 safetyFraction 參數，其意義在於在邏輯上預留出 1-safetyFraction 這麼一塊保險地區，降低因實際記憶體超出當前預設範圍而導致 OOM 的風險（上文提到，對於非序列化對象的記憶體採樣估算會產生誤差）。值得注意的是，這個預留的保險地區僅僅是一種邏輯上的規劃，在具體使用時 Spark 並沒有區別對待，和"其它記憶體"一樣交給了 JVM 去管理。

堆外的空間分配較為簡單，只有儲存記憶體和執行記憶體， 3 所示。可用的執行記憶體和儲存記憶體佔用的空間大小直接由參數 spark.memory.storageFraction 決定，由於堆外記憶體佔用的空間可以被精確計算，所以無需再設定保險地區。

圖 3 . 靜態記憶體管理圖示——堆外

 

靜態記憶體管理機制實現起來較為簡單，但如果使用者不熟悉 Spark 的儲存機制，或沒有根據具體的資料規模和計算任務或做相應的配置，很容易造成"一半海水，一半火焰"的局面，即儲存記憶體和執行記憶體中的一方剩餘大量的空間，而另一方卻早早被佔滿，不得不淘汰或移出舊的內容以儲存新的內容。由於新的記憶體管理機制的出現，這種方式目前已經很少有開發人員使用，出於相容舊版本的應用程式的目的，Spark 仍然保留了它的實現。

2.2 統一記憶體管理

Spark 1.6 之後引入的統一記憶體管理機制，與靜態記憶體管理的區別在於儲存記憶體和執行記憶體共用同一塊空間，可以動態佔用對方的空閑地區， 4 和圖 5 所示

圖 4 . 統一記憶體管理圖示——堆內

 圖 5 . 統一記憶體管理圖示——堆外

 

其中最重要的最佳化在於動態佔用機制，其規則如下：

• 設定基本的儲存記憶體和執行記憶體地區（spark.storage.storageFraction 參數），該設定確定了雙方各自擁有的空間的範圍
• 雙方的空間都不足時，則儲存到硬碟；若己方空間不足而對方空餘時，可借用對方的空間;（儲存空間不足是指不足以放下一個完整的 Block）
• 執行記憶體的空間被對方佔用後，可讓對方將佔用的部分轉存到硬碟，然後"歸還"借用的空間
• 儲存記憶體的空間被對方佔用後，無法讓對方"歸還"，因為需要考慮 Shuffle 過程中的很多因素，實現起來較為複雜[4]

圖 6 . 動態佔用機製圖示

 

憑藉統一記憶體管理機制，Spark 在一定程度上提高了堆內和堆外記憶體資源的利用率，降低了開發人員維護 Spark 記憶體的難度，但並不意味著開發人員可以高枕無憂。譬如，所以如果儲存記憶體的空間太大或者說緩衝的資料過多，反而會導致頻繁的全量記憶體回收，降低任務執行時的效能，因為緩衝的 RDD 資料通常都是長期駐留記憶體的 [5] 。所以要想充分發揮 Spark 的效能，需要開發人員進一步瞭解儲存記憶體和執行記憶體各自的管理方式和實現原理。

3. 儲存記憶體管理3.1 RDD 的持久化機制

彈性分布式資料集（RDD）作為 Spark 最根本的資料抽象，是唯讀分區記錄（Partition）的集合，只能基於在穩定實體儲存體中的資料集上建立，或者在其他已有的 RDD 上執行轉換（Transformation）操作產生一個新的 RDD。轉換後的 RDD 與原始的 RDD 之間產生的依賴關係，構成了血統（Lineage）。憑藉血統，Spark 保證了每一個 RDD 都可以被重新恢複。但 RDD 的所有轉換都是惰性的，即只有當一個返回結果給 Driver 的行動（Action）發生時，Spark 才會建立任務讀取 RDD，然後真正觸發轉換的執行。
Task 在啟動之初讀取一個分區時，會先判斷這個分區是否已經被持久化，如果沒有則需要檢查 Checkpoint 或按照血統重新計算。所以如果一個 RDD 上要執行多次行動，可以在第一次行動中使用 persist 或 cache 方法，在記憶體或磁碟中持久化或緩衝這個 RDD，從而在後面的行動時提升計算速度。事實上，cache 方法是使用預設的 MEMORY_ONLY 的儲存層級將 RDD 持久化到記憶體，故緩衝是一種特殊的持久化。 堆內和堆外儲存記憶體的設計，便可以對緩衝 RDD 時使用的記憶體做統一的規劃和管 理 （儲存記憶體的其他應用情境，如緩衝 broadcast 資料，暫時不在本文的討論範圍之內）。

RDD 的持久化由 Spark 的 Storage 模組 [7] 負責，實現了 RDD 與實體儲存體的解耦合。Storage 模組負責管理 Spark 在計算過程中產生的資料，將那些在記憶體或磁碟、在本地或遠程存取資料的功能封裝了起來。在具體實現時 Driver 端和 Executor 端的 Storage 模組構成了主從式的架構，即 Driver 端的 BlockManager 為 Master，Executor 端的 BlockManager 為 Slave。Storage 模組在邏輯上以 Block 為基本存放裝置單位，RDD 的每個 Partition 經過處理後唯一對應一個 Block（BlockId 的格式為 rdd_RDD-ID_PARTITION-ID ）。Master 負責整個 Spark 應用程式的 Block 的中繼資料資訊的管理和維護，而 Slave 需要將 Block 的更新等狀態上報到 Master，同時接收 Master 的命令，例如新增或刪除一個 RDD。

圖 7 . Storage 模組

 

在對 RDD 持久化時，Spark 規定了 MEMORY_ONLY、MEMORY_AND_DISK 等 7 種不同的 儲存層級 ，而儲存層級是以下 5 個變數的組合：

清單 3 . 儲存層級

1234567

class StorageLevel private(private var _useDisk: Boolean, //磁碟private var _useMemory: Boolean, //這裡其實是指堆內記憶體private var _useOffHeap: Boolean, //堆外記憶體private var _deserialized: Boolean, //是否為非序列化private var _replication: Int = 1 //副本個數)

通過對資料結構的分析，可以看出儲存層級從三個維度定義了 RDD 的 Partition（同時也就是 Block）的儲存方式：

• 儲存位置：磁碟／堆內記憶體／堆外記憶體。如 MEMORY_AND_DISK 是同時在磁碟和堆內記憶體上儲存，實現了冗餘備份。OFF_HEAP 則是只在堆外記憶體儲存，目前選擇堆外記憶體時不能同時儲存到其他位置。
• 儲存形式：Block 緩衝到儲存記憶體後，是否為非序列化的形式。如 MEMORY_ONLY 是非序列化方式儲存，OFF_HEAP 是序列化方式儲存。
• 副本數量：大於 1 時需要遠程冗餘備份到其他節點。如 DISK_ONLY_2 需要遠程備份 1 個副本。

3.2 RDD 緩衝的過程

RDD 在緩衝到儲存記憶體之前，Partition 中的資料一般以迭代器（Iterator）的資料結構來訪問，這是 Scala 語言中一種遍曆資料集合的方法。通過 Iterator 可以擷取分區中每一條序列化或者非序列化的資料項目(Record)，這些 Record 的對象執行個體在邏輯上佔用了 JVM 堆內記憶體的 other 部分的空間，同一 Partition 的不同 Record 的空間並不連續。

RDD 在緩衝到儲存記憶體之後，Partition 被轉換成 Block，Record 在堆內或堆外儲存記憶體中佔用一塊連續的空間。將Partition由不連續的儲存空間轉換為連續儲存空間的過程，Spark稱之為"展開"（Unroll）。Block 有序列化和非序列化兩種儲存格式，具體以哪種方式取決於該 RDD 的儲存層級。非序列化的 Block 以一種 DeserializedMemoryEntry 的資料結構定義，用一個數組儲存所有的對象執行個體，序列化的 Block 則以 SerializedMemoryEntry的資料結構定義，用位元組緩衝區（ByteBuffer）來儲存位元據。每個 Executor 的 Storage 模組用一個鏈式 Map 結構（LinkedHashMap）來管理堆內和堆外儲存記憶體中所有的 Block 對象的執行個體[6]，對這個 LinkedHashMap 新增和刪除間接記錄了記憶體的申請和釋放。

因為不能保證儲存空間可以一次容納 Iterator 中的所有資料，當前的計算任務在 Unroll 時要向 MemoryManager 申請足夠的 Unroll 空間來臨時佔位，空間不足則 Unroll 失敗，空間足夠時可以繼續進行。對於序列化的 Partition，其所需的 Unroll 空間可以直接累加計算，一次申請。而非序列化的 Partition 則要在遍曆 Record 的過程中依次申請，即每讀取一條 Record，採樣估算其所需的 Unroll 空間並進行申請，空間不足時可以中斷，釋放已佔用的 Unroll 空間。如果最終 Unroll 成功，當前 Partition 所佔用的 Unroll 空間被轉換為正常的緩衝 RDD 的儲存空間，如 8 所示。

圖 8. Spark Unroll

 

在圖 3 和圖 5 中可以看到，在靜態記憶體管理時，Spark 在儲存記憶體中專門劃分了一塊 Unroll 空間，其大小是固定的，統一記憶體管理時則沒有對 Unroll 空間進行特別區分，當儲存空間不足時會根據動態佔用機制進行處理。

3.3 淘汰和落盤

由於同一個 Executor 的所有的計算任務共用有限的儲存記憶體空間，當有新的 Block 需要緩衝但是剩餘空間不足且無法動態佔用時，就要對 LinkedHashMap 中的舊 Block 進行淘汰（Eviction），而被淘汰的 Block 如果其儲存層級中同時包含儲存到磁碟的要求，則要對其進行落盤（Drop），否則直接刪除該 Block。

儲存記憶體的淘汰規則為：

• 被淘汰的舊 Block 要與新 Block 的 MemoryMode 相同，即同屬於堆外或堆內記憶體
• 新舊 Block 不能屬於同一個 RDD，避免迴圈淘汰
• 舊 Block 所屬 RDD 不能處於被讀狀態，避免引發一致性問題
• 遍曆 LinkedHashMap 中 Block，按照最近最少使用（LRU）的順序淘汰，直到滿足新 Block 所需的空間。其中 LRU 是 LinkedHashMap 的特性。

落盤的流程則比較簡單，如果其儲存層級符合_useDisk 為 true 的條件，再根據其_deserialized 判斷是否是非序列化的形式，若是則對其進行序列化，最後將資料存放區到磁碟，在 Storage 模組中更新其資訊。

4. 執行記憶體管理4.1 多任務間記憶體配置

Executor 內啟動並執行任務同樣共用執行記憶體，Spark 用一個 HashMap 結構儲存了任務到記憶體耗費的映射。每個任務可佔用的執行記憶體大小的範圍為 1/2N ~ 1/N，其中 N 為當前 Executor 內正在啟動並執行任務的個數。每個任務在啟動之時，要向 MemoryManager 請求申請最少為 1/2N 的執行記憶體，如果不能被滿足要求則該任務被阻塞，直到有其他任務釋放了足夠的執行記憶體，該任務才可以被喚醒。

4.2 Shuffle 的記憶體佔用

執行記憶體主要用來儲存任務在執行 Shuffle 時佔用的記憶體，Shuffle 是按照一定規則對 RDD 資料重新分區的過程，我們來看 Shuffle 的 Write 和 Read 兩階段對執行記憶體的使用：

• Shuffle Write

1. 若在 map 端選擇普通的排序方式，會採用 ExternalSorter 進行外排，在記憶體中儲存資料時主要佔用堆內執行空間。
2. 若在 map 端選擇 Tungsten 的排序方式，則採用 ShuffleExternalSorter 直接對以序列化形式儲存的資料排序，在記憶體中儲存資料時可以佔用堆外或堆內執行空間，取決於使用者是否開啟了堆外記憶體以及堆外執行記憶體是否足夠。

• Shuffle Read

1. 在對 reduce 端的資料進行彙總時，要將資料交給 Aggregator 處理，在記憶體中儲存資料時佔用堆內執行空間。
2. 如果需要進行最終結果排序，則要將再次將資料交給 ExternalSorter 處理，佔用堆內執行空間。

在 ExternalSorter 和 Aggregator 中，Spark 會使用一種叫 AppendOnlyMap 的雜湊表在堆內執行記憶體中儲存資料，但在 Shuffle 過程中所有資料並不能都儲存到該雜湊表中，當這個雜湊表佔用的記憶體會進行周期性地採樣估算，當其大到一定程度，無法再從 MemoryManager 申請到新的執行記憶體時，Spark 就會將其全部內容儲存到磁碟檔案中，這個過程被稱為溢存(Spill)，溢存到磁碟的檔案最後會被歸併(Merge)。

Shuffle Write 階段中用到的 Tungsten 是 Databricks 公司提出的對 Spark 最佳化記憶體和 CPU 使用的計劃[9]，解決了一些 JVM 在效能上的限制和弊端。Spark 會根據 Shuffle 的情況來自動選擇是否採用 Tungsten 排序。Tungsten 採用的頁式記憶體管理機制建立在 MemoryManager 之上，即 Tungsten 對執行記憶體的使用進行了一步的抽象，這樣在 Shuffle 過程中無需關心資料具體儲存在堆內還是堆外。每個記憶體頁用一個 MemoryBlock 來定義，並用 Object obj 和 long offset 這兩個變數統一標識一個記憶體頁在系統記憶體中的地址。堆內的 MemoryBlock 是以 long 型數組的形式分配的記憶體，其 obj 的值為是這個數組的對象引用，offset 是 long 型數組的在 JVM 中的初始位移地址，兩者配合使用可以定位這個數組在堆內的絕對位址；堆外的 MemoryBlock 是直接申請到的記憶體塊，其 obj 為 null，offset 是這個記憶體塊在系統記憶體中的 64 位元絕對位址。Spark 用 MemoryBlock 巧妙地將堆內和堆外記憶體頁統一抽象封裝，並用頁表(pageTable)管理每個 Task 申請到的記憶體頁。

Tungsten 頁式管理下的所有記憶體用 64 位元的邏輯地址表示，由頁號和頁內位移量組成：

• 頁號：占 13 位，唯一標識一個記憶體頁，Spark 在申請記憶體頁之前要先申請空閑頁號。
• 頁內位移量：占 51 位，是在使用記憶體頁儲存資料時，資料在頁內的位移地址。

有了統一的定址方式，Spark 可以用 64 位元邏輯地址的指標定位到堆內或堆外的記憶體，整個 Shuffle Write 排序的過程只需要對指標進行排序，並且無需還原序列化，整個過程非常高效，對於記憶體訪問效率和 CPU 使用效率帶來了明顯的提升[10]。

Spark 的儲存記憶體和執行記憶體有著截然不同的管理方式：對於儲存記憶體來說，Spark 用一個 LinkedHashMap 來集中管理所有的 Block，Block 由需要緩衝的 RDD 的 Partition 轉化而成；而對於執行記憶體，Spark 用 AppendOnlyMap 來儲存 Shuffle 過程中的資料，在 Tungsten 排序中甚至抽象成為頁式記憶體管理，開闢了全新的 JVM 記憶體管理機制。

結束語

Spark 的記憶體管理是一套複雜的機制，且 Spark 的版本更新比較快，筆者水平有限，難免有敘述不清、錯誤的地方，若讀者有好的建議和更深的理解，還望不吝賜教。

參考資源

1. Spark Cluster Mode Overview
2. Spark Sort Based Shuffle 記憶體分析
3. Spark OFF_HEAP
4. Unified Memory Management in Spark 1.6
5. Tuning Spark: Garbage Collection Tuning
6. Spark Architecture
7. 《Spark 技術內幕：深入解析 Spark 核心架構於實現原理》第 8 章 Storage 模組詳解
8. Spark Sort Based Shuffle 記憶體分析
9. Project Tungsten: Bringing Apache Spark Closer to Bare Metal
10. Spark Tungsten-sort Based Shuffle 分析
11. 探索  Spark Tungsten  的秘密
12. Spark Task 記憶體管理（on-heap&off-heap）

Apache Spark 記憶體管理詳解