面向固態硬盤的Spark數據持久化方法設計

陸克中 朱金彬 李正民 隋秀峰

1(深圳大學計算機與軟件學院 廣東深圳 518060) 2(廣東工業大學計算機學院 廣州 511400) 3(國家計算機網絡應急技術處理協調中心 北京 100029) 4(計算機體系結構國家重點實驗室 (中國科學院計算技術研究所) 北京 100190)5(中國工程院戰略咨詢中心 北京 100088)

面向固態硬盤的Spark數據持久化方法設計

陸克中1朱金彬2,4李正民3隋秀峰4,5

1(深圳大學計算機與軟件學院 廣東深圳 518060)2(廣東工業大學計算機學院 廣州 511400)3(國家計算機網絡應急技術處理協調中心 北京 100029)4(計算機體系結構國家重點實驗室 (中國科學院計算技術研究所) 北京 100190)5(中國工程院戰略咨詢中心 北京 100088)

(kzlu@szu.edu.cn)

基于固態硬盤(solid-state drive, SSD)和硬盤(hard disk drive, HDD)混合存儲的數據中心已經成為大數據計算領域的高性能載體，數據中心負載應該可將不同特性的數據按需持久化到SSD或HDD，以提升系統整體性能.Spark是目前產業界廣泛使用的高效大數據計算框架，尤其適用于多次迭代計算的應用領域，其原因在于Spark可以將中間數據持久化在內存或硬盤中，且持久化數據到硬盤打破了內存容量不足對數據集規模的限制.然而，當前的Spark實現并未專門提供顯式的面向SSD的持久化接口，盡管可根據配置信息將數據按比例分布到不同的存儲介質中，但是用戶無法根據數據特征按需指定RDD的持久化存儲介質，針對性和靈活性不足.這不僅成為進一步提升Spark性能的瓶頸，而且嚴重影響了混合存儲系統性能的發揮.有鑒于此，首次提出面向SSD的數據持久化策略.探索了Spark數據持久化原理，基于混合存儲系統優化了Spark的持久化架構，最終通過提供特定的持久化API實現用戶可顯式、靈活指定RDD的持久化介質.基于SparkBench的實驗結果表明，經本方案優化后的Spark與原生版本相比，其性能平均提升14.02%.

大數據；混合存儲；固態硬盤；Spark；持久化

“大數據”描述了信息爆炸時代所產生的海量數據，它不僅聚焦于數據規模本身，更強調了數據量激增背景下的數據分析與應用所面臨的巨大挑戰[1].與傳統數據相比，大數據來源廣、種類豐富且格式多樣，其中囊括了結構化、半結構化和非結構化數據[2].目前，大數據已經滲透到人類社會的各行各業，已成為起決定性作用的生產要素.挖掘隱藏在大數據內部的有價值的信息，可以有效推進相關工作的展開，提高領導者的決策和管理水平[3-4].大數據技術是指從各種類型的大數據中快速提取高價值信息的能力，其中涉及數據的采集、清洗、存儲、管理、信息挖掘和可視化等內容.面對海量數據，如何在有效的時間內管理、分析并提取有價值的信息，成為人們亟需解決的問題.然而，無論是規模、種類還是結構，大數據對人們駕馭數據的能力提出了巨大挑戰.

Spark是目前高效且在產業界被廣泛使用的大數據計算框架，是通用、快速的大規模數據處理引擎[5].1)Spark提供了統一的解決方案，可以用于交互式查詢(Spark SQL)、實時流處理(Spark Streaming)、機器學習(Spark MLlib)等復雜任務；2)Spark通過彈性分布式數據集(resilient distributed dataset, RDD)劃分階段和任務，通過高效的有向無環圖(directed acyclic graph, DAG)執行引擎優化子任務執行順序，并通過基于內存的計算大幅提升數據處理效率；3)Spark數據管理依賴于HDFS,Hive等多種數據源，并且集群模式下的Spark實現了橫向擴展，支持大規模數據的處理.RDD是Spark區別于其他大數據計算框架最重要的概念，它是一種具有高度容錯機制的、只讀的分布式數據集.Spark應用程序中，每一個RDD會被分成多個分區，且Spark以分區為單位對RDD進行各種操作[6].

持久化(persist)RDD分區數據到內存或硬盤實現了對計算任務中間結果的緩存，以供后續迭代任務直接讀取中間結果，避免了重復計算，大幅提升了數據處理效率[7].另外，持久化數據到硬盤，打破了內存容量不足對數據集規模的限制，使得Spark處理大數據游刃有余.

固態硬盤(solid-state drive, SSD)的出現為提升存儲系統性能帶來了新的機遇，SSD具有低功耗、低延遲、體積小等優點[8].與傳統企業級硬盤(hard disk drive, HDD)通過移動機械臂來尋址方式不同，SSD完全構建于半導體芯片上，因此具有隨機訪問性能.然而，由于SSD容量成本過高、壽命有限等不足，完全使用SSD替換HDD會大幅提升產業成本.為了合理利用SSD的高性能和HDD的低廉價格等優勢，基于SSD和HDD混合存儲的異構數據中心得到人們普遍研究和應用[9].當前的研究主要涉及了SSD與HDD的組織架構以及容量比例分配，并針對不同特征的數據提出了合理、高效的數據存儲策略.目前，Google,Amazon,Facebook,Baidu等國內外大型互聯網公司都已經將SSD應用到數據中心的存儲系統中[10-12]，通過結合數據冷熱條件，實現了數據的按需持久化，提升了系統整體性能.

然而，數據中心計算框架Spark所提供的數據持久化語義對存儲介質不具備感知能力，無法實現RDD分區數據的按需持久化.具體而言，在Spark迭代計算任務中，不同RDD的重復利用率往往不同，顯然，將不同重復利用率的RDD有選擇地持久化到SSD或HDD，充分利用SSD高速讀寫和HDD大容量的特性，可有效提升Spark性能，而原生Spark提供的單一持久化語義根據Spark配置信息按照比例地放置RDD分區的存儲位置，針對性和靈活性不足，無法實現上述按需持久化目標.因此，基于混合存儲系統，為應用的開發者提供面向不同存儲介質的RDD持久化編程接口，實現用戶根據程序中數據的不同特征有針對性地進行數據的持久化成為進一步提升Spark性能的關鍵技術之一.

本文首次基于混合存儲系統提出面向SSD的數據持久化策略.探索了Spark數據持久化原理，并基于SSD和HDD的混合存儲系統優化了Spark的持久化架構.設計DeviceAdapter模塊完成存儲設備的映射，并提供顯式持久化API實現RDD的按需持久化.

1 研究背景

1.1 存儲異構數據中心的發展

IDC的研究報告指出：“自2005年至2020年，人類社會所產生的數據將增長300倍——從130艾字節增長到40 000艾字節”[13].數據的爆炸式增長從根本上改變了傳統數據的規模、種類和結構等，催生了新一代數據中心的數據存儲和管理方式的變革.尤其對于大數據分析型數據中心，其任務高頻率的讀、寫磁盤操作對數據中心存儲系統的性能提出巨大的挑戰.SSD的引入，顯著地提升了數據中心的性能和能效.SSD可以幫助企業在一個快速發展的大數據時代中最大限度地提升數據的存儲和分析效率.目前，諸多新興技術可以有效地提升SSD的I/O帶寬和降低訪問延遲.而HDD仍然能為那些對存儲性能要求較低的數據提供大量的存儲效率.IDC的研究數據顯示，大量的數據被數據中心收集并捕獲后，并不經常被訪問，稱之為冷數據，約占全球數據的90%；而剩余的10%的數據被收集并捕獲后，會經常性地被訪問，稱之為熱數據.顯然，將全部的數據都存儲在高性能、低延遲的存儲設備是不合理的，成本是極為昂貴的.因此，將SSD和HDD以合理的方式進行組合，通過構建混合存儲系統有可能帶來性能的大幅提升，同時保障成本可控.

目前，基于SSD和HDD混合存儲的異構數據中心在學術界得到廣泛研究，其從組織結構上分為2類：1)SSD作為HDD的緩存[14-16];2)SSD作為HDD的同層持久化存儲[17-18].在SSD作為HDD的緩存組織結構中，SSD負責存放HDD少量數據的拷貝，所有的數據請求優先查找SSD，如果請求的數據在SSD中就直接由SSD服務，否則從HDD上拷貝相應的數據到SSD中.這種分層結構，通過部署高命中率的數據映射機制，可以有效地提升存儲系統的I/O性能.在另一種結構中，SSD作為HDD的同層持久化存儲，用戶或系統可以根據數據的冷熱條件將不同類別的數據按需持久化到SSD或HDD，利用SSD高速讀、寫的特征來提升熱數據的訪問效率，同時，利用HDD大容量的特性來提升數據的存儲效率，從而提升系統的整體性能.本文基于該結構展開面向固態硬盤的Spark數據持久化方法的研究.在工業界，基于SSD和HDD混合存儲的異構數據中心已經得到了普遍的應用.如Google、Facebook、百度以及阿里云等國內外大型互聯網公司都已經將SSD引入數據中心，并結合自身業務需求，合理地構建了基于SSD和HDD混合存儲的異構數據中心.如圖1所示，三星公司的研究報告指出，基于SSD和HDD的混合存儲系統可以大幅度地降低數據中心能耗至原來的1/7，同時將數據中心性能提升2倍[19].

Fig. 1 Performance evaluation between traditional and heterogeneous data centers[19]圖1 傳統與存儲異構數據中心性能評估[19]

1.2 混合存儲系統中的Spark數據持久化問題

Spark的功能涵蓋了大數據計算的各個分支領域，如SQL類處理、實時流數據處理、機器學習和圖計算等復雜計算任務.Spark廣泛的應用范圍、簡潔易用的API，使得Spark已經成為越來越受歡迎的大數據計算平臺之一.Spark最重要的一項功能是持久化RDD分區數據到內存或硬盤，被持久化的分區數據可被其他迭代任務直接讀取，避免了重復計算.

在混合存儲系統中，根據數據的冷熱條件將不同類別的數據按需持久化到SSD或HDD，可有效提升數據的訪問和存儲效率.具體到Spark應用中，不同RDD的重復利用率往往不同，換言之，不同RDD的冷熱度存在明顯差異.因此，在僅考慮存儲層的持久化問題時，如將高熱度的RDD分區數據完全持久化到SSD，將熱度相對較高或基于其他原因的關鍵RDD分區數據持久化到HDD，充分發揮混合存儲的特性，可有效加速大數據的計算速度.然而，Spark所提供的持久化語義對存儲介質不具備感知能力，無法實現RDD分區數據的按需持久化.

針對該問題，做3組實驗進行驗證：將原生Spark2.0部署到僅配置一塊HDD、僅配置一塊SSD以及同時配置一塊HDD和一塊SSD三種服務器平臺上，同時在Spark配置文件中，每一塊存儲設備配置一個臨時文件目錄.圖2所示為我們設計的MicroBench的RDD轉換關系，其中RDD_a,RDD_b和RDD_e的依賴度比較高，所以我們對這3個RDD做persist(DISK_ONLY)持久化.以RDD的分區為單位，分別統計3種情況下被持久化的數據分布情況.

Fig. 2 Transformation of RDD in MicroBench圖2 MicroBench的RDD轉換關系

統計實驗結果發現，RDD_a,RDD_b和RDD_e全部被劃分為28個分區.第1組實驗中，3個RDD的分區數據全部被持久化到HDD；第2組實驗中，3個RDD的分區數據全部被持久化到SSD；第3組實驗中，每個RDD的14個分區被持久化到SSD，另一半被持久化到HDD.

統計結果表明，被持久化的RDD分區數據的分布和各實驗中臨時文件目錄的配置存在一定關系,即原生Spark僅按照臨時文件目錄個數比例來確認持久化數據的存儲位置.而在SSD和HDD混合存儲系統中，由于RDD_e的依賴度較高，希望將RDD_e完全持久化到SSD而RDD_a和RDD_b持久化到HDD，以此提升Spark數據處理效率是無法實現的.因此，原生Spark所提供的持久化語義靈活性較差，程序員無法根據Spark應用數據的特征，顯式地依據RDD的冷熱特性實現按需持久化.有鑒于此，本文將進一步探索面向SSD的數據持久化方法.

原生Spark持久化框架如圖3所示.其中，臨時文件目錄由用戶通過配置文件配置，且可以同時配置多個.臨時文件目錄的選擇決定了數據持久化地址，具體一個RDD的某一分區數據持久化地址的選擇是由Utils模塊的nonNegativeHash方法完成，該函數的設計原理是保持每一個目錄以相同的概率被選取.如上文所做的第3組實驗中，當配置了2個臨時文件目錄時，每個目錄都有50%被使用的概率.

Fig. 3 Persistence framework of native Spark圖3 原生Spark持久化框架

結合圖3所示Spark數據持久化框架可知，Spark對SSD的存在無感知能力的根本原因可歸納為3點：

1) Spark配置文件采用單一參數保存多個臨時文件目錄，將指向SSD和HDD的目錄進行混合管理；

2) nonNegativeHash方法未有效地區分不同臨時文件目錄所在存儲介質數據訪問性能的差異，等概率的選擇目錄；

3) 對不同的存儲介質，統一使用DISK_ONLY為上層應用提供持久化接口，而此接口通過StorageLevel反饋給用戶.

第2節將結合上述原因，提出在混合存儲系統中，面向SSD的顯式數據持久化方案，并以編程接口的方式提供用戶根據數據特征按需選擇持久化介質.

2 面向SSD的持久化

基于1.2節分析，研究Spark如何正確地感知混合存儲系統底層存儲設備，提供更為靈活的持久化API.首先，將底層存儲設備的差異暴露給用戶，打破DISK_ONLY的屏蔽作用，并向用戶提供更為精確的持久化API，實現Spark應用程序的按需持久化，具體實現如下.

如圖4所示，Spark持久化架構的具體優化方案如下：

Fig. 4 Persistence framework of optimized Spark圖4 優化版Spark持久化框架

1) 增加“SSD”和“HDD”臨時文件目錄管理變量，將臨時文件目錄的混合管理方式改為由“SSD”和“HDD”分別管理指向SSD和HDD的臨時文件目錄；

2) 增加設備適配器DeviceAdapter模塊，接收用戶設置的數據持久化級別，同時讀取用戶配置的臨時文件目錄，實現持久化級別參數到SSD或HDD的精確映射；

3) 增加SSD_ONLY和HDD_ONLY兩個持久化級別，將混合存儲系統特征暴露給用戶.同時，擴展StorageLevel的作用域，如圖3所示，StorageLevel僅作用于BlockManager，為用戶和BlockManager提供數據持久化級別.我們將StorageLevel作用域進一步延伸至DeviceAdapter模塊.

其中，DeviceAdapter的算法設計如下所述.

輸入：數據持久化級別StorageLevel、用戶標記的級別storageLevel、臨時文件目錄SSDLocation和HDDLocation；

輸出：數據持久化物理地址address.

procedure DeviceAdapter

callBlockManager.getFile;

Begin

switch(storageLevel)

address=SSDLocation;

address=HDDLocation;

End

End procedure.

3 性能評估

在Spark2.0版本基礎上，依據第2節對Spark框架做的優化，對Spark數據持久化功能模塊做了對應的修改，向用戶提供了新的持久化API(SSD_ONLY和HDD_ONLY)，并進行了重新編譯和系統地部署.本節分別基于如圖2所示的MicroBench和開源的SparkBench[20](其中的機器學習和圖計算2類負載)，針對原生Spark2.0和經本方案優化后的Spark進行性能評估實驗，并對實驗結果做充分地分析.

這里需要對SparkBench進行如下修改：將源代碼中的cache()方法全部替換成persist()方法，并且對于機器學習類負載將初始RDD數據集按照隨機比例進行分割，并且依據此比例將數據持久化到不同的存儲介質中；而對于圖計算負載，則是針對頂點和邊訪問特征的不同選擇持久化介質.介質的選擇是通過調用persist(SSD_ONLY)或persist(DISK_ONLY)接口來實現的.

實驗環境如表1～3所示，其中表1說明了Spark集群的搭建和服務器配置信息，表2說明了SSD-HDD混合存儲系統的配置信息，表3說明了服務器上的相關軟件版本及安裝信息.

Table 1 Spark Cluster Configuration表1 Spark集群及服務器配置信息

Table 2 SSD-HDD Heterogeneous Storage Configuration表2 SSD-HDD混合存儲系統配置

Table 3 Related Software Information表3 相關軟件信息

我們分別進行MicroBench和SparkBench實驗，驗證優化后的Spark可以實現RDD分區數據的SSD或HDD精確持久化，并在此基礎上通過不同的持久化方案可以有效地提升Spark性能.這里做如下說明，面向固態硬盤的Spark數據持久化方法設計，旨在充分利用混合存儲系統的大容量、高性能的特性，以提升Spark大數據計算效率.具體地，我們的目標是在最小化SSD的使用量的前提下，最大限度地提升Spark大數據計算效率，以此減少SSD的擦除次數，兼顧了實現綠色數據中心的目的.

3.1 MicroBench性能評估

本節通過MicroBench性能評估實驗，驗證面向固態硬盤的Spark數據持久化方法設計的正確性和靈活性，即實現了面向固態硬盤的Spark數據持久化方法.按圖2所示設計方案，首先驗證優化后Spark可以做到RDD分區數據按需持久化.對RDD_e調用persist(SSD_ONLY)做持久化，而對RDD_a和RDD_b則調用persist(HDD_ONLY)做持久化，統計結果如表4所示.統計結果顯示，優化后Spark的持久化結果完全按照程序員所調用的持久化API對分區數據進行存儲，實現了Spark應用程序中間數據面向固態硬盤的持久化，進而提升了Spark持久化API的靈活性.

Table 4 Partitions Distribution of Different Schemes Using Optimized Spark

下面分別對優化后的Spark和原生Spark，變化不同RDD的持久化介質進行更加深入的實驗分析.

Fig. 5 Performance evaluation of each RDD圖5 針對每一個RDD的持久化方案比較

圖5顯示的結果為：依次分別針對每一個RDD調用2種不同的持久化方法，圖5所示的MicroBench的執行時間，其中persist(DISK_ONLY)和+persist(SSD_ONLY)分別表示原生Spark和提供面向SSD的持久化接口的優化Spark.根據結果可獲知，在支持混合存儲系統的平臺上，相比于默認的按比例持久化方案，顯式調用面向SSD的接口進行持久化可以獲得更好的性能提升，這是因為該接口可將RDD的全部分區都存儲于SSD中，而不是原來的按比例在介質間分配分區.同時，性能提升的幅度也和RDD的訪問特征有著密切的關系.例如，根據圖2，RDD_e的依賴本來較多，但是由于它是利用filter操作生成的，使得其規模不大，因此即使不對其進行持久化性能影響也并不大，這就是圖5中持久化RDD_e的性能收益并不顯著的原因.

圖6是從RDD的串并行關系和RDD的計算復雜度、RDD的熱度等多個角度考慮不同持久化方案的比較，探索將哪些RDD按需持久化到SSD或HDD可以最大限度地提升系統性能.綜合圖5和圖6，對RDD_(c,h)調用本文提供的接口做持久化性能提升得更加明顯，其原因在于這些RDD的計算更加復雜并且后續使用頻繁，將其全部分區都持久化到SSD可獲得更大的性能收益.實驗結果表明，相對于原生Spark，本文所提持久化方案可以將性能平均提升2.7%，最大提升4.7%.

Fig. 6 Performance evaluation of schemes based on parallel and dependency圖6 基于并行和依賴關系的持久化方案比較

對已經持久化到存儲系統層的RDD，再選擇持久化到SSD或HDD，能夠進一步獲得的性能提升將與生成該RDD的計算復雜度以及該RDD后續被訪問的頻繁程度(熱度)有很大的關系，不妨將其稱之為依賴系數(RDD的依賴系數為該RDD的子RDD個數).由此，將高依賴系數的RDD分區數據持久化至SSD，相比于系統默認的按分區比例的持久化方案將獲得更加明顯的性能提升.盡管MicroBench實驗結果顯示，優化后Spark性能提升幅度有限，但這是當前使用的數據規模和應用復雜度簡單所導致的，顯然可以構造出效果更佳明顯的RDD訪問行為.

3.2 SparkBench性能評估

Spark作為目前流行的大數據計算框架，其十分擅長多次迭代計算任務(如機器學習、圖計算等).Spark應用程序的迭代次數與RDD持久化性能提升具有密切聯系，顯然，對于迭代次數多的RDD，將其持久化到SSD對Spark性能提升的幫助更大.另外，數據規模是Spark讀、寫硬盤時間消耗的重要影響因素.本節我們基于SparkBench實現了若干機器學習和圖計算負載，從數據量和迭代計算角度比較原生Spark和優化后Spark的性能.同時強調面向固態硬盤的Spark數據持久化方法的設計，旨在通過向Spark用戶提供顯示的面向固態硬盤的持久化接口，提升Spark數據持久化接口的靈活性和針對性，進而使得程序員可以根據Spark應用程序的數據特征，實現中間數據的按需持久化.結合SSD，HDD的各自特征與Spark應用程序數據的冷熱特性，將依賴系數較高的RDD持久化到SSD，以提升中間數據重復利用的讀取效率，將依賴系數相對較低的RDD持久化到HDD，以減輕SSD因頻繁讀寫而引起擦除操作的壓力，同時擴大了Spark應用程序可利用的存儲空間.而具體RDD持久化接口的選擇則依賴于程序員對應用程序的個人經驗.如下為SparkBench性能評估實驗結果的詳細分析.

圖7和圖8分別測試KMeans和Linear-Regre-ssion負載性能，通過改變數據規模評估原生Spark和優化后Spark，實驗結果顯示，系統性能平均提升19.72%，最大提升20.5%.同樣，針對機器學習算法，我們測試程序迭代次數對Spark性能的影響，圖9和圖10顯示結果為不同訓練規模下，原生Spark和優化后Spark的性能比較，優化后Spark性能平均提升10.04%，最大提升13.95%.

Fig. 7 Performance evaluation of KMeans圖7 Kmeans性能評估

Fig. 8 Performance evaluation of LinearRegression圖8 LinearRegression性能評估

Fig. 9 Performance evaluation of DecisionTree圖9 DecisionTree性能評估

Fig. 10 Performance evaluation of LogististicRegression圖10 LogististicRegression性能評估

Spark GraphX是一個分布式圖處理框架，它是基于Spark平臺提供對圖計算和圖挖掘簡潔易用的而豐富的接口，極大地方便了對分布式圖處理的需求.圖11和圖12分別通過測試SparkBench的典型圖計算負載PageRank和ShortestPath進行評估優化后Spark性能的優越性.隨著圖規模的不斷擴大，圖的結構不斷復雜化，即對Spark性能要求更高，實驗結果表明，優化后Spark性能平均提高11.79%，最大提高12.62%，且隨著圖的結構越復雜，優化后Spark的性能越顯著.

Fig. 11 Performance evaluation of PageRank圖11 PageRank性能評估

Fig. 12 Performance evaluation of ShortestPath圖12 ShortestPath性能評估

MicroBench和SparkBench性能評估結果說明，我們所提出并實現的按需持久化方案的性能明顯優越于原生Spark，該方案實現了Spark用戶依據應用程序特征，對RDD進行按需持久化，進一步提升了Spark大數據計算性能.經過分析RDD的DAG圖可以給出一些使用新的編程接口的啟發：對于自身計算復雜度較高并且后續使用比較頻繁的RDD，有針對性地將其持久化至SSD中，相比于Spark原有的處理方式將獲得更大的性能提升，當然這需要用戶對所開發的應用理解得更加深入，特別是不同RDD的訪問行為.

4 相關工作

進入“大數據”時代，大數據種類和數據量的激增以及其結構的復雜化給數據分析帶來了巨大的挑戰.如何快速、準確地挖掘隱含在大數據內部的高價值信息是目前研究的熱門問題，因此，人們研發出MapReduce，Spark等大數據計算框架.目前，國內外關于Spark的研究工作層出不窮，較多國內文獻利用Spark的高性能優勢設計了出色的大數據分析算法[21].文獻[4]介紹了大數據挖掘的若干挑戰性問題，文獻[22]回顧了近年來有關大數據計算框架、存儲及數據分析等問題的發展.目前較為流行的大數據計算框架有Hadoop和Spark，其中Spark基于內存計算且能夠持久化計算的中間結果，大幅提升了迭代計算任務的效率.MapReduce是目前已經非常成熟的大數據并行計算框架，且得到了較為普遍的應用.文獻[23-25]分別研究MapReduce應用于快速大規模數據檢索、可擴展的云數據匿名化方案和基于MapReduce模型實現了關鍵字感知的服務推薦系統，有效地提升了互聯網大數據分析工作的效率.另外，文獻[26]提出并設計了Mammoth模型，該模型通過內存調度算法實現內存的全局管理，并設計啟發式算法來優化執行單元之間的資源分配，提高了MapReduce性能.

文獻[27-29]中，作者分別從不同的角度出發研究如何提升Spark性能.其中，文獻[28]提出自適應調整策略，Spark在JVM的基礎上對內存做了進一步的管理，作者提出動態地調整Spark內存分配方案，進一步提升Spark數據處理效率.檢查點是Spark實現RDD容錯的一個重要概念，通過將某RDD設置為檢查點為快速恢復RDD提供了保障.文獻[29]提出了自動檢查點設置算法，以提升RDD的容錯性能、改進Spark迭代計算任務的效率，從而實現提升Spark性能的目的.作者在文獻[27]中分析了Spark大數據處理過程中Shuffle的產生及其對Spark性能造成的影響，并介紹了基于排序的shuffle可以提升Spark性能并應用到Spark1.1.0版本中.伴隨著人工智能產業的發展，機器學習成為當今學術界和產業界共同的熱門話題，且基于機器學習的大數據分析技術得到快速發展.由于Spark是基于內存的計算框架，且實現了計算中間結果的持久化功能，使得其在諸如機器學習、圖計算等多次迭代計算領域表現出色.作者在文獻[30]中介紹了Spark并行分布式機器學習庫，該庫基于數據和模型并行策略，實現對數據和模型存儲和相關操作.文獻[31]使用Spark更高效地利用大數據實現優秀的推薦系統引擎.

目前，關于Spark性能提升研究集中于Spark內存管理，通過調節JVM內存利用率提升Spark性能.然而，內存空間的不足限制了Spark通過內存加速超大規模數據的計算，而持久化數據到硬盤打破了內存容量不足對數據集規模的限制，使得Spark處理大數據游刃有余.本文首次基于混合存儲系統提出Spark性能優化方案.通過優化Spark的持久化框架，實現Spark數據的按需持久化.進而，Spark可以根據程序特征，將高熱度RDD的分區數據持久化到SSD，利用存儲異構數據中心的特征有效地提升Spark性能.

5 總 結

目前Spark無法精確持久化RDD分區數據到SSD或HDD，無法根據應用程序特征進行按需持久化，導致Spark無法充分利用混合存儲系統的彈性、高性能的優勢以提升自身性能.針對該問題，本文探索了Spark數據持久化原理，進而針對混合存儲系統對Spark的持久化框架進行優化，并向用戶提供了SSD_ONLY和HDD_ONLY持久化API，實現了Spark的顯示SSD和HDD持久化功能.本文通過分析HDD和SSD讀取性能并結合RDD讀取特征，理論論證了將RDD分區數據持久化到SSD或HDD以及混合存儲系統的性能差異.然后進一步通過基準性能評估實驗驗證了優化后Spark對應用程序性能提升明顯優于原生Spark.未來將進一步探索面向異構存儲系統的隱式持久化方案，即數據持久化介質的確定由Spark框架自動完成，對用戶是透明的.

[1]Labrinidis A, Jagadish H V. Challenges and opportunities with big data[J]. Proceedings of the VLDB Endowment, 2012, 5(12): 2032-2033

[2]Howe D, Costanzo M, Fey P, et al. Big data: The future of biocuration[J]. Nature, 2008, 455(7209): 47-50

[3]Kriegel H P, Borgwardt K M, Kr?ger P, et al. Future trends in data mining[J]. Data Mining and Knowledge Discovery, 2007, 15(1): 87-97

[4]Wu Xindong, Zhu Xingquan, Wu Gongqing, et al. Data mining with big data[J]. IEEE Trans on Knowledge and Data Engineering, 2014, 26(1): 97-107

[5]Zaharia M, Chowdhury M, Franklin M J, et al. Spark: Cluster computing with working sets[C/OL] //Proc of the 2nd USENIX Conf on Hot Topics in Cloud Computing (HotCloud). Berkeley, CA: USENIX Association, 2012[2017-01-18].http://static.usenix.org/legacy/events/hotcloud10/tech/full_papers/Zaharia.pdf

[6]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 Conf on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2012: 15-28

[7]Jiang Zhipeng, Chen Haopeng, Zhou Huan, et al. An elastic data persisting solution with high performance for Spark[C] //Proc of the 2015 Int Conf on Smart City/SocialCom/SustainCom. Piscataway, NJ: IEEE, 2015: 656-661

[8]Rizvi S S, Chung T S. Flash SSD vs HDD: High performance oriented modern embedded and multimedia storage systems[C] //Proc of the 2nd Int Conf on Computer Engineering and Technology (ICCET). Piscataway, NJ: IEEE, 2010: 297-299

[9]Narayanan I, Wang Di, Jeon M, et al. SSD failures in datacenters: What, when and why?[C] //Proc of the 9th ACM SIGMETRICS Int Conf. New York: ACM, 2016: 407-408

[10]Meza J, Wu Qiang, Kumar S, et al. A large-scale study of flash memory failures in the field[C] //Proc of ACM Sigmetrics Performance Evaluation Review. New York: ACM, 2015: 177-190

[11]Ouyang Jian, Lin Shiding, Hou Zhenyu, et al. Active SSD design for energy-efficiency improvement of Web-scale data analysis[C] //Proc of the 2013 Int Symp on Low Power Electronics and Design. Piscataway, NJ: IEEE, 2013: 286-291

[12]Schroeder B, Lagisetty R, Merchant A. Flash reliability in production: The expected and the unexpected[C] //Proc of the 14th USENIX Conf on File and Storage Technologies (FAST’16). Berkeley, CA: USENIX Association, 2016: 67-80

[13]Gantz J, Reinsel D. Extracting value from chaos, IDC IVIEW[R/OL]. Hopkinton, MA： EMC Corporation, 2011[2017-01-18].https://www.emc.com/collateral/analyst-reports/idc-extracting-value-from-chaos-ar.pdf

[14]Canim M, Mihaila G A, Bhattacharjee B, et al. SSD bufferpool extensions for database systems[J]. Proceedings of the VLDB Endowment, 2010, 3(1/2): 1435-1446

[15]Kang W H, Lee S W, Moon B. Flash-based extended cache for higher throughput and faster recovery[J]. Proceedings of the VLDB Endowment, 2012, 5(11): 1615-1626

[16]Ni Yuanjiang, Jiang Ji, Jiang Dejun, et al. S-RAC: SSD friendly caching for data center workloads[C] //Proc of the 9th ACM Int on Systems and Storage Conf. New York: ACM, 2016: 8:1-8:12

[17]Awasthi A, Nandini A, Bhattacharya A, et al. Hybrid HBase: Leveraging flash SSDs to improve cost per throughput of HBase[C] //Proc of the 18th Int Conf on Management of Data. Mumbai, India: Computer Society of India, 2012: 68-79

[18]Luo Tian, Lee R, Mesnier M, et al. hStorage-DB: Heterogeneity-aware data management to exploit the full capability of hybrid storage systems[J]. Proceedings of the VLDB Endowment, 2012, 5(10): 1076-1087

[19]SAMSUNG. SAMSUNG GREEN SSD[R/OL]. Austin, Texas: SAMSUNG SEMICONDUCTOR, INC, 2010 [2017-01-18].http://www.samsung.com/us/business/oem-solutions/pdfs/SSI-green_ssd_v4.pdf

[20]Li Min, Tan Jian, Wang Yandong, et al. Sparkbench: A comprehensive benchmarking suite for in memory data analytic platform Spark[C] //Proc of the 12th ACM Int Conf on Computing Frontiers. New York: ACM, 2015: No.53

[21]Zhu Jizhao, Jia Yantao, Xu Jun, et al. SparkCRF: A parallel implementation of CRFs algorithm with Spark[J]. Journal of Computer Research and Development, 2016, 53(8): 1819-1828 (in Chinese)

(朱繼召, 賈巖濤, 徐君, 等. SparkCRF: 一種基于Spark的并行CRFs算法實現[J]. 計算機研究與發展, 2016, 53(8): 1819-1828)

[22]Bilal M, Oyedele L O, Qadir J, et al. Big data in the construction industry: A review of present status, opportunities, and future trends[J]. Advanced Engineering Informatics, 2016, 30(3): 500-521

[23]Doulkeridis C, N?rv?g K. A survey of large-scale analytical query processing in MapReduce[J]. The VLDB Journal, 2014, 23(3): 355-380

[24]Meng Shunmei, Dou Wanchun, Zhang Xuyun, et al. KASR: A keyword-aware service recommendation method on MapReduce for big data applications[J]. IEEE Trans on Parallel and Distributed Systems, 2014, 25(12): 3221-3231

[25]Zhang Xuyun, Yang L T, Liu Chang, et al. A scalable two-phase top-down specialization approach for data anonymization using MapReduce on cloud[J]. IEEE Trans on Parallel and Distributed Systems, 2014, 25(2): 363-373

[26]Shi Xuanhua, Chen Ming, He Ligang, et al. Mammoth: Gearing Hadoop towards memory-intensive MapReduce applications[J]. IEEE Trans on Parallel and Distributed Systems, 2015, 26(8): 2300-2315

[27]Rana N, Deshmukh S. Performance improvement in Apache Spark through shuffling[J]. International Journal of Science, Engineering and Technology Research, 2015, 4(3): 1636-1638

[28]Zhao Yao, Hu Fei, Chen Haopeng. An adaptive tuning strategy on Spark based on in-memory computation characteristics[C] //Proc of the 18th IEEE Int Conf on Advanced Communication Technology (ICACT). Piscataway, NJ: IEEE, 2016: 484-488

[29]Zhu Wei, Chen Haopeng, Hu Fei. ASC: Improving Spark driver performance with automatic Spark checkpoint[C] //Proc of the 18th IEEE Int Conf on Advanced Communication Technology (ICACT). Piscataway, NJ: IEEE, 2016: 607-611

[30]Meng Xiangrui, Bradley J, Yavuz B, et al. Mllib: Machine learning in Apache Spark[J]. Journal of Machine Learning Research, 2016, 17(1): 1235-1241

[31]Kulkarni S. A recommendation engine using Apache Spark[D]. San Jose, CA: The Faculty of the Department of Computer Science San Jose State University, 2015

Lu Kezhong, born in 1982. PhD, professor at Shenzhen University. His main research interests include big data theory, parallel and distributed computing, wireless sensor networks, design and analysis of algorithms and computational geometry.

Zhu Jinbin, born in 1989. Master candidate. His main research interests include computer system architecture and design and analysis of algorithms.

Li Zhengmin, born in 1984. PhD candidate. His main research interests include cloud computing, network and network virtualization.

Sui Xiufeng, born in 1982. PhD, associate professor of the Institute of Computing Technology, Chinese Academy of Sciences. His main research interests include high performance computer archi-tectures, system performance modeling and evaluation, and cloud computing (suixiufeng@ict.ac.cn).

Design of RDD Persistence Method in Spark for SSDs

Lu Kezhong1, Zhu Jinbin2,4, Li Zhengmin3, and Sui Xiufeng4,5

1(CollegeofComputerScience&SoftwareEngineering,ShenzhenUniversity,Shenzhen,Guangdong518060)2(SchoolofComputerScienceandTechnology,GuangdongUniversityofTechnology,Guangzhou511400)3(NationalComputerNetworkEmergencyResponseTechnicalTeamCoordinationCenterofChina,Beijing100029)4(StateKeyLaboratoryofComputerArchitecture(InstituteofComputingTechnology,ChineseAcademyofSciences),Beijing100190)5(StrategicStudiesCentre,ChineseAcademyofEngineering,Beijing100088)

SSD (solid-state drive) and HDD (hard disk drive) hybrid storage system has been widely used in big data computing datacenters. The workloads should be able to persist data of different characteristics to SSD or HDD on demand to improve the overall performance of the system. Spark is an industry-wide efficient data computing framework, especially for the applications with multiple iterations. The reason is that Spark can persist data in memory or hard disk, and persisting data to the hard disk can break the insufficient memory limits on the size of the data set. However, the current Spark implementation does not specifically provide an explicit SSD-oriented persistence interface, although data can be distributed proportionally to different storage mediums based on configuration information, and the user can not specify RDD’s persistence locations according to the data characteristics, and thus the lack of relevance and flexibility. This has not only become a bottleneck to further enhance the performance of Spark, but also seriously affected the played performance of hybrid storage system. This paper presents the data persistence strategy for SSD for the first time as we know. We explore the data persistence principle in Spark, and optimize the architecture based on hybrid storage system. Finally, users can specify RDD’s storage mediums explicitly and flexibly leveraging the persistence API we provided. Experimental results based on SparkBench shows that the performance can be improved by an average of 14.02%.

big data; hybrid storage; solid-state drive (SSD); Spark; persistence

2017-02-27；

2017-04-14

國家“八六三”高技術研究發展計劃基金項目(2015AA015305)；廣東省自然科學基金項目(2014A030313553)；廣東省省部產學研項目(2013B090500055);深圳市基礎研究學科布局項目(JCYJ20150529164656096) This work was supported by the National High Research and Development Program of China (863 Program) (2015AA015305), the Guangdong Natural Science Foundation of China (2014A030313553), the Guangdong Science and Technology Foundation (2013B090500055), and the Shenzhen Science and Technology Foundation (JCYJ20150529164656096).

李正民(lzm@cert.org.cn)

TP303