Spark并行計算框架的內(nèi)存優(yōu)化*

廖旺堅,黃永峰,包從開

(1.清華大學(xué)電子工程系，北京 100084;2.清華大學(xué)信息科學(xué)與技術(shù)國家實驗室(籌)，北京 100084)

1 引言

集群并行計算是指在大量性能較低、可靠性較差的通用計算機(jī)上并行完成巨大的計算任務(wù)，是大數(shù)據(jù)時代滿足低成本/高計算能力需求的最佳選擇。Hadoop是一個開源的集群并行計算框架，包含MapReduce計算模型和Hadoop分布式文件系統(tǒng)HDFS(Hadoop Distributed File System)存儲模型，具有硬件要求低、吞吐量大、容錯性好的特點，滿足了大數(shù)據(jù)計算的需要，成為當(dāng)前工業(yè)界最流行的計算框架，也是學(xué)術(shù)界研究熱點。但是，隨著數(shù)據(jù)量迅猛增長，計算復(fù)雜度不斷增加，計算實時性越來越高，Hadoop計算速度較慢的弱點逐漸顯現(xiàn)。于是，Zaharia等[1 - 3]基于Hadoop，在前人不斷改進(jìn)的基礎(chǔ)上重新實現(xiàn)其調(diào)度模型，形成了Spark計算框架。

Spark是一個快速、通用的大規(guī)模數(shù)據(jù)處理引擎[4]，具有快速、易用、通用、兼容性好的特點。它使用有向無環(huán)圖DAG(Directed Acyclic Graph)進(jìn)行作業(yè)調(diào)度，根據(jù)依賴關(guān)系將不同作業(yè)分解成大量子任務(wù)組成的DAG，減少了不同作業(yè)之間的數(shù)據(jù)傳遞過程，并且將前后作業(yè)間的中間數(shù)據(jù)使用內(nèi)存緩存?zhèn)鬟f，使用線程池運(yùn)行計算任務(wù)，使得計算速度相比傳統(tǒng)的Hadoop MapReduce有100倍量級的提升[3]。

目前對Spark性能的研究主要有三類：第一類是在Spark模型層面對作業(yè)調(diào)度、底層資源管理等方面做改進(jìn)和優(yōu)化；第二類是在提交Spark作業(yè)時改變不同的參數(shù)，找到最優(yōu)值；第三類是在應(yīng)用層面，編程時使用不同的實現(xiàn)方法，提高作業(yè)運(yùn)行性能。Ousterhout等[5]對Spark性能做了詳盡測試和分析，認(rèn)為CPU可以優(yōu)化的地方較少，而網(wǎng)絡(luò)使用遠(yuǎn)未達(dá)到飽和狀態(tài)，其優(yōu)化對性能的影響很小，但該文獻(xiàn)關(guān)于內(nèi)存對性能的影響很少提及。陳僑安等[6]對大量舊任務(wù)提交參數(shù)和性能進(jìn)行分析，對比任務(wù)相似度，預(yù)測出新任務(wù)最適合的參數(shù)，屬于第二類的方法。楊志偉等[7]改變?nèi)蝿?wù)調(diào)度策略，優(yōu)先將任務(wù)分發(fā)給資源空余度高的結(jié)點，提高集群整體運(yùn)行性能，屬于第一類的方法。Gog等[8]采用內(nèi)存分區(qū)管理的思路，給應(yīng)用中處于生命周期的數(shù)據(jù)對象劃定內(nèi)存區(qū)塊，運(yùn)行時不對此區(qū)塊進(jìn)行GC(Garbage Collector)操作，但這樣需要給每個對象指定明確的生命周期，使得編程更為復(fù)雜。Gidra等[9]針對分布式系統(tǒng)的GC進(jìn)行改造，使各結(jié)點GC進(jìn)程互相發(fā)布消息，避免無效的GC操作，提高運(yùn)行效率，但增加了結(jié)點間通信消耗。

Spark的特點是大量使用內(nèi)存提高計算速度，因此內(nèi)存資源是Spark最基本的瓶頸，通過內(nèi)存優(yōu)化，可以提升Spark的性能。本文針對第二類和第三類方法存在的不足，圍繞內(nèi)存在Spark作業(yè)中的分配方法和作用原理，提出不同的內(nèi)存優(yōu)化策略，并設(shè)計了相應(yīng)的實驗進(jìn)行論證。

2 Spark作業(yè)執(zhí)行框架分析

2.1 作業(yè)調(diào)度機(jī)制分析

Spark的作業(yè)執(zhí)行流程如圖1所示，用戶向Driver結(jié)點提交需要運(yùn)行的作業(yè)后，Driver結(jié)點創(chuàng)建SparkContext。SparkContext根據(jù)程序中的Action操作，將作業(yè)劃分為連續(xù)的Job流，并依次提交到有向無環(huán)圖調(diào)度器DAGScheduler。DAGScheduler對提交的Job進(jìn)行解析，生成由不同Stage流組成的有向無環(huán)圖，然后依次將每個Stage提交到線程調(diào)度器TaskSchedulerImpl。TashSchedulerImpl為Stage生成線程集TaskSet，并將TaskSet分發(fā)到各個工作結(jié)點Worker的線程管理器TaskManager。TaskManager根據(jù)收到的信息啟動Task開始運(yùn)算，運(yùn)算結(jié)束后得到的數(shù)據(jù)可能被下一個Stage所使用，稱為中間數(shù)據(jù)，由數(shù)據(jù)塊管理器BlockManager進(jìn)行管理。BlockManager在內(nèi)存充足的時候?qū)⒅虚g數(shù)據(jù)存儲到內(nèi)存，以提高訪問速度，在內(nèi)存不夠的時候?qū)⒅虚g數(shù)據(jù)存儲到本地磁盤、HDFS或丟棄。

Figure 1 Spark application execution flow圖1 Spark作業(yè)執(zhí)行流程

2.2 JVM層內(nèi)存管理機(jī)制分析

Spark作業(yè)運(yùn)行在Java進(jìn)程中，一個Java進(jìn)程對應(yīng)一個JVM。JVM在運(yùn)行過程中管理的內(nèi)存空間叫堆空間，用于存儲程序中創(chuàng)建的對象，在運(yùn)行過程中可根據(jù)配置動態(tài)變化。如圖2所示，JVM堆空間分為年輕代(Young Generation)、年老代(Old Generation)和持久代(Permanent Generation)，一般年輕代存放短生命周期的對象，年老代存放長生命周期的對象，持久代存放類、方法等元數(shù)據(jù)，年輕代又可分為Eden、Survivor1(S1)和Survivor2(S2)區(qū)間。

Figure 2 Memory management comparison between Spark and JVM圖2 Spark和JVM的內(nèi)存管理對應(yīng)關(guān)系

JVM運(yùn)行過程中會使用垃圾收集器GC對內(nèi)存數(shù)據(jù)進(jìn)行清理。新生成的對象存放在Eden區(qū)間，Eden區(qū)間滿了后，會觸發(fā)Minor GC，將Eden和Survivor1區(qū)間仍然存活的對象復(fù)制到Survivor2區(qū)間。下一次Eden區(qū)間再滿，再觸發(fā)Minor GC，將Eden和Survivor2區(qū)間仍然存活的對象復(fù)制到Survivor1區(qū)間，如此不斷往復(fù)。當(dāng)對象生命周期足夠長或Survivor區(qū)間滿了后，對象會被轉(zhuǎn)移到年老代區(qū)域。當(dāng)年老代快滿的時候，會觸發(fā)Full GC，清理年老代不需要使用的對象。當(dāng)持久代有類不需再使用并且需要空間存放別的數(shù)據(jù)時，會觸發(fā)Major GC，清理持久代的數(shù)據(jù)。

當(dāng)GC被觸發(fā)時，JVM中所有運(yùn)行的線程會暫時停止運(yùn)行，等待GC完成后繼續(xù)。如果一次作業(yè)中GC被觸發(fā)的次數(shù)特別多，就會顯著延長作業(yè)執(zhí)行總時間，降低系統(tǒng)性能。其中Full GC需要時間比Minor GC更長，對性能影響更大。Java官方文檔[10]顯示，在理想情況下，使用30%的時間作為GC消耗，在使用2個CPU內(nèi)核時，系統(tǒng)吞吐量會下降到80%，而使用32個CPU內(nèi)核時，系統(tǒng)吞吐量會下降到10%。而Spark作業(yè)處理大規(guī)模數(shù)據(jù)，通常都會使用較多的CPU內(nèi)核，因此GC對性能的影響需要引起重視。

2.3 Spark層內(nèi)存管理機(jī)制分析

Spark框架同樣對所使用的內(nèi)存進(jìn)行管理，其管理的內(nèi)存主要有兩種用途。如圖2所示，第一種是用于程序執(zhí)行，如join、sort、shuffle、aggregation等算子執(zhí)行時使用的內(nèi)存;第二種是用于存儲，如RDD(Resilient Distributed Datasets)數(shù)據(jù)緩存和廣播變量存儲等。用于這兩種用途的內(nèi)存使用一個統(tǒng)一的空間(如圖2中的M，其存儲空間大小為M)，Spark使用一個參數(shù)spark.memory.fraction設(shè)置M的大小：

spark.memory.fraction=M/(Java堆空間-300 MB)(默認(rèn)0.6)

在內(nèi)存M中，一部分用于任務(wù)執(zhí)行(如圖2中的Execution,其空間大小為E)，一部分用于緩存數(shù)據(jù)(如圖2的Storage,其存儲空間大小為R)。Spark使用參數(shù)spark.memory.storageFraction設(shè)置兩者比例：

spark.memory.storageFraction=R/M(默認(rèn)0.5)

從圖2可以看出，Spark管理的內(nèi)存和JVM管理的堆空間屬于同一段物理內(nèi)存空間，只是在不同層面上進(jìn)行管理。Spark管理的內(nèi)存基本等于JVM堆空間的年輕代和年老代的空間，一部分用于執(zhí)行運(yùn)算和存儲(M)，另一部分空間用于Spark的類等元數(shù)據(jù)的存儲。

3 內(nèi)存優(yōu)化策略

我們對影響Spark作業(yè)執(zhí)行性能的主要因素進(jìn)行分類，如圖3所示。

Figure 3 Influencing factors of Spark application performance圖3 Spark作業(yè)性能影響因素示意圖

圖3中可以看出，目前對于Spark的優(yōu)化一般從修改源代碼改變系統(tǒng)作業(yè)的執(zhí)行模型，提交作業(yè)時調(diào)整運(yùn)行參數(shù)和編寫作業(yè)程序時算法優(yōu)化等幾個方面入手。系統(tǒng)運(yùn)行參數(shù)又可分為CPU參數(shù)、內(nèi)存參數(shù)和I/O網(wǎng)絡(luò)參數(shù)等。CPU參數(shù)配置包括單執(zhí)行容器使用的核數(shù)、單核的線程數(shù)等。網(wǎng)絡(luò)和I/O的配置包括緩沖區(qū)大小、數(shù)據(jù)分塊大小和文件并發(fā)數(shù)量等。內(nèi)存的運(yùn)行參數(shù)配置方面，可以通過改變單容器內(nèi)存大小、對緩存數(shù)據(jù)進(jìn)行預(yù)處理、改變JVM和Spark管理內(nèi)存的分配比例等，對作業(yè)性能產(chǎn)生影響。

3.1 通過序列化和壓縮，減小緩存數(shù)據(jù)大小，提升系統(tǒng)性能

一般數(shù)據(jù)從磁盤讀取到內(nèi)存以后，占用空間都會不同程度地增大。這主要是由于Java的對象存儲格式所決定的，如每個String對象會占用40 Bytes空間存儲文本宏信息，則平均每行40個字符的中文數(shù)據(jù)集轉(zhuǎn)化成RDD后，占用內(nèi)存會比原始數(shù)據(jù)大50%。而對于英文文本來說，內(nèi)存中存儲的UNICODE格式或UTF-16格式的字符，占用內(nèi)存空間會比磁盤上存儲的UTF-8或ASCII碼格式大一倍。

Spark將作業(yè)運(yùn)行過程中產(chǎn)生的RDD緩存到內(nèi)存時，RDD中每一行的數(shù)據(jù)指針等頭數(shù)據(jù)都會緩存下來，而這會占用大量內(nèi)存空間。序列化可以將RDD轉(zhuǎn)化為字節(jié)序列存儲，減小緩存數(shù)據(jù)占用空間，如果序列化后再使用壓縮算法對字節(jié)序列進(jìn)行壓縮，能更大程度減少空間占用。特別是在內(nèi)存空間緊張時，減少緩存數(shù)據(jù)大小，更多內(nèi)存可以用于代碼執(zhí)行，減少系統(tǒng)的GC觸發(fā)次數(shù)，有效避免或減少對外存的使用，提高運(yùn)行性能。

3.2 在一定范圍內(nèi)減小運(yùn)行內(nèi)存，減少緩存使用，提升性能

使用硬件資源越多，系統(tǒng)性能越好，這是業(yè)界普遍的認(rèn)識。數(shù)據(jù)在內(nèi)存中緩存是以RDD分塊的方式存在的，分塊的大小默認(rèn)跟HDFS存儲文件的分塊大小一致。作業(yè)運(yùn)行過程中，如果空閑內(nèi)存不夠存下整個分塊，系統(tǒng)會移除掉部分舊的緩存數(shù)據(jù)，存放新的數(shù)據(jù)。如果移除掉舊的部分?jǐn)?shù)據(jù)還不夠的話，系統(tǒng)會放棄使用內(nèi)存緩存，改用外部存儲緩存或不使用緩存。

對于數(shù)據(jù)量大而計算代價小的作業(yè)而言，使用足夠大的內(nèi)存，可以使得內(nèi)存在緩存全部數(shù)據(jù)后還有足夠的空間執(zhí)行代碼，作業(yè)執(zhí)行過程不會觸發(fā)GC，系統(tǒng)性能可以達(dá)到最佳。而在可使用的運(yùn)行內(nèi)存較小時，系統(tǒng)調(diào)度策略會發(fā)生改變，減少數(shù)據(jù)的緩存操作，改由重新計算得到原來緩存的數(shù)據(jù)。如果減少緩存的數(shù)據(jù)很大，則騰出來的內(nèi)存空間更多，反而會降低JVM的GC觸發(fā)次數(shù)，在重新計算消耗小的情況下，會使得整個系統(tǒng)運(yùn)行過程穩(wěn)定，性能提高。

3.3 配置合適的Spark和JVM使用內(nèi)存分區(qū)的配比，提升系統(tǒng)性能

文獻(xiàn)[10]指出，JVM的GC算法是基于“Java程序中大部分的對象都是短生命周期”這一假設(shè)，即大部分的對象在Minor GC時就會被清理掉，沒機(jī)會轉(zhuǎn)入到年老代，因此GC過程中Full GC較少，對系統(tǒng)性能影響不大。而Spark中緩存數(shù)據(jù)在整個作業(yè)期間會一直存在，對于JVM來說都是長生命周期對象，并且普遍數(shù)據(jù)量大，占用大量的JVM堆空間。大數(shù)據(jù)背景下的計算任務(wù)，一個數(shù)據(jù)塊很容易就占滿所有的年老代空間，導(dǎo)致傳統(tǒng)GC不能起到應(yīng)有的作用，反而降低系統(tǒng)性能。通過改變JVM中年輕代和年老代的比例，改變Spark中執(zhí)行內(nèi)存和存儲內(nèi)存的比例，可以調(diào)節(jié)JVM的GC消耗，減少不利影響，提高系統(tǒng)性能。

下一節(jié)我們運(yùn)行大量Spark作業(yè)，使用上述不同策略優(yōu)化，驗證不同優(yōu)化策略下參數(shù)配置對系統(tǒng)性能的影響。

4 實驗與分析

為驗證和分析優(yōu)化策略的效果，搭建了Spark運(yùn)行平臺。Spark計算層設(shè)置4個結(jié)點，其中1個主結(jié)點，3個工作結(jié)點，每個工作結(jié)點32 GB內(nèi)存，8個CPU內(nèi)核。HDFS存儲層設(shè)置6個結(jié)點，其中1個主結(jié)點，5個數(shù)據(jù)結(jié)點，HDFS文件塊大小設(shè)置為128 MB。

為驗證優(yōu)化策略，設(shè)計了兩類計算任務(wù)：

任務(wù)A對不同大小的中文微博數(shù)據(jù)集(1 GB～100 GB)進(jìn)行詞頻統(tǒng)計。任務(wù)要求將數(shù)據(jù)集讀出后使用不同的方式緩存，然后做詞頻統(tǒng)計工作。

任務(wù)B對2 227萬條60維的向量數(shù)據(jù)聚類計算，數(shù)據(jù)以文本的格式存儲在HDFS上，共9.82 GB，79個分塊。任務(wù)要求將數(shù)據(jù)讀入后，轉(zhuǎn)化為Vector向量，然后再以不同方式緩存，最后進(jìn)行迭代次數(shù)不大于8次的KMeans聚類操作。

實驗過程中，采用不同的參數(shù)配置運(yùn)行A類任務(wù)和B類任務(wù)，觀察任務(wù)運(yùn)行時間、GC詳情、線程執(zhí)行時間、數(shù)據(jù)塊存取、資源占用情況等指標(biāo)，并作記錄和分析。

4.1 序列化和壓縮數(shù)據(jù)

表1顯示了任務(wù)A的數(shù)據(jù)經(jīng)過不同方式處理后，緩存占用的空間大小和作業(yè)運(yùn)行時間。任務(wù)中數(shù)據(jù)集為1 096 MB的中文微博文本數(shù)據(jù)，共8 546萬行。可以看出，Spark將數(shù)據(jù)導(dǎo)入后，占用空間比在磁盤占用空間增加17%，而序列化以后，空間減少14%，如果序列化后再進(jìn)行壓縮，則占用空間比不處理減少42%。在運(yùn)行時間上，壓縮比不壓縮平均降低運(yùn)行時間2 s，同時GC時間減少80%，說明緩存空間的減少能夠有效降低GC消耗。但是，最終不處理情況下運(yùn)行時間是最小的，因為序列化和壓縮，包括讀取緩存后的反序列化和解壓縮過程本身需要占用資源。序列化后再壓縮相比序列化后不壓縮，雖然壓縮過程需要時間，但壓縮后占用空間更少，GC消耗大大降低，降低的GC消耗時間遠(yuǎn)超過壓縮過程增加的時間，總作業(yè)運(yùn)行時間反而比序列化后不壓縮降低18%。

Table 1 Effects of different processingmethods on data size and performance表1 不同處理方式對數(shù)據(jù)大小和運(yùn)行性能的影響

圖4顯示了對任務(wù)B用不同緩存方式處理后的性能。任務(wù)中數(shù)據(jù)直接緩存占用空間約10.7 GB，序列化后占用空間約10.3 GB。如果使用壓縮后再緩存的方式，占用空間約7.8 GB，減少24%，與文本數(shù)據(jù)的空間占用規(guī)律基本一致?？梢钥闯?，在直接使用系統(tǒng)內(nèi)存和HDFS緩存中間數(shù)據(jù)的情況下，隨著提交內(nèi)存的增加，系統(tǒng)運(yùn)行性能提高，這是因為隨著內(nèi)存的增加減少了對HDFS的使用，所以運(yùn)行速度增加。如果將外部存儲方式由HDFS改為DISK，我們可以看到，在內(nèi)存較少的情況下，系統(tǒng)運(yùn)行時間比HDFS方式降低很多，因為去除了網(wǎng)絡(luò)消耗和多備份消耗后，本地硬盤的讀寫比HDFS讀寫消耗的時間要短。

Figure 4 Performance comparison of different caching modes圖4 不同緩存方式性能對比

從以上兩例中可以看出，減小緩存占用的空間可以減少讀寫時間，降低GC消耗，提高系統(tǒng)性能。但序列化和壓縮兩種減少空間的過程本身需要時間，在“一次緩存，多次使用”和內(nèi)存嚴(yán)重受限的情況下，適用于這種方式提高系統(tǒng)性能。而在內(nèi)存不夠時，用本地磁盤代替HDFS存儲中間數(shù)據(jù)，能夠降低讀寫時間消耗，在通常的情況下都能比較適用。

4.2 改變運(yùn)行內(nèi)存大小

圖5顯示了任務(wù)B在提交作業(yè)時使用不同內(nèi)存大小，對任務(wù)運(yùn)行的總時間和GC占用的時間的影響。可以看出，GC時間和運(yùn)行總時間有明顯的正相關(guān)性，GC耗時長則運(yùn)行總時間長。在內(nèi)存小的時候，GC用時明顯較大，在內(nèi)存大的時候，GC時間則非常之少。當(dāng)內(nèi)存從1 500 MB到4 000 MB時，GC時間逐步下降，任務(wù)運(yùn)行時間也隨內(nèi)存增多而下降。內(nèi)存大于6 000 MB以后，GC用時基本可以忽略不計，而運(yùn)行總時間趨于穩(wěn)定。在內(nèi)存小于1 600 MB時，提交內(nèi)存越大反而運(yùn)行時間越長，這符合策略3分析的結(jié)果。不過直接計算速度比不上內(nèi)存緩存，所以相比最佳性能還是差一些。當(dāng)內(nèi)存在1 500 MB左右時，GC用時和任務(wù)運(yùn)行總時間達(dá)到最高，GC用時占到了總用時的30%。

從這里可以看出，在提交Spark作業(yè)的時候，在內(nèi)存足夠的情況下，應(yīng)盡量使用更多的內(nèi)存，而內(nèi)存有限的情況下，也并不是內(nèi)存越少性能就越差，同時也要避免如實驗中“1 500 MB”這樣的區(qū)間。

Figure 5 Task running time and GC time scatter distribution圖5 任務(wù)運(yùn)行時間與GC時間散點分布

圖6展示了任務(wù)B運(yùn)行過程中所有緩存的數(shù)據(jù)量，包括緩存在內(nèi)存和磁盤的，以及系統(tǒng)因為內(nèi)存空間不夠，為緩存新數(shù)據(jù)而從磁盤移除的老數(shù)據(jù)量?？梢钥闯觯谶\(yùn)行內(nèi)存較小的時候，系統(tǒng)使用內(nèi)存緩存和磁盤緩存都小，但都隨內(nèi)存增加而增大。而到1 600 MB以后，內(nèi)存緩存基本保持穩(wěn)定，磁盤緩存則顯著下降。說明內(nèi)存足夠大以后，只用內(nèi)存就能滿足所有緩存要求，所以磁盤使用量下降，同時也越來越不需要移除內(nèi)存給新的數(shù)據(jù)騰空間，所以內(nèi)存緩存移除數(shù)據(jù)同步下降，最后趨于零。前面內(nèi)存越小，內(nèi)存緩存也越小，但磁盤緩存也越小，同圖5類似，說明系統(tǒng)根據(jù)參數(shù)減少了緩存的使用，使用重新計算的方式得到需要的數(shù)據(jù)，這一部分需要消耗部分時間，但比使用磁盤緩存耗時反而更低。

Figure 6 Cache data trends圖6 緩存數(shù)據(jù)變化趨勢

綜合圖5和圖6可以看出，Spark作業(yè)運(yùn)行時間與GC時間、存儲設(shè)備讀寫時間等都密切相關(guān)，由多種因素決定。在數(shù)據(jù)量太大而內(nèi)存遠(yuǎn)遠(yuǎn)不夠的情況下運(yùn)行任務(wù)，酌情減少內(nèi)存的使用，可能會達(dá)到更好的效果。

4.3 JVM堆空間和Spark內(nèi)存分配

圖7展示了使用不同的JVMNewRatio參數(shù)運(yùn)行任務(wù)B的結(jié)果。NewRatio參數(shù)代表JVM中年老代和年輕代大小的比例，我們分別設(shè)置為1、2、4、8、15，對比運(yùn)行效果。從圖7中可以看出，當(dāng)NewRatio參數(shù)越來越大，也就是堆空間中年老代占比越來越多的時候，系統(tǒng)的Minor GC時間增加，而Full GC時間減少，任務(wù)運(yùn)行的總時間減少,在參數(shù)為8時達(dá)到最小值，此時性能比參數(shù)為1時提升25%，比默認(rèn)參數(shù)提升10%。

Figure 7 Running time and GC time in different heap space ratio圖7 不同堆空間比例時作業(yè)運(yùn)行時間和GC時間

這是因為Spark任務(wù)中緩存的數(shù)據(jù)一般會保持較長時間，并且比較大，在NewRatio較大，即年輕代較小、年老代較大的情況下，會很快占滿年輕代的Eden區(qū)間，引發(fā)Minor GC，所以Minor GC次數(shù)比較多，時間比較長，但單次Minor GC的時間會短，因為年輕代空間較小，清理對象較快，如圖8所示。而由于年老代空間較大，對象的生命周期容忍度比較大，所以年老代的Full GC次數(shù)比較少。從圖8中可以看見，單次Full GC時間大約是單次Minor GC時間的10～20倍，因此Full GC的次數(shù)更能影響系統(tǒng)的性能。

Figure 8 Average time of single GC in different heap space ratio圖8 不同堆空間比例時平均單次GC時間對比

Spark有兩個參數(shù)調(diào)節(jié)管理內(nèi)存的分配，spark.memory.fraction表示Spark管理的內(nèi)存中執(zhí)行和存儲部分占的比例，實驗使用任務(wù)B在0.9～0.002測試，結(jié)果如圖9所示。從圖9中可以發(fā)現(xiàn)，當(dāng)比例在0.001時運(yùn)行時間達(dá)到最小值，也就是說提交運(yùn)行內(nèi)存為2 200 MB時，只使用不到20 MB作為執(zhí)行代碼和存儲使用的內(nèi)存，此時性能比最低水平提升50%，比平均水平提升30%。查找監(jiān)測數(shù)據(jù)可以發(fā)現(xiàn)，該比例時運(yùn)行作業(yè)，JVM只有Minor GC，同時也幾乎沒有中間數(shù)據(jù)存儲在內(nèi)存和硬盤，因為此時Spark使用的內(nèi)存大小遠(yuǎn)小于JVM年老代大小，所以根本不會觸發(fā)Full GC，在內(nèi)存緩存很小很小的情況下，GC時間最短的性能最高。

Figure 9 Running time of different Spark memory execution storage ratio圖9 不同Spark內(nèi)存執(zhí)行存儲比例時運(yùn)行時間

5 結(jié)束語

本文分析Spark運(yùn)行過程中JVM層面和Spark層面對內(nèi)存的管理機(jī)制，從減少數(shù)據(jù)量、改變提交內(nèi)存大小、改變JVM堆空間內(nèi)存分配比例、改變Spark管理內(nèi)存分配比例幾個方面探討了優(yōu)化Spark作業(yè)運(yùn)行的方法，并通過實驗對方法進(jìn)行了驗證。

通過實驗發(fā)現(xiàn)，總的來說，使用更大的內(nèi)存能夠提升系統(tǒng)性能。但是，在大數(shù)據(jù)處理背景下，內(nèi)存的增長跟不上數(shù)據(jù)的增長，在有限的內(nèi)存條件下，適當(dāng)減少內(nèi)存使用促使系統(tǒng)用重新計算代替緩存，根據(jù)Spark緩存對象和作業(yè)性質(zhì)的特點，優(yōu)化JVM中堆內(nèi)存的分配和Spark管理內(nèi)存的大小，能夠有效降低I/O和GC消耗，提高系統(tǒng)性能。

本文的貢獻(xiàn)點在于結(jié)合Spark對內(nèi)存的管理和JVM對內(nèi)存的管理，分析兩層之間的內(nèi)存管理的相互聯(lián)系，根據(jù)數(shù)據(jù)對象在內(nèi)存中的存在方式變化，提出優(yōu)化策略。實驗結(jié)果說明優(yōu)化策略能夠有效提升系統(tǒng)性能，具有一定的代表性，分析的結(jié)論對如何更好地使用和改進(jìn)Spark也有一定的啟發(fā)作用。

參考文獻(xiàn):

[1] Zaharia M.An architecture for fast and general data processing on large clusters[M].New York:Association for Computing Machinery and Morgan & Claypool,2013.

[2] Zaharia M,Chowdhury M,Franklin M J,et al.Spark: Cluster computing with working sets[C]∥Proc of the 2nd USENIX Conference on Hot Topics in Cloud Computing,2010:10.

[3] Zaharia M,Chowdhury M,Das T,et al.Resilient distributed datasets: A fault-tolerant abstraction for in-memory cluster computing[C]∥Proc of the 9th USENIX Conference on Networked Systems Design and Implementation,2012:141-146.

[4] Apache Spark-Lightning-fast cluster computing[EB/OL].[2016-09-14].http://spark.apache.org/.

[5] Ousterhout K,Rasti R,Ratnasamy S,et al.Making sense of performance in data analytics frameworks[C]∥Proc of the 12th USENIX Conference on Networked Systems Design & Implementation,2015:293-307.

[6] Chen Qiao-an,Li Feng,Cao Yue,et al.Parameter optimization for Spark jobs based on runtime data analysis[J].Computer Engineering & Science,2016,38(1):11-19.(in Chinese)

[7] Yang Zhi-wei,Zheng Quan,Wang Song,et al.Adaptive task scheduling strategy for heterogeneous spark cluster [J].Computer Engineering,2016,42(1):31-35.(in Chinese)

[8] Gog I,Giceva J,Schwarzkopf M,et al.Broom: Sweeping out garbage collection from big data systems[C]∥Proc of the 15th Usenix Conference on Hot Topics in Operating Systems,

2015:2.

[9] Gidra L, Thomas G,Sopena J,et al.NumaGiC: A garbage collector for big data on big NUMA machines[J].Acm Sigplan Notices,2015,50(4):661-673.

[10] Java SE 6 HotSpot[tm] Virtual machine garbage collection tuning[EB/OL].[2016-09-16].http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html.

附中文參考文獻(xiàn)：

[6] 陳僑安,李峰,曹越,等.基于運(yùn)行數(shù)據(jù)分析的Spark任務(wù)參數(shù)優(yōu)化[J].計算機(jī)工程與科學(xué),2016,38(1):11-19.

[7] 楊志偉,鄭烇,王嵩,等.異構(gòu)Spark集群下自適應(yīng)任務(wù)調(diào)度策略[J].計算機(jī)工程,2016,42(1):31-35.