Apache Spark 內(nèi)存管理詳解

Spark 作為一個基于內(nèi)存的分布式計算引擎彪标,其內(nèi)存管理模塊在整個系統(tǒng)中扮演著非常重要的角色。理解 Spark 內(nèi)存管理的基本原理屑咳,有助于更好地開發(fā) Spark 應(yīng)用程序和進行性能調(diào)優(yōu)道盏。本文旨在梳理出 Spark 內(nèi)存管理的脈絡(luò),拋磚引玉苟耻,引出讀者對這個話題的深入探討。本文中闡述的原理基于 Spark 2.1 版本扶檐,閱讀本文需要讀者有一定的 Spark 和 Java 基礎(chǔ)凶杖,了解 RDD、Shuffle款筑、JVM 等相關(guān)概念智蝠。

在執(zhí)行 Spark 的應(yīng)用程序時腾么,Spark 集群會啟動 Driver 和 Executor 兩種 JVM 進程,前者為主控進程杈湾,負責(zé)創(chuàng)建 Spark 上下文哮翘,提交 Spark 作業(yè)(Job),并將作業(yè)轉(zhuǎn)化為計算任務(wù)(Task)毛秘,在各個 Executor 進程間協(xié)調(diào)任務(wù)的調(diào)度,后者負責(zé)在工作節(jié)點上執(zhí)行具體的計算任務(wù)阻课,并將結(jié)果返回給 Driver叫挟,同時為需要持久化的 RDD 提供存儲功能。由于 Driver 的內(nèi)存管理相對來說較為簡單限煞,本文主要對 Executor 的內(nèi)存管理進行分析抹恳,下文中的 Spark 內(nèi)存均特指 Executor 的內(nèi)存。

1. 堆內(nèi)和堆外內(nèi)存規(guī)劃

作為一個 JVM 進程署驻,Executor 的內(nèi)存管理建立在 JVM 的內(nèi)存管理之上奋献,Spark 對 JVM 的堆內(nèi)(On-heap)空間進行了更為詳細的分配,以充分利用內(nèi)存旺上。同時瓶蚂,Spark 引入了堆外(Off-heap)內(nèi)存,使之可以直接在工作節(jié)點的系統(tǒng)內(nèi)存中開辟空間宣吱,進一步優(yōu)化了內(nèi)存的使用窃这。

圖 1 . 堆內(nèi)和堆外內(nèi)存示意圖


1.1 堆內(nèi)內(nèi)存

堆內(nèi)內(nèi)存的大小,由 Spark 應(yīng)用程序啟動時的 –executor-memory 或 spark.executor.memory 參數(shù)配置征候。Executor 內(nèi)運行的并發(fā)任務(wù)共享 JVM 堆內(nèi)內(nèi)存杭攻,這些任務(wù)在緩存 RDD 數(shù)據(jù)和廣播(Broadcast)數(shù)據(jù)時占用的內(nèi)存被規(guī)劃為存儲(Storage)內(nèi)存,而這些任務(wù)在執(zhí)行 Shuffle 時占用的內(nèi)存被規(guī)劃為執(zhí)行(Execution)內(nèi)存疤坝,剩余的部分不做特殊規(guī)劃兆解,那些 Spark 內(nèi)部的對象實例,或者用戶定義的 Spark 應(yīng)用程序中的對象實例跑揉,均占用剩余的空間锅睛。不同的管理模式下,這三部分占用的空間大小各不相同(下面第 2 小節(jié)會進行介紹)历谍。

Spark 對堆內(nèi)內(nèi)存的管理是一種邏輯上的"規(guī)劃式"的管理衣撬,因為對象實例占用內(nèi)存的申請和釋放都由 JVM 完成,Spark 只能在申請后和釋放前記錄這些內(nèi)存扮饶,我們來看其具體流程:

  • 申請內(nèi)存:
  1. Spark 在代碼中 new 一個對象實例
  2. JVM 從堆內(nèi)內(nèi)存分配空間具练,創(chuàng)建對象并返回對象引用
  3. Spark 保存該對象的引用,記錄該對象占用的內(nèi)存
  • 釋放內(nèi)存:
  1. Spark 記錄該對象釋放的內(nèi)存甜无,刪除該對象的引用
  2. 等待 JVM 的垃圾回收機制釋放該對象占用的堆內(nèi)內(nèi)存

我們知道扛点,JVM 的對象可以以序列化的方式存儲哥遮,序列化的過程是將對象轉(zhuǎn)換為二進制字節(jié)流,本質(zhì)上可以理解為將非連續(xù)空間的鏈?zhǔn)酱鎯D(zhuǎn)化為連續(xù)空間或塊存儲陵究,在訪問時則需要進行序列化的逆過程——反序列化眠饮,將字節(jié)流轉(zhuǎn)化為對象,序列化的方式可以節(jié)省存儲空間铜邮,但增加了存儲和讀取時候的計算開銷仪召。

對于 Spark 中序列化的對象,由于是字節(jié)流的形式松蒜,其占用的內(nèi)存大小可直接計算扔茅,而對于非序列化的對象,其占用的內(nèi)存是通過周期性地采樣近似估算而得秸苗,即并不是每次新增的數(shù)據(jù)項都會計算一次占用的內(nèi)存大小召娜,這種方法降低了時間開銷但是有可能誤差較大,導(dǎo)致某一時刻的實際內(nèi)存有可能遠遠超出預(yù)期[2]惊楼。此外玖瘸,在被 Spark 標(biāo)記為釋放的對象實例,很有可能在實際上并沒有被 JVM 回收檀咙,導(dǎo)致實際可用的內(nèi)存小于 Spark 記錄的可用內(nèi)存雅倒。所以 Spark 并不能準(zhǔn)確記錄實際可用的堆內(nèi)內(nèi)存,從而也就無法完全避免內(nèi)存溢出(OOM, Out of Memory)的異常弧可。

雖然不能精準(zhǔn)控制堆內(nèi)內(nèi)存的申請和釋放屯断,但 Spark 通過對存儲內(nèi)存和執(zhí)行內(nèi)存各自獨立的規(guī)劃管理,可以決定是否要在存儲內(nèi)存里緩存新的 RDD侣诺,以及是否為新的任務(wù)分配執(zhí)行內(nèi)存殖演,在一定程度上可以提升內(nèi)存的利用率,減少異常的出現(xiàn)年鸳。

1.2 堆外內(nèi)存

為了進一步優(yōu)化內(nèi)存的使用以及提高 Shuffle 時排序的效率趴久,Spark 引入了堆外(Off-heap)內(nèi)存,使之可以直接在工作節(jié)點的系統(tǒng)內(nèi)存中開辟空間搔确,存儲經(jīng)過序列化的二進制數(shù)據(jù)彼棍。利用 JDK Unsafe API(從 Spark 2.0 開始,在管理堆外的存儲內(nèi)存時不再基于 Tachyon膳算,而是與堆外的執(zhí)行內(nèi)存一樣座硕,基于 JDK Unsafe API 實現(xiàn)[3]),Spark 可以直接操作系統(tǒng)堆外內(nèi)存涕蜂,減少了不必要的內(nèi)存開銷华匾,以及頻繁的 GC 掃描和回收,提升了處理性能机隙。堆外內(nèi)存可以被精確地申請和釋放蜘拉,而且序列化的數(shù)據(jù)占用的空間可以被精確計算萨西,所以相比堆內(nèi)內(nèi)存來說降低了管理的難度,也降低了誤差旭旭。

在默認情況下堆外內(nèi)存并不啟用谎脯,可通過配置 spark.memory.offHeap.enabled 參數(shù)啟用,并由 spark.memory.offHeap.size 參數(shù)設(shè)定堆外空間的大小持寄。除了沒有 other 空間源梭,堆外內(nèi)存與堆內(nèi)內(nèi)存的劃分方式相同,所有運行中的并發(fā)任務(wù)共享存儲內(nèi)存和執(zhí)行內(nèi)存稍味。

1.3 內(nèi)存管理接口

Spark 為存儲內(nèi)存和執(zhí)行內(nèi)存的管理提供了統(tǒng)一的接口——MemoryManager废麻,同一個 Executor 內(nèi)的任務(wù)都調(diào)用這個接口的方法來申請或釋放內(nèi)存:

清單 1 . 內(nèi)存管理接口的主要方法

//申請存儲內(nèi)存
def acquireStorageMemory(blockId: BlockId, numBytes: Long, memoryMode: MemoryMode): Boolean
//申請展開內(nèi)存
def acquireUnrollMemory(blockId: BlockId, numBytes: Long, memoryMode: MemoryMode): Boolean
//申請執(zhí)行內(nèi)存
def acquireExecutionMemory(numBytes: Long, taskAttemptId: Long, memoryMode: MemoryMode): Long
//釋放存儲內(nèi)存
def releaseStorageMemory(numBytes: Long, memoryMode: MemoryMode): Unit
//釋放執(zhí)行內(nèi)存
def releaseExecutionMemory(numBytes: Long, taskAttemptId: Long, memoryMode: MemoryMode): Unit
//釋放展開內(nèi)存
def releaseUnrollMemory(numBytes: Long, memoryMode: MemoryMode): Unit

MemoryManager 的具體實現(xiàn)上,Spark 1.6 之后默認為統(tǒng)一管理(Unified Memory Manager)方式仲闽,1.6 之前采用的靜態(tài)管理(Static Memory Manager)方式仍被保留,可通過配置 spark.memory.useLegacyMode 參數(shù)啟用僵朗。兩種方式的區(qū)別在于對空間分配的方式赖欣,下面的第 2 小節(jié)會分別對這兩種方式進行介紹。

2 . 內(nèi)存空間分配

2.1 靜態(tài)內(nèi)存管理

在 Spark 最初采用的靜態(tài)內(nèi)存管理機制下验庙,存儲內(nèi)存、執(zhí)行內(nèi)存和其他內(nèi)存的大小在 Spark 應(yīng)用程序運行期間均為固定的,但用戶可以應(yīng)用程序啟動前進行配置出牧,堆內(nèi)內(nèi)存的分配如圖 2 所示:

圖 2 . 靜態(tài)內(nèi)存管理圖示——堆內(nèi)

清單 2 . 可用堆內(nèi)內(nèi)存空間

可用的存儲內(nèi)存 = systemMaxMemory * spark.storage.memoryFraction * spark.storage.safetyFraction
可用的執(zhí)行內(nèi)存 = systemMaxMemory * spark.shuffle.memoryFraction * spark.shuffle.safetyFraction

其中 systemMaxMemory 取決于當(dāng)前 JVM 堆內(nèi)內(nèi)存的大小寇钉,最后可用的執(zhí)行內(nèi)存或者存儲內(nèi)存要在此基礎(chǔ)上與各自的 memoryFraction 參數(shù)和 safetyFraction 參數(shù)相乘得出。上述計算公式中的兩個 safetyFraction 參數(shù)违寿,其意義在于在邏輯上預(yù)留出 1-safetyFraction 這么一塊保險區(qū)域湃交,降低因?qū)嶋H內(nèi)存超出當(dāng)前預(yù)設(shè)范圍而導(dǎo)致 OOM 的風(fēng)險(上文提到,對于非序列化對象的內(nèi)存采樣估算會產(chǎn)生誤差)藤巢。值得注意的是搞莺,這個預(yù)留的保險區(qū)域僅僅是一種邏輯上的規(guī)劃,在具體使用時 Spark 并沒有區(qū)別對待掂咒,和"其它內(nèi)存"一樣交給了 JVM 去管理才沧。

堆外的空間分配較為簡單,只有存儲內(nèi)存和執(zhí)行內(nèi)存绍刮,如圖 3 所示温圆。可用的執(zhí)行內(nèi)存和存儲內(nèi)存占用的空間大小直接由參數(shù) spark.memory.storageFraction 決定孩革,由于堆外內(nèi)存占用的空間可以被精確計算岁歉,所以無需再設(shè)定保險區(qū)域。

圖 3 . 靜態(tài)內(nèi)存管理圖示——堆外

靜態(tài)內(nèi)存管理機制實現(xiàn)起來較為簡單膝蜈,但如果用戶不熟悉 Spark 的存儲機制刨裆,或沒有根據(jù)具體的數(shù)據(jù)規(guī)模和計算任務(wù)或做相應(yīng)的配置澈圈,很容易造成"一半海水,一半火焰"的局面帆啃,即存儲內(nèi)存和執(zhí)行內(nèi)存中的一方剩余大量的空間瞬女,而另一方卻早早被占滿,不得不淘汰或移出舊的內(nèi)容以存儲新的內(nèi)容努潘。由于新的內(nèi)存管理機制的出現(xiàn)诽偷,這種方式目前已經(jīng)很少有開發(fā)者使用,出于兼容舊版本的應(yīng)用程序的目的疯坤,Spark 仍然保留了它的實現(xiàn)报慕。

2.2 統(tǒng)一內(nèi)存管理

Spark 1.6 之后引入的統(tǒng)一內(nèi)存管理機制,與靜態(tài)內(nèi)存管理的區(qū)別在于存儲內(nèi)存和執(zhí)行內(nèi)存共享同一塊空間压怠,可以動態(tài)占用對方的空閑區(qū)域眠冈,如圖 4 和圖 5 所示

圖 4 . 統(tǒng)一內(nèi)存管理圖示——堆內(nèi)
圖 5 . 統(tǒng)一內(nèi)存管理圖示——堆外

其中最重要的優(yōu)化在于動態(tài)占用機制,其規(guī)則如下:

  • 設(shè)定基本的存儲內(nèi)存和執(zhí)行內(nèi)存區(qū)域(spark.storage.storageFraction 參數(shù))菌瘫,該設(shè)定確定了雙方各自擁有的空間的范圍
  • 雙方的空間都不足時蜗顽,則存儲到硬盤;若己方空間不足而對方空余時雨让,可借用對方的空間;(存儲空間不足是指不足以放下一個完整的 Block)
  • 執(zhí)行內(nèi)存的空間被對方占用后雇盖,可讓對方將占用的部分轉(zhuǎn)存到硬盤,然后"歸還"借用的空間
  • 存儲內(nèi)存的空間被對方占用后栖忠,無法讓對方"歸還"崔挖,因為需要考慮 Shuffle 過程中的很多因素,實現(xiàn)起來較為復(fù)雜
圖 6 . 動態(tài)占用機制圖示

憑借統(tǒng)一內(nèi)存管理機制庵寞,Spark 在一定程度上提高了堆內(nèi)和堆外內(nèi)存資源的利用率狸相,降低了開發(fā)者維護 Spark 內(nèi)存的難度,但并不意味著開發(fā)者可以高枕無憂捐川。譬如卷哩,所以如果存儲內(nèi)存的空間太大或者說緩存的數(shù)據(jù)過多,反而會導(dǎo)致頻繁的全量垃圾回收属拾,降低任務(wù)執(zhí)行時的性能将谊,因為緩存的 RDD 數(shù)據(jù)通常都是長期駐留內(nèi)存的 [5] 。所以要想充分發(fā)揮 Spark 的性能渐白,需要開發(fā)者進一步了解存儲內(nèi)存和執(zhí)行內(nèi)存各自的管理方式和實現(xiàn)原理尊浓。

3. 存儲內(nèi)存管理

3.1 RDD 的持久化機制

彈性分布式數(shù)據(jù)集(RDD)作為 Spark 最根本的數(shù)據(jù)抽象,是只讀的分區(qū)記錄(Partition)的集合纯衍,只能基于在穩(wěn)定物理存儲中的數(shù)據(jù)集上創(chuàng)建栋齿,或者在其他已有的 RDD 上執(zhí)行轉(zhuǎn)換(Transformation)操作產(chǎn)生一個新的 RDD。轉(zhuǎn)換后的 RDD 與原始的 RDD 之間產(chǎn)生的依賴關(guān)系,構(gòu)成了血統(tǒng)(Lineage)瓦堵。憑借血統(tǒng)基协,Spark 保證了每一個 RDD 都可以被重新恢復(fù)。但 RDD 的所有轉(zhuǎn)換都是惰性的菇用,即只有當(dāng)一個返回結(jié)果給 Driver 的行動(Action)發(fā)生時澜驮,Spark 才會創(chuàng)建任務(wù)讀取 RDD,然后真正觸發(fā)轉(zhuǎn)換的執(zhí)行惋鸥。
Task 在啟動之初讀取一個分區(qū)時杂穷,會先判斷這個分區(qū)是否已經(jīng)被持久化,如果沒有則需要檢查 Checkpoint 或按照血統(tǒng)重新計算卦绣。所以如果一個 RDD 上要執(zhí)行多次行動耐量,可以在第一次行動中使用 persist 或 cache 方法,在內(nèi)存或磁盤中持久化或緩存這個 RDD滤港,從而在后面的行動時提升計算速度廊蜒。事實上,cache 方法是使用默認的 MEMORY_ONLY 的存儲級別將 RDD 持久化到內(nèi)存溅漾,故緩存是一種特殊的持久化山叮。 堆內(nèi)和堆外存儲內(nèi)存的設(shè)計,便可以對緩存 RDD 時使用的內(nèi)存做統(tǒng)一的規(guī)劃和管理(存儲內(nèi)存的其他應(yīng)用場景樟凄,如緩存 broadcast 數(shù)據(jù)聘芜,暫時不在本文的討論范圍之內(nèi))兄渺。

RDD 的持久化由 Spark 的 Storage 模塊 [7] 負責(zé)缝龄,實現(xiàn)了 RDD 與物理存儲的解耦合。Storage 模塊負責(zé)管理 Spark 在計算過程中產(chǎn)生的數(shù)據(jù)挂谍,將那些在內(nèi)存或磁盤叔壤、在本地或遠程存取數(shù)據(jù)的功能封裝了起來。在具體實現(xiàn)時 Driver 端和 Executor 端的 Storage 模塊構(gòu)成了主從式的架構(gòu)口叙,即 Driver 端的 BlockManager 為 Master炼绘,Executor 端的 BlockManager 為 Slave。Storage 模塊在邏輯上以 Block 為基本存儲單位妄田,RDD 的每個 Partition 經(jīng)過處理后唯一對應(yīng)一個 Block(BlockId 的格式為 rdd_RDD-ID_PARTITION-ID )俺亮。Master 負責(zé)整個 Spark 應(yīng)用程序的 Block 的元數(shù)據(jù)信息的管理和維護,而 Slave 需要將 Block 的更新等狀態(tài)上報到 Master疟呐,同時接收 Master 的命令脚曾,例如新增或刪除一個 RDD。

圖 7 . Storage 模塊示意圖


在對 RDD 持久化時启具,Spark 規(guī)定了 MEMORY_ONLY本讥、MEMORY_AND_DISK 等 7 種不同的 存儲級別 ,而存儲級別是以下 5 個變量的組合:

清單 3 . 存儲級別
class StorageLevel private(
private var _useDisk: Boolean, //磁盤
private var _useMemory: Boolean, //這里其實是指堆內(nèi)內(nèi)存
private var _useOffHeap: Boolean, //堆外內(nèi)存
private var _deserialized: Boolean, //是否為非序列化
private var _replication: Int = 1 //副本個數(shù)
)

通過對數(shù)據(jù)結(jié)構(gòu)的分析,可以看出存儲級別從三個維度定義了 RDD 的 Partition(同時也就是 Block)的存儲方式:

  • 存儲位置:磁盤/堆內(nèi)內(nèi)存/堆外內(nèi)存拷沸。如 MEMORY_AND_DISK 是同時在磁盤和堆內(nèi)內(nèi)存上存儲色查,實現(xiàn)了冗余備份。OFF_HEAP 則是只在堆外內(nèi)存存儲撞芍,目前選擇堆外內(nèi)存時不能同時存儲到其他位置秧了。
  • 存儲形式:Block 緩存到存儲內(nèi)存后,是否為非序列化的形式勤庐。如 MEMORY_ONLY 是非序列化方式存儲示惊,OFF_HEAP 是序列化方式存儲。
  • 副本數(shù)量:大于 1 時需要遠程冗余備份到其他節(jié)點愉镰。如 DISK_ONLY_2 需要遠程備份 1 個副本米罚。

3.2 RDD 緩存的過程

RDD 在緩存到存儲內(nèi)存之前,Partition 中的數(shù)據(jù)一般以迭代器(Iterator)的數(shù)據(jù)結(jié)構(gòu)來訪問丈探,這是 Scala 語言中一種遍歷數(shù)據(jù)集合的方法录择。通過 Iterator 可以獲取分區(qū)中每一條序列化或者非序列化的數(shù)據(jù)項(Record),這些 Record 的對象實例在邏輯上占用了 JVM 堆內(nèi)內(nèi)存的 other 部分的空間碗降,同一 Partition 的不同 Record 的空間并不連續(xù)隘竭。

RDD 在緩存到存儲內(nèi)存之后,Partition 被轉(zhuǎn)換成 Block讼渊,Record 在堆內(nèi)或堆外存儲內(nèi)存中占用一塊連續(xù)的空間动看。將Partition由不連續(xù)的存儲空間轉(zhuǎn)換為連續(xù)存儲空間的過程,Spark稱之為"展開"(Unroll)爪幻。Block 有序列化和非序列化兩種存儲格式菱皆,具體以哪種方式取決于該 RDD 的存儲級別。非序列化的 Block 以一種 DeserializedMemoryEntry 的數(shù)據(jù)結(jié)構(gòu)定義挨稿,用一個數(shù)組存儲所有的對象實例仇轻,序列化的 Block 則以 SerializedMemoryEntry的數(shù)據(jù)結(jié)構(gòu)定義,用字節(jié)緩沖區(qū)(ByteBuffer)來存儲二進制數(shù)據(jù)奶甘。每個 Executor 的 Storage 模塊用一個鏈?zhǔn)?Map 結(jié)構(gòu)(LinkedHashMap)來管理堆內(nèi)和堆外存儲內(nèi)存中所有的 Block 對象的實例篷店,對這個 LinkedHashMap 新增和刪除間接記錄了內(nèi)存的申請和釋放。

因為不能保證存儲空間可以一次容納 Iterator 中的所有數(shù)據(jù)臭家,當(dāng)前的計算任務(wù)在 Unroll 時要向 MemoryManager 申請足夠的 Unroll 空間來臨時占位疲陕,空間不足則 Unroll 失敗,空間足夠時可以繼續(xù)進行钉赁。對于序列化的 Partition蹄殃,其所需的 Unroll 空間可以直接累加計算,一次申請橄霉。而非序列化的 Partition 則要在遍歷 Record 的過程中依次申請窃爷,即每讀取一條 Record邑蒋,采樣估算其所需的 Unroll 空間并進行申請,空間不足時可以中斷按厘,釋放已占用的 Unroll 空間医吊。如果最終 Unroll 成功,當(dāng)前 Partition 所占用的 Unroll 空間被轉(zhuǎn)換為正常的緩存 RDD 的存儲空間逮京,如下圖 8 所示卿堂。

圖 8. Spark Unroll 示意圖


在圖 3 和圖 5 中可以看到,在靜態(tài)內(nèi)存管理時懒棉,Spark 在存儲內(nèi)存中專門劃分了一塊 Unroll 空間草描,其大小是固定的,統(tǒng)一內(nèi)存管理時則沒有對 Unroll 空間進行特別區(qū)分策严,當(dāng)存儲空間不足時會根據(jù)動態(tài)占用機制進行處理穗慕。

3.3 淘汰和落盤

由于同一個 Executor 的所有的計算任務(wù)共享有限的存儲內(nèi)存空間,當(dāng)有新的 Block 需要緩存但是剩余空間不足且無法動態(tài)占用時妻导,就要對 LinkedHashMap 中的舊 Block 進行淘汰(Eviction)逛绵,而被淘汰的 Block 如果其存儲級別中同時包含存儲到磁盤的要求,則要對其進行落盤(Drop)倔韭,否則直接刪除該 Block术浪。

存儲內(nèi)存的淘汰規(guī)則為:

  • 被淘汰的舊 Block 要與新 Block 的 MemoryMode 相同,即同屬于堆外或堆內(nèi)內(nèi)存
  • 新舊 Block 不能屬于同一個 RDD寿酌,避免循環(huán)淘汰
  • 舊 Block 所屬 RDD 不能處于被讀狀態(tài)胰苏,避免引發(fā)一致性問題
  • 遍歷 LinkedHashMap 中 Block,按照最近最少使用(LRU)的順序淘汰醇疼,直到滿足新 Block 所需的空間硕并。其中 LRU 是 LinkedHashMap 的特性。

落盤的流程則比較簡單僵腺,如果其存儲級別符合_useDisk 為 true 的條件鲤孵,再根據(jù)其_deserialized 判斷是否是非序列化的形式壶栋,若是則對其進行序列化辰如,最后將數(shù)據(jù)存儲到磁盤,在 Storage 模塊中更新其信息贵试。

4. 執(zhí)行內(nèi)存管理

4.1 多任務(wù)間內(nèi)存分配

Executor 內(nèi)運行的任務(wù)同樣共享執(zhí)行內(nèi)存琉兜,Spark 用一個 HashMap 結(jié)構(gòu)保存了任務(wù)到內(nèi)存耗費的映射。每個任務(wù)可占用的執(zhí)行內(nèi)存大小的范圍為 1/2N ~ 1/N毙玻,其中 N 為當(dāng)前 Executor 內(nèi)正在運行的任務(wù)的個數(shù)豌蟋。每個任務(wù)在啟動之時,要向 MemoryManager 請求申請最少為 1/2N 的執(zhí)行內(nèi)存桑滩,如果不能被滿足要求則該任務(wù)被阻塞梧疲,直到有其他任務(wù)釋放了足夠的執(zhí)行內(nèi)存,該任務(wù)才可以被喚醒。

4.2 Shuffle 的內(nèi)存占用

執(zhí)行內(nèi)存主要用來存儲任務(wù)在執(zhí)行 Shuffle 時占用的內(nèi)存幌氮,Shuffle 是按照一定規(guī)則對 RDD 數(shù)據(jù)重新分區(qū)的過程缭受,我們來看 Shuffle 的 Write 和 Read 兩階段對執(zhí)行內(nèi)存的使用:

  • Shuffle Write
  1. 若在 map 端選擇普通的排序方式,會采用 ExternalSorter 進行外排该互,在內(nèi)存中存儲數(shù)據(jù)時主要占用堆內(nèi)執(zhí)行空間米者。
  2. 若在 map 端選擇 Tungsten 的排序方式,則采用 ShuffleExternalSorter 直接對以序列化形式存儲的數(shù)據(jù)排序宇智,在內(nèi)存中存儲數(shù)據(jù)時可以占用堆外或堆內(nèi)執(zhí)行空間蔓搞,取決于用戶是否開啟了堆外內(nèi)存以及堆外執(zhí)行內(nèi)存是否足夠。
  • Shuffle Read
  1. 在對 reduce 端的數(shù)據(jù)進行聚合時随橘,要將數(shù)據(jù)交給 Aggregator 處理喂分,在內(nèi)存中存儲數(shù)據(jù)時占用堆內(nèi)執(zhí)行空間。
  2. 如果需要進行最終結(jié)果排序机蔗,則要將再次將數(shù)據(jù)交給 ExternalSorter 處理妻顶,占用堆內(nèi)執(zhí)行空間。

在 ExternalSorter 和 Aggregator 中蜒车,Spark 會使用一種叫 AppendOnlyMap 的哈希表在堆內(nèi)執(zhí)行內(nèi)存中存儲數(shù)據(jù)讳嘱,但在 Shuffle 過程中所有數(shù)據(jù)并不能都保存到該哈希表中,當(dāng)這個哈希表占用的內(nèi)存會進行周期性地采樣估算酿愧,當(dāng)其大到一定程度沥潭,無法再從 MemoryManager 申請到新的執(zhí)行內(nèi)存時,Spark 就會將其全部內(nèi)容存儲到磁盤文件中嬉挡,這個過程被稱為溢存(Spill)钝鸽,溢存到磁盤的文件最后會被歸并(Merge)。

Shuffle Write 階段中用到的 Tungsten 是 Databricks 公司提出的對 Spark 優(yōu)化內(nèi)存和 CPU 使用的計劃[9]庞钢,解決了一些 JVM 在性能上的限制和弊端拔恰。Spark 會根據(jù) Shuffle 的情況來自動選擇是否采用 Tungsten 排序。Tungsten 采用的頁式內(nèi)存管理機制建立在 MemoryManager 之上基括,即 Tungsten 對執(zhí)行內(nèi)存的使用進行了一步的抽象颜懊,這樣在 Shuffle 過程中無需關(guān)心數(shù)據(jù)具體存儲在堆內(nèi)還是堆外。每個內(nèi)存頁用一個 MemoryBlock 來定義风皿,并用 Object obj 和 long offset 這兩個變量統(tǒng)一標(biāo)識一個內(nèi)存頁在系統(tǒng)內(nèi)存中的地址河爹。堆內(nèi)的 MemoryBlock 是以 long 型數(shù)組的形式分配的內(nèi)存,其 obj 的值為是這個數(shù)組的對象引用桐款,offset 是 long 型數(shù)組的在 JVM 中的初始偏移地址咸这,兩者配合使用可以定位這個數(shù)組在堆內(nèi)的絕對地址;堆外的 MemoryBlock 是直接申請到的內(nèi)存塊魔眨,其 obj 為 null媳维,offset 是這個內(nèi)存塊在系統(tǒng)內(nèi)存中的 64 位絕對地址酿雪。Spark 用 MemoryBlock 巧妙地將堆內(nèi)和堆外內(nèi)存頁統(tǒng)一抽象封裝,并用頁表(pageTable)管理每個 Task 申請到的內(nèi)存頁侄刽。

Tungsten 頁式管理下的所有內(nèi)存用 64 位的邏輯地址表示执虹,由頁號和頁內(nèi)偏移量組成:

  1. 頁號:占 13 位,唯一標(biāo)識一個內(nèi)存頁唠梨,Spark 在申請內(nèi)存頁之前要先申請空閑頁號袋励。
  2. 頁內(nèi)偏移量:占 51 位,是在使用內(nèi)存頁存儲數(shù)據(jù)時当叭,數(shù)據(jù)在頁內(nèi)的偏移地址茬故。

有了統(tǒng)一的尋址方式,Spark 可以用 64 位邏輯地址的指針定位到堆內(nèi)或堆外的內(nèi)存蚁鳖,整個 Shuffle Write 排序的過程只需要對指針進行排序磺芭,并且無需反序列化,整個過程非常高效醉箕,對于內(nèi)存訪問效率和 CPU 使用效率帶來了明顯的提升[10]钾腺。

Spark 的存儲內(nèi)存和執(zhí)行內(nèi)存有著截然不同的管理方式:對于存儲內(nèi)存來說,Spark 用一個 LinkedHashMap 來集中管理所有的 Block讥裤,Block 由需要緩存的 RDD 的 Partition 轉(zhuǎn)化而成放棒;而對于執(zhí)行內(nèi)存,Spark 用 AppendOnlyMap 來存儲 Shuffle 過程中的數(shù)據(jù)己英,在 Tungsten 排序中甚至抽象成為頁式內(nèi)存管理间螟,開辟了全新的 JVM 內(nèi)存管理機制。

結(jié)束語

Spark 的內(nèi)存管理是一套復(fù)雜的機制损肛,且 Spark 的版本更新比較快厢破,筆者水平有限,難免有敘述不清治拿、錯誤的地方摩泪,若讀者有好的建議和更深的理解,還望不吝賜教劫谅。

參考:https://www.ibm.com/developerworks/cn/analytics/library/ba-cn-apache-spark-memory-management/index.html?ca=drs-&utm_source=tuicool&utm_medium=referral
https://github.com/hustnn/TungstenSecret/tree/master

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末见坑,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子同波,更是在濱河造成了極大的恐慌鳄梅,老刑警劉巖叠国,帶你破解...
    沈念sama閱讀 221,820評論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件未檩,死亡現(xiàn)場離奇詭異,居然都是意外死亡粟焊,警方通過查閱死者的電腦和手機冤狡,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,648評論 3 399
  • 文/潘曉璐 我一進店門孙蒙,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人悲雳,你說我怎么就攤上這事挎峦。” “怎么了合瓢?”我有些...
    開封第一講書人閱讀 168,324評論 0 360
  • 文/不壞的土叔 我叫張陵坦胶,是天一觀的道長。 經(jīng)常有香客問我晴楔,道長顿苇,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 59,714評論 1 297
  • 正文 為了忘掉前任税弃,我火速辦了婚禮纪岁,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘则果。我一直安慰自己幔翰,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 68,724評論 6 397
  • 文/花漫 我一把揭開白布西壮。 她就那樣靜靜地躺著遗增,像睡著了一般。 火紅的嫁衣襯著肌膚如雪款青。 梳的紋絲不亂的頭發(fā)上贡定,一...
    開封第一講書人閱讀 52,328評論 1 310
  • 那天,我揣著相機與錄音可都,去河邊找鬼缓待。 笑死,一個胖子當(dāng)著我的面吹牛渠牲,可吹牛的內(nèi)容都是我干的旋炒。 我是一名探鬼主播,決...
    沈念sama閱讀 40,897評論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼签杈,長吁一口氣:“原來是場噩夢啊……” “哼瘫镇!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起答姥,我...
    開封第一講書人閱讀 39,804評論 0 276
  • 序言:老撾萬榮一對情侶失蹤铣除,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后鹦付,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體尚粘,經(jīng)...
    沈念sama閱讀 46,345評論 1 318
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,431評論 3 340
  • 正文 我和宋清朗相戀三年敲长,在試婚紗的時候發(fā)現(xiàn)自己被綠了郎嫁。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片秉继。...
    茶點故事閱讀 40,561評論 1 352
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖泽铛,靈堂內(nèi)的尸體忽然破棺而出尚辑,到底是詐尸還是另有隱情,我是刑警寧澤盔腔,帶...
    沈念sama閱讀 36,238評論 5 350
  • 正文 年R本政府宣布杠茬,位于F島的核電站,受9級特大地震影響弛随,放射性物質(zhì)發(fā)生泄漏澈蝙。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,928評論 3 334
  • 文/蒙蒙 一撵幽、第九天 我趴在偏房一處隱蔽的房頂上張望灯荧。 院中可真熱鬧,春花似錦盐杂、人聲如沸逗载。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,417評論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽厉斟。三九已至,卻和暖如春强衡,著一層夾襖步出監(jiān)牢的瞬間擦秽,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,528評論 1 272
  • 我被黑心中介騙來泰國打工漩勤, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留感挥,地道東北人。 一個月前我還...
    沈念sama閱讀 48,983評論 3 376
  • 正文 我出身青樓越败,卻偏偏與公主長得像触幼,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子究飞,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,573評論 2 359

推薦閱讀更多精彩內(nèi)容