分布式數據處理系統內存對象管理問題分析

張雄　陸路　石宣化

摘要：通過從程序語言的特性、垃圾回收機制、內存對象的序列化機制到基于區域的內存管理機制分析了內存對象的管理存在的問題，并分析了內存對象的生命周期在內存對象管理中能發揮的作用。提出了基于內存對象的生命周期對內存進行區域化管理的思路，可以從根本上解決垃圾回收問題。

關鍵詞：大數據；內存對象管理；分布式數據處理系統

Abstract：Through analysis of the characteristics of program languages， mechanism of garbage collection， serialization of in-memory data-objects and region-based memory management， most existing problems with memory management are exposed. Whats more， the lifetime of in-memory data objects can be key factor in memory management. Thus a solution is region-based memory management combined with the lifetime of in-memory data objects， which can solve the garbage collection problem.

Key words：big data； in-memory data-object management； distributed data processing system

以MapReduce為代表的分布式數據處理系統使得人們可以以增加硬件資源的方法來處理海量數據。已有的大量研究集中在多核或分布式環境下的可擴展性和容錯性。最新的研究工作表明：這類系統計算執行效率是一個被忽視的重要問題。導致執行效率低下的一個重要原因是代表性的開源系統，如Hadoop和Spark，都使用帶有托管執行環境的高級語言開發，從而降低分布式環境下的部署和調試的難度。托管環境提供內建的高級功能，比如自動內存管理和并發模型，使得其對象模型的底層實現非常復雜，帶來額外的內存和中央處理器（CPU）開銷。工業級托管環境的現代即時編譯優化很大程度上解決了中間代碼（IR）的解釋執行效率問題，但是難以解決復雜對象模型實現帶來的對象管理開銷問題。以Java虛擬機（JVM）為例：（1）每個對象在JVM中會有一個頭結構保存元數據，頭結構除了記錄對象類型，還要支持垃圾收集和并發加鎖優化；（2）所有（非原生類型）對象都在堆中創建，因此每個存活對象至少要有一個額外變量保存其引用；（3）泛型容器的元素如果是基本類型，必須首先被裝箱為對象類型；（4）主流垃圾收集算法都是基于對象追蹤的，因此堆中有大量的存活對象時，垃圾收集器需要耗費大量CPU周期來標記存活對象[1]。隨著處理數據量的增大，內存對象越來越多，尤其是長駐內存對象的存在[2]，內存對象管理會帶來嚴重的內存膨脹和CPU開銷問題。內存膨脹會間接影響執行性能：如果內存足夠，更大的內存占用會導致更頻繁的垃圾回收；如果內存不足，緩存的數據需要部分丟棄或者換出到磁盤，導致額外的重計算或輸入輸出（IO）開銷。

最初用來解決這類問題的方法是垃圾收集優化。垃圾收集優化分為兩個方面：一方面是通過參數[3]調優，避免頻繁垃圾收集；另一方面是通過優化垃圾收集算法實現來提高垃圾收集的性能[4]。垃圾收集優化的方法只是減緩了垃圾收集操作的影響，實際上內存對象管理所存在的問題仍然存在。后續的性能優化方案逐漸從垃圾收集的優化深入到內存對象管理本身，針對數據對象在內存中的存儲進行優化，主要包括序列化存儲[5]，基于區域的內存管理[6]。這種解決方案從根本上解決了對象對內存資源的占用，但是仍然無法避免對象的存在。在對象存儲優化的基礎上，目前分布式系統的一些上層特定應用，例如Spark 結構化查詢語言（SQL），利用特定的數據結構解決了對象存儲優化的不足，從根本上消除對象。當然，由于是特定的應用系統，使用范圍窄。

1 垃圾收集優化

垃圾收集問題是內存對象管理中最重要的問題之一，也是影響系統性能的關鍵因素。因此，最初針對內存對象管理問題的解決方法都是從垃圾收集入手。

1.1 垃圾收集調優

垃圾收集調優是最傳統的垃圾收集優化技術，也是一些長時間運行的低延遲Web服務所推薦的方法。一些開源分布式數據處理系統，例如Cassandra和HBase都使用以延遲為中心的方法來避免長時間垃圾收集開銷[7]。以上所述垃圾收集調優方法的關鍵在于：用標記清除算法（CMS）的垃圾收集控制器代替原有以吞吐量為中心的垃圾收集；調整標記清除算法的垃圾收集控制器參數以降低垃圾收集開銷。

1.2 垃圾收集算法優化

目前的垃圾收集算法有引用計數法、標記清除算法、拷貝收集算法等，不同的垃圾收集算法讓內存對象管理有更多的選擇來處理對象的回收。垃圾收集算法的優化性能要到達最優一般有特定場景，例如非統一內存訪問（NUMA）感知的垃圾回收器[8]。并且，垃圾收集算法的優化只是掩蓋了內存對象管理的問題，內存對象的自動化管理存在的問題仍然存在，頻繁調用垃圾收集的本質因素沒有解決。

1.3 程序語言優化

分布式數據處理系統使用高級面向對象語言進行開發會導致內存對象管理的問題，而傳統的面向機器的語言，如C、C++，則不存在內存對象管理存在的問題。為了追求性能上的優勢，一部分企業機構會選擇用這些傳統的語言來改寫目前的分布式數據處理系統，但是失去了高級語言特性的系統開發難度非常之大，并且不利于系統的更新。

2 對象存儲的優化策略

垃圾收集的優化并沒有考慮內存對象管理所存在的問題的本質，即內存中的對象仍然是自動化管理的。所以一些系統將對象用序列化的方式存放到內存以減少內存的占用來防止頻繁垃圾收集，或者將常規的內存對象管理方法替換為針對對象標記回收的區域內存管理方法來消除垃圾收集。這一類方法從內存對象管理的本質上考慮了性能問題。

2.1 序列化存儲

目前的分布式數據處理系統，如Hadoop和Spark，都支持將中間數據對象序列化為byte數組，從而減少對象在內存中存儲的占用。Hadoop系統中的對象大部分都是臨時的數據對象，因此Hadoop僅將Map的輸出數據序列化成byte數據，存放到磁盤，然后通過Shuffle傳輸給reduce task。盡管不存在內存對象管理的問題，但是序列化機制確實對分布式數據處理系統有重要作用。Spark系統不僅在Shuffle階段提供序列化機制，還在Cache時提供了序列化選擇，Cache時Spark會將彈性分布式數據集（RDD）中的數據保存到內存，用戶可以選擇是否采用序列化保存數據。Spark之所以支持非序列化保存，是因為序列化機制存在序列化和反序列化的開銷。一般來說，序列化機制能夠有效降低內存對象的占用，但是要在Cache數據對象時執行序列化操作，而在使用對象時執行反序列化操作。

序列化存儲降低了內存對象的占用，但是應用仍然基于對象執行的。因此在序列化和反序列化的基礎上，內存對象管理仍然需要考慮中間對象的管理，當數據量大時，對象的回收仍然會影響系統的性能[9]。

2.2 基于區域的內存管理

無論是基于垃圾收集調優還是序列化存儲，都是由內存管理機制自動標注對象的生命周期，始終存在對象的操作，就必然會需要內存管理機制根據標注回收無需再使用的對象，也就必然會導致垃圾收集。從內存對象相反的一個方向分析，C、C++等語言完全手動的標注內存中使用的對象，手動的回收對象?；趨^域的內存管理綜合了自動化和完全手動標注內存對象的兩種策略，采取了繞過垃圾收集的策略，將一部分對象統一標記后直接存儲到堆外區域，整塊回收區域內的對象，從而消除頻繁垃圾收集，解決內存對象管理的問題。

FACADE[10]系統是基于區域的內存管理的典型實例。FACADE以程序分析為基礎，在程序代碼中由用戶標識需要轉換的Java對象。FACADE會首先識別用戶標注的Java對象，將其轉換為輕量級的FACADE對象并通過byte形式保存FACADE到堆外內存，極大地減少了對象對內存的占用，而FACADE相比序列化更加進一步消除對象之處在于它同時轉換了Java對象的操作代碼。用戶自定義的操作函數是基于Java對象的，FACADE轉換Java對象為FACADE對象后，同時將操作函數轉換為基于FACADE對象的操作函數，完全實現了對象的消除。FACADE的內存對象管理采取了整塊分配和整塊回收的原則，一方面配合FACADE對象的存儲方式；一方面減少了垃圾收集開銷，相比傳統的內存對象管理取得了非常好的效果。

盡管FACADE的內存對象管理已經從很大程度上解決了對象管理的垃圾收集問題，但是它基于一個很強烈的假設：在整塊分配和整塊回收的操作間隔內的所有對象在內存中的存活時間都是相同的。在一些分布式數據處理系統中，例如Spark和Flink，將作業劃分為有向無環圖，按照每個階段執行。這類系統中的數據對象在內存中的存活時間就非常復雜，如果有用戶將數據Cache到內存，數據對象的存活時間持續整個作業執行期；如果是Shuffle階段的數據對象，數據對象可能會在多個階段的執行期內都存活在內存中。所以，FACADE在內存對象的管理上忽略了內存對象的生命周期。

Broom[11]綜合考慮了基于區域的內存管理的特點以及內存對象的生命周期的特點，Broom以NET CLR平臺為研究對象，將內存對象的存放區域進一步區分為：可轉移區域，用來存放操作的傳遞消息，同一時間只有一個操作可以訪問該區域；操作所需區域，針對某個操作私有的對象存儲區域，該區域內的對象的生命周期與相應的操作生命周期相同；臨時區域，存放一些臨時的數據對象。由于Broom基于閉源的系統實現而且作為short paper對系統實現提及較少，所以能夠獲取的信息只在于基于區域的內存管理與內存對象生命周期特點的結合是消除垃圾收集所必須考慮的兩個因素。

3 特定應用領域的優化

大多優秀的開源分布式數據處理系統，如Hadoop和Spark，都基于底層的系統實現了上層應用領域的生態系統[12]，例如Spark生態系統包括Spark SQL、Spark Streaming、Spark GraphX和Spark MLlib。特定應用領域的分布式數據處理系統在底層數據系統的基礎上定義了特定的計算結構，從而可以實現更加復雜的內存對象管理機制。在最初Java等高級語言被應用在數據分析系統時，除了受益于高級語言的特性，一些系統也意識到其在內存對象管理上的不足，因此結合特定的結構進行優化[13]，例如SQL。Shark等針對data-intensive的數據庫管理系統，將Java對象轉化為Telegraph數據流，在內存分配上整存整取，繞過Java的內存管理方法[14]。Shark使用基于列的內存存儲和動態查詢優化來提高SQL查詢的性能。Apache項目Tungsten基于Spark SQL實現，將傳統的關系表結果轉換為以列為結構的字節序列，同時將SQL操作全部轉換為基于字節序列的操作。

分布式數據處理系統內存對象管理的解決方案各具優點和缺點，具體見表1。

4 結束語

分布式數據處理系統按照數據流的路徑可以分為控制路徑和數據路徑，控制路徑由系統框架支持和實現，數據路徑由用戶定義和實現。我們發現：控制路徑的編程實現更多的從對象模型的高級特性中獲益，包括類型的運行時動態識別、并發同步操作的偏向鎖優化和自動對象內存管理等。數據路徑的編程實現很少使用語言的高級特性。數據路徑的實現由用戶自定義，具體包括用戶自定義類型（UDT）和用戶自定義方法（UDF）。UDT定義的是數據路徑中實際操作的對象類型，而UDF定義了對這些數據類型執行的操作。UDT通常是基本類型的淺層組合和常用方法的實現封裝，很少會使用復雜的繼承層次和多態。

比如，通過定義接口來抽象化模塊之間的交互，進而通過工廠模式，依賴注入來支持靈活的模塊和插件加載，而這些設計模式依賴于多態和反射等語言特性。框架負責任務的并行化執行和同步機制，因此依賴于托管環境的并發執行模型，比如線程創建和加鎖操作。由于并發執行由框架負責，UDF本身都是串行代碼，在UDF內部使用加鎖操作通常沒有意義，更不可能會在UDT數據對象上加鎖。因此，UDT并不依賴于一個復雜的對象模型實現。比如：（1）當沒有多態導致的虛方法派發時，也沒有使用反射時，不需要在對象頭部記錄對象的運行時類型；（2）當對象沒有加鎖操作時，也不需要在頭部存儲偏向鎖狀態；（3）UDT數據對象的生命周期具有很強的規律性，如果能夠跳過JVM的內存管理，不僅消除了垃圾收集的CPU開銷，也不需要在對象頭部存儲垃圾收集所需的狀態信息。

最重要的一點是：數據對象的生命周期具有很強的規律性。我們發現：在以Spark為代表的新一代通用數據并行系統中，作業執行時通常有幾類數據容器會持有數據對象，而數據對象的生命周期和持有它的數據容器的生命周期有很強的關聯性：

（1）UDF變量。包括UDF對象的字段和UDF局部變量，前者的生命周期剛好為一個任務的執行時間，其存活時間內時所持有的對象生命周期由該字段的賦值操作決定，但最長不超過任務的執行時間；后者的生命周期為一次UDF方法的調用，因此其持有的數據對象最多存活一次方法調用，可以視為臨時對象。

（2）緩存數據集。緩存數據集的生命周期由應用程序顯示決定，其持有的數據對象的生命周期具有與該RDD等同的生命周期。

（3）Shuffle緩沖區。不考慮溢出到磁盤的情況，Shuffle緩沖區的生命周期也剛好為一個任務的執行時間。其持有的數據對象的生命周期較為復雜，在聚合計算的過程中，Shuffle buffer僅為一個Key數據對象保存一個數據對象作為當前聚合的結果。

一種可行的方法是通過自動轉換數據處理應用程序來減少程序運行時創建的UDT數據對象的數量。轉換工作對應用開發人員完全透明，不會限制數據并行編程模型的表達能力和靈活性。

致謝

本研究得到華中科技大學金海教授的指導，謹致謝意！

參考文獻

[1] JONES R， HOSKING A， MOSS E. The Garbage Collection Handbook ： the Art of Automatic Memory Management [M]. USA： CRC Press， 2012

[2] ZAHARIA M， CHOWDHURY M， DAS T， et al. Resilient Distributed Datasets： a Fault-Tolerant Abstraction for in-Memory Cluster Computing [C]//Proceeding in 9th USENIX Conference on Networked Systems Design and Implementation （NSDI）. USA： USENIX Association， 2012： 141-146

[3] Cassandra Garbage Collection Tuning， Find and Fix Long GC Pauses [EB/OL]. [2013-11-14]. http：//aryanet.com/blog/cassandra-garbage-collector-tuning

[4] Laboratory for Web Algorithmic [EB/OL]. [2014-10-12].http：//law.di.unimi.it/datasets.php

[5] CARPENTER B， FOX G， KO S H， et al. Object Serialization for Marshalling Data in a Java Interface to MPI[C]//ACM Java Grande Conference. USA： ASM， 1970： 66-67

[6] MADS T， JEAN-PIERRE T. Region-Based Memory Management [J]. Information & Computation， 1997， 132（2）：109-176

[7] The Garbage Collector and Apache Hbase [EB/OL]. （2016-02-18）[2014-03-22].http：//hbase.apache.org/book.html#gc

[8] 浦云明. JAVA垃圾收集器算法分析及垃圾收集器的運行透視[J]. 計算機系統應用， 2003 （11）： 39-41

[9] MILLER H， HALLER P， BURMAKO E， et al. Instant Pickles： Generating Object-Oriented Pickler Combinators for Fast and Extensible Serialization [J]. ACM Sigplan Notices， 2013， 48（10）：183-202

[10] NGUYEN K， WANG K， BU Y， et al. FACADE： A Compiler and Runtime for （Almost） Object-Bounded Big Data Applications [J]. ACM Sigplan Notices， 2015， 50（4）：675-690. DOI： 10.1145/2775054.2694345

[11] GOH I， GICEVA J， SCHWARZKOPF M， et al. Broom： Sweeping Out Garbage Collection from Big Data Systems [C]//15th Workshop on Hot Topics in Operating Systems （HotOS XV）. USA： ACM， 2015

[12] 胡俊， 胡賢德， 程家興. 基于Spark的大數據混合計算模型[J]. 計算機系統應用， 2015（4）： 214-218

[13] SHAH M A， FRANKLIN M J， MADDEN S， et al. Java Support for Data-Intensive Systems： Experiences Building the Telegraph Dataflow System [J]. Sigmod Record， 2001， 30（4）：103-114

[14] XIN R. S， ROSEN J， ZAHARIA M， et al. Shark： SQL and Rich Analytics at Scale[C]// Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data. USA： ASM， 2013：13-24. DOI： 10.1145/2463676.2465288