基于Alluxio的異步存儲優化

溫東新　 董文菁　 曹　瑞　 張　展

(哈爾濱工業大學計算機科學與技術學院, 哈爾濱 150001)

受輸入輸出流的限制,現行框架[1-2]和存儲系統[3-6]無法更高效地進行大規模數據并行處理.數據緩存[7]是最通用的提升數據讀寫性能的方法,但由于容錯的需要,實際操作中會對節點間的寫數據進行復制備份.然而,數據復制過程中網絡延遲高以及吞吐率性能低下都會降低寫過程的性能.

Alluxio(原名Tachyon)是以內存為中心的虛擬分布式存儲系統[8],在大數據生態系統中介于計算框架和底層存儲之間.其利用世系思想[9]避免重復復制引發的吞吐率降低,采用重計算而非數據備份進行數據恢復,利用底層存儲的容錯機制保證已持久化數據的可靠性.針對底層存儲,采用同步存儲方式會導致讀寫速度難以匹配計算速度,進而影響系統性能,而采用異步存儲則可以在不影響性能的情況下完成數據的持久化.

本文提出了一種適用于遠程應用場景的結合文件操作的異步存儲策略Async-Store.為保證數據可靠性,進一步提出同步與異步相結合的策略Async&Sync.Async-Store策略采用傳輸操作的方式,利用底層存儲的計算資源完成數據持久化過程,減輕網絡傳輸數據的壓力,提升異步存儲性能.

1　異步存儲基礎與架構

1.1　Alluxio遠程應用場景

Alluxio作為一個內存級別的虛擬分布式存儲系統,其主要應用場景之一是遠程應用場景,即計算層需要反復訪問遠程存儲的數據.在百度與去哪兒的實際應用中,Alluxio作為核心存儲層與計算系統部署在一起,存儲系統如HDFS則作為底層存儲位于遠端機房,用于備份所有數據.

1.2　Alluxio寫數據

Alluxio包括2種存儲類型:管理存儲和底層存儲.Alluxio的寫類型包括4種:數據同步到底層存儲、異步到底層存儲、只在Alluxio中的存儲和直接寫到底層的存儲.同步存儲表示程序必須等待數據完成持久化后才能返回成功.異步存儲表示數據寫入Alluxio后立即返回成功,然后在后期進行持久化操作.Alluxio支持的異步存儲方式目前處于實驗階段,在當前1.2.0版本中支持單節點異步存儲[10].

1.3　Alluxio世系關系

Alluxio的世系關系日志記錄了文件之間的生成關系[9].生成世系關系的前提是生成文件的操作具有冪等性.通過訪問日志可以獲得生成某文件的具體操作信息,根據這些信息利用重計算來恢復丟失數據.因此,在數據持久化過程中,傳輸操作能有效減緩網絡的數據傳輸壓力.

1.4　異步存儲架構

異步存儲策略包括3個模塊:文件預處理模塊、異步存儲模塊和故障處理模塊(見圖1).文件預處理模塊負責對異步文件進行組織分配,按照是否可重計算、可替換等條件管理文件.異步存儲模塊將進入異步隊列的文件按照優先級排列,根據異步策略持久化文件,保證數據一致性,以不影響程序運行為前提完成數據持久化過程.發生故障后,故障處理模塊根據異步存儲的狀態進行處理,以保證數據能夠有效持久化.

圖1　異步存儲架構

2　異步存儲策略實現

2.1　文件預處理模塊

2.1.1文件類型分配

在異步策略中,文件被分為需要異步的文件和暫不需要異步的文件2個部分.針對需要異步的文件,根據生成該文件的操作是否具有冪等性,將其分為可重計算恢復的文件和無法重計算恢復的文件.暫不需要異步的文件主要包括已經完成持久化的文件和用戶標注不需要異步的文件.

2.1.2異步文件隊列

當引入一個需要異步的新文件時,需判別該文件是否可以利用重計算恢復.不能利用重計算恢復的文件的異步優先級高于可以利用重計算恢復的文件.在異步過程中,通過預測文件重計算時間和傳輸時間進行異步策略分配.圖2給出了一個由原始文件集1通過一系列操作生成各種文件集的重計算隊列.默認文件集1已完成持久化操作.對于可重計算隊列中的文件n,其相應世系關系中的文件m(m

圖2　世系關系信息鏈舉例

2.1.3數據替換

緩存滿時可替換已經完成持久化的文件和不需要持久化的文件.可用的緩存替換算法有很多,Alluxio支持LRU,LRFU等替換算法[7].

當可替換的文件容量小于新文件大小時,可以占用部分可重計算的文件容量.為避免影響文件恢復速度,選擇位于特殊位置的文件進行替換,例如利用位于重計算隊列中奇數位置的文件通過一步冪等操作即可恢復相應偶數位置的文件.如果新文件很大,對其采用直接存到底層存儲的方式,而非占用過多的內存資源[8].

2.2　異步存儲模塊

異步存儲設置的關鍵是在后臺異步執行存儲操作且不停止當前執行的應用程序.理想的異步存儲策略需要滿足以下幾點:① 為重要文件進行優先異步;② 盡量避免對臨時文件的異步;③ 異步存儲滿足一定的效率,如果時間過長導致文件數據丟失或者失去意義則會形成無效的異步.

2.2.1異步文件優先級分配

需要異步的文件分為無法重計算得到的文件、世系關系中的檢查點文件和正?？芍赜嬎愕奈募?種.文件分配優先級的策略是基于文件的屬性和文件被讀取的次數.不可重計算獲得的文件優先級比可重計算的文件優先級高,生成文件操作不具有冪等性的文件優先級比具有冪等性的文件優先級高,被多次讀取的文件優先級比相同條件下讀取次數少的文件優先級高,作為檢查點的文件優先級比其他世系關系信息中記錄的文件優先級高.因此,分配文件優先級的考慮因素包括該文件是否可以通過重計算獲得、操作是否具有冪等性、是否作為檢查點文件及其被讀取次數.按權重配比,對于文件i而言,其優先級設定為

Pi=ax1+bx2+cx3+dx4

式中,x1,x2,x3∈{0,1},且x1=1表示系統中存在生成文件i的相應操作信息,x2=1表示該操作信息具有冪等性,x3=1表示文件i屬于檢查點文件;x4為文件i被讀取的次數;a,b,c,d為權重,具體數值需依照實際運行環境進行分配.

2.2.2傳輸策略設計

對于無法重計算獲得的文件只能利用傳送數據來進行持久化.對于具有操作信息的文件,以某個固定數據量為界限,數據量小的文件可以在短時間內進行數據結果的傳輸,如詞頻計算的結果.超過一定數據量的文件根據其操作是否具有冪等性進行劃分,對不具有冪等性的文件采用傳輸數據的方式,對具有冪等性的文件采用傳輸操作的方式,如對大文件的清洗操作.

針對非世系關系中的檢查點文件,選擇在操作結束后對文件數據進行傳輸,從而避免程序在運行過程中傳輸與復制臨時文件,避免存儲資源與網絡資源的浪費.針對傳送操作,需考慮操作執行的前提條件,如該操作的源文件是否已經完成持久化、操作在底層計算資源中的預估計算時間與直接傳送數據的預估傳輸時間的對比.傳輸數據時需選擇傳輸數據的執行節點,為提升數據傳送效率,需根據文件數據塊所處位置進行判斷,選擇存在最多連續數據塊的空閑節點執行數據傳輸操作,若不存在則尋找距離這些數據塊最近的空閑節點執行.

2.2.3數據一致性保證

由于Alluxio是一次寫入多次讀取,數據具有不變性且只提供數據之上的擴展操作[8],因此Alluxio中不會發生因數據更改造成的數據不一致現象.異步存儲過程中,導致數據不一致現象發生的情況主要包括:① 系統故障導致的數據塊丟失;② 文件發生替換時一旦未持久化的數據塊被替換出去會導致數據塊丟失,引起數據不一致現象;③ 數據傳輸過程中受網絡影響等因素導致數據變化引起的數據不一致現象.

在數據塊丟失情況下,無法重計算恢復且尚未完成持久化操作的文件是不支持進行替換操作的.可重計算文件在未完成持久化之前發生數據丟失時,可以通過重計算進行恢復.數據已發生部分丟失且無法重計算恢復的文件則只能拋出異常交由上層應用處理.

針對傳輸過程發生的數據不一致現象,通過校驗和進行檢查.完成持久化處理之后,由底層存儲的相應機制來保證數據的一致性.

2.2.4異步開銷

為不影響當前工作任務,在執行過程中將異步策略分配優先級設置得較低.在文件進行異步過程中,具有冪等性的大文件采用傳操作方式,避免占用計算集群資源和網絡資源,小文件使用直接傳輸數據的方式.異步策略的開銷對集群運行影響較小.

2.2.5異步與同步相結合

異步策略能夠在維持性能的前提下盡可能完成數據的持久化,但無法完全避免數據丟失.例如,用戶從本地將大型文件導入到集群中,再將本地文件刪除,在數據完成持久化處理前,系統發生任何異常都可能導致數據永久性丟失.對無法恢復的重要文件采用異步存儲會出現數據不可用的情況,這時可結合同步操作來保證數據的可用性.通過采用同步與異步相結合的方式,針對不可恢復的重要文件采用同步策略,最大化保證數據的可靠性.

2.3　故障處理模塊

Alluxio利用底層存儲的容錯機制來保證數據在底層存儲上的可靠性,利用世系關系[9]進行未持久化文件的容錯.Alluxio集群因系統故障可能會發生數據丟失,對已完成持久化或未發生數據塊丟失的文件不需要進行處理,發生數據塊丟失的文件通過世系關系信息重計算進行數據恢復,對無法重計算的文件交則由上層應用處理.整個系統有2種情況會使文件無法通過重計算恢復:① 生成該文件的操作不具有冪等性;② 生成該文件操作的源文件不存在于集群中.

系統發生故障后,異步文件包括正在進行數據持久化的文件、操作持久化的文件和等待進行異步的文件.對于處于操作持久化或待異步中的文件,只要傳輸操作的前提條件滿足即可進行持久化操作.對于處于數據持久化中的文件,只能等待世系關系重計算恢復文件后重新傳輸.無法恢復數據的文件只能拋出異常,交由上層應用處理.Async&Sync策略將無法重計算獲得的文件進行同步存儲,使得異步存儲的文件均為可重計算獲得的文件,即使發生故障也可以保證數據完成持久化.

3　實驗

實驗中的計算中心是搭建在浪潮服務器上的一個虛擬機集群,Alluxio容量設置為56 GB.存儲中心是搭建在刀片服務器上的一個虛擬機集群,HDFS容量為1.5 TB.

實驗中,作為測試的工作流是基于文件的一個分析工作流[8].如圖3所示,該工作流包括周期性的提取、轉換和加載,分為若干批次分別讀取數據源1～5 GB的數據,每批次包含5個Spark操作和4個MapReduce操作.利用Spark的轉換操作來仿真數據清洗過程,采用MapReduce的詞頻計算來仿真測試分析過程.

圖3　實驗工作流

實驗測試了CacheOnly,CacheThrough,Async-Store和Async&Sync四種持久化策略.其中CacheOnly和CacheThrough為Alluxio自帶的持久化方式.采用CacheOnly時數據不進行持久化;采用CacheThrough時數據使用同步方式進行持久化.

實驗中文件的計算時間與傳輸時間采用隨機數進行模擬.默認底層存儲足夠大,生成的文件都需要進行保存.只要完成文件持久化操作,就可以利用底層存儲的容錯機制來保證數據的可靠性.

實驗中采用文件丟失數來衡量數據丟失程度.當某個文件丟失了部分數據塊,則認為該文件丟失.

3.1　運行時間分析

程序運行時間見圖4.由圖可知,CacheOnly策略和Async-Store策略的時間消耗相當且最少,Async&Sync策略次之,CacheThrough策略最長.

圖4　程序運行時間

相比同步策略CacheThrough,Async-Store的運行時間縮短41%，Async&Sync的運行時間縮短26%,并保證了數據的可靠性，說明選擇同步策略雖然保證了數據的可靠性,但是犧牲了運行時間.

3.2　數據結果分析

從數據丟失的情況來看,CacheThrough與Async&Sync能保證數據不會丟失,CacheOnly則無法保證,Async-Store只能在不可重計算文件不丟失的情況下保證數據不丟失.本實驗中,采用CacheOnly策略時,由于存在數據替換操作,文件丟失的概率為53%,CacheThrough,Async-Store和Async&Sync均未發生數據丟失.通過程序比較方法,證明CacheTrough與Async-Store持久化到底層的數據完全一致.

由此可知,異步操作能在保證運行時間的情況下完成數據的持久化操作.同步與異步相結合的方式能以犧牲少部分性能來保證數據可靠性.

3.3　資源消耗分析

使用文獻[11]中方法對集群中異步策略的資源消耗進行分析,統計結果如圖5所示.Async-Store與CacheOnly在內存的消耗上基本一致,其中內存使用平均值分別為20.0和19.3,緩存消耗平均值為34.4和31.7.Async-Store的平均網絡流量輸出較CacheOnly高出約5 MB/s.由此可知,異步策略對集群資源的使用沒有產生很大影響.

3.4　故障處理分析

在故障處理實驗中采用節點宕機的方式模擬單點故障.節點故障導致存儲在該節點的數據發生丟失,利用2.3節中的方法進行相應處理,結果見圖6.由圖可知,程序相對無故障運行時間延長,在Async-Store中因故障丟失且無法重計算獲得的文件數約為需要完成持久化文件數的3%.Async & Sync通過同步方式對無法重計算的文件進行持久化操作,沒有發生數據丟失.

4　結語

異步存儲策略Async-Store依據操作信息,采用傳送冪等方式,利用底層空閑資源實現數據的持久化操作.實驗結果表明,該策略可以在不影響性能的情況下極大地保證數據可靠性.Alluxio本身提供了4種寫類型.如果在編寫程序的時候明確文件屬性,便可以直接進行相應文件的屬性配置.若內存容量足夠且結果只用一次,則可以將數據全部存儲在內存中.

(a) 內存使用對比

(b) 內存緩存對比

(c) 網絡流量輸入對比

(d) 網絡流量輸出對比

圖6　故障處理分析圖

參考文獻(References)

[1] Zaharia M, Chowdhury M, Das T, et al. Resilient distributed datasets: A fault-tolerant abstraction for in-memory cluster computing [C]//UsenixConferenceonNetworkedSystemsDesignandImplementation. Berkeley, CA, USA, 2012: 2.

[2] Vaidya M. MapReduce: A flexible data processing tool[J].CommunicationsoftheACM, 2010,53(1): 72-77.

[3] Ousterhout J, Agrawal P, Erickson D, et al. The case for RAMCloud[J].AcmSigopsOperatingSystemsReview, 2009,54(4): 121-130.

[4] Baker J, Bond C, Corbett J, et al. Megastore: Providing scalable, highly available storage for interactive services[C]//FifthBiennialConferenceonInnovativeDataSystemsResearch. Asilomar, CA, USA, 2011: 223-234.

[5] Escriva R, Wong B. HyperDex: A distributed, searchable key-value store[J].ACMSIGCOMMComputerCommunicationReview, 2012,42(42): 25-36. DOI:10.1145/2377677.2377681.

[6] Ghemawat S, Gobioff H, Leung S. File and storage systems: The Google file system[J].AcmSymposiumonOperatingSystemsPrinciplesBoltonLanding, 2003,37: 29-43.

[7] anonym. Tiered storage on Alluxio. [EB/OL].[2017-04-03].http://www.alluxio.org/docs/master/cn/Tiered-Storage-on-Alluxio.html.

[8] Li, Haoyuan, Ghodsi, et al. Tachyon: Reliable, memory speed storage for cluster computing frameworks[J].ACMTransactionsonNetworks, 2014,14: 1-15.

[9] Anonym. Lineage [EB/OL].[2017-04-12]. http://www.alluxio.org/docs/master/cn/Lineage-API.html.

[10] Anonym. Why the data in memory still not be persisted into hdfs with setting write type to “ASYNC_THROUGH” [EB/OL].(2016-10-12)[2017-04-03]. http://alluxio-users.85194.x6.nabble.com/Why-the-data-in-memory-still-not-be-persisted-into-hdfs-with-setting-write-type-to-quot-ASYNC-THROUG-td1295.html#a1526.

[11] Massie M L, Chun B N, Culler D E. The ganglia distributed monitoring system: Design, implementation, and experience[J].ParallelComputing, 2004,30(7): 817-840. DOI:10.1016/j.parco.2004.04.001.