Spark 作為一個以擅長記憶體計算為優勢的計算引擎，記憶體管理方案是其非常重要的模組； Spark的記憶體可以大體歸為兩類：execution和storage，前者包括shuffles、joins、sorts和aggregations所需記憶體，後者包括cache和節點間資料傳輸所需記憶體；在Spark 1.5和之前版本里，兩者是靜態配置的，不支援借用，spark1.6 對記憶體管理模組進行了優化，通過記憶體空間的融合，消除以上限制，提供更好的效能。官方網站只是要求記憶體在8GB之上即可（Impala推薦要求機器配置在128GB）， 但spark job執行效率主要取決於：資料量大小，記憶體消耗，核心數（確定併發執行的task數量）

目錄：

•  基礎知識
• spark1.5- 記憶體管理
• spark1.6 記憶體管理

基本知識：

• on-heap memory：Java中分配的非空物件都是由Java虛擬機器的垃圾收集器管理的，也稱為堆內記憶體。虛擬機器會定期對垃圾記憶體進行回收，在某些特定的時間點，它會進行一次徹底的回收（full gc）。徹底回收時，垃圾收集器會對所有分配的堆內記憶體進行完整的掃描，這意味著一個重要的事實——這樣一次垃圾收集對Java應用造成的影響，跟堆的大小是成正比的。過大的堆會影響Java應用的效能
• off-heap memory：堆外記憶體意味著把記憶體物件分配在Java虛擬機器的堆以外的記憶體，這些記憶體直接受作業系統管理（而不是虛擬機器）。這樣做的結果就是能保持一個較小的堆，以減少垃圾收集對應用的影響
• LRU Cache（Least Recently Used）：LRU可以說是一種演算法，也可以算是一種原則，用來判斷如何從Cache中清除物件，而LRU就是“近期最少使用”原則，當Cache溢位時，最近最少使用的物件將被從Cache中清除
• spark 原始碼： https://github.com/apache/spark/releases
• scale ide for Intellij : http://plugins.jetbrains.com/plugin/?id=1347

Spark1.5- 記憶體管理：

• 1.6 版本引入了新的記憶體管理方案，配置引數： spark.memory.useLegacyMode 預設 false 表示使用新方案，true 表示使用舊方案， SparkEnv.scala 原始碼 如下圖：
•  
• 在staticMemoryManager.scala 類中檢視構造類及記憶體獲取定義
•       

• 通過程式碼推斷，若設定了 spark.testing.memory 則以該配置的值作為 systemMaxMemory，否則使用 JVM 最大記憶體作為 systemMaxMemory。
• spark.testing.memory 僅用於測試，一般不設定，所以這裡我們認為 systemMaxMemory 的值就是 executor 的最大可用記憶體
• Execution：用於快取shuffle、join、sort和aggregation的臨時資料，通過spark.shuffle.memoryFraction配置
• spark.shuffle.memoryFraction：shuffle 期間佔 executor 執行時記憶體的百分比，用小數表示。在任何時候，用於 shuffle 的記憶體總 size 不得超過這個限制，超出部分會 spill 到磁碟。如果經常 spill，考慮調大引數值
• spark.shuffle.safetyFraction：為防止 OOM，不能把 systemMaxMemory * spark.shuffle.memoryFraction 全用了，需要有個安全百分比
• 最終用於 execution 的記憶體量為：executor 最大可用記憶體* spark.shuffle.memoryFraction*spark.shuffle.safetyFraction，預設為 executor 最大可用記憶體 * 0.16
• execution記憶體被分配給JVM裡的多個task執行緒。
• task間的execution記憶體分配是動態的，如果沒有其他tasks存在，Spark允許一個task佔用所有可用execution記憶體

• storage記憶體分配分析過程與 Execution 一致，由上面的程式碼得出，用於storage 的記憶體量為: executor 最大可用記憶體 * spark.storage.memoryFraction * spark.storage.safetyFraction，預設為 executor 最大可用記憶體 * 0.54
• 在 storage 中，有一部分記憶體是給 unroll 使用的，unroll 即反序列化 block，該部分佔比由 spark.storage.unrollFraction 控制，預設為0.2

• 通過程式碼分析，storage 和 execution 總共使用了 80% 的記憶體，剩餘 20% 記憶體被系統保留了，用來儲存執行中產生的物件,該型別記憶體不可控.

小結：

• 這種記憶體管理方式的缺陷，即 execution 和 storage 記憶體表態分配，即使在一方記憶體不夠用而另一方記憶體空閒的情況下也不能共享，造成記憶體浪費，為解決這一問題，spark1.6 啟用新的記憶體管理方案UnifiedMemoryManager
• staticMemoryManager- jvm 堆記憶體分配圖如下
• 

Spark1.6 記憶體管理：

• 從spark1.6開始，引入了新的記憶體管理方式-----統一記憶體管理(UnifiedMemoryManager)，在統一記憶體管理下，spark一個executor中的jvm heap記憶體被劃分成如下圖:

• 
• Reserved Memory,這一部分的記憶體是我們無法使用的部分，spark內部保留記憶體，會儲存一些spark的內部物件等內容。
• spark1.6預設的Reserved Memory大小是300MB。這部分大小是不允許我們使用者改變的。簡單點說就是我們在為executor申請記憶體後，有300MB是我們無法使用的。並且如果我們申請的executor的大小小於1.5 * Reserved Memory 即 < 450MB，spark會報錯:
• User Memory：使用者在程式中建立的物件儲存等一系列非spark管理的記憶體開銷都佔用這一部分記憶體
• Spark Memory：該部分大小為 (JVM Heap Size - Reserved Memory) * spark.memory.fraction,其中的spark.memory.fraction可以是我們配置的(預設0.75)，如下圖：
• 
• 如果spark.memory.fraction配小了，我們的spark task在執行時產生資料時，包括我們在做cache時就很可能出現經常因為這部分記憶體不足的情況而產生spill到disk的情況，影響效率。採用官方推薦預設配置
• Spark Memory這一塊有被分成了兩個部分，Execution Memory 和 Storage Memory,這通過spark.memory.storageFraction來配置兩塊各佔的大小(預設0.5，一邊一半)，如圖：
• 
• Storage Memory主要用來儲存我們cache的資料和臨時空間序列化時unroll的資料，以及broadcast變數cache級別儲存的內容
• Execution Memory則是spark Task執行時使用的記憶體(比如shuffle時排序就需要大量的記憶體)
• 為了提高記憶體利用率，spark針對Storage Memory 和 Execution Memory有如下策略:

1. 1. 一方空閒，一方記憶體不足情況下，記憶體不足一方可以向空閒一方借用記憶體
   2. 只有Execution Memory可以強制拿回Storage Memory在Execution Memory空閒時，借用的Execution Memory的部分記憶體（如果因強制取回，而Storage Memory資料丟失，重新計算即可）
   3. 如果Storage Memory只能等待Execution Memory主動釋放佔用的Storage Memory空閒時的記憶體。(這裡不強制取回，因為如果task執行，資料丟失就會導致task 失敗)