基于Alluxio的異步存儲優(yōu)化

溫東新　 董文菁　 曹　瑞　 張　展

(哈爾濱工業(yè)大學(xué)計算機科學(xué)與技術(shù)學(xué)院, 哈爾濱 150001)

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

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

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

1　異步存儲基礎(chǔ)與架構(gòu)

1.1　Alluxio遠(yuǎn)程應(yīng)用場景

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

1.2　Alluxio寫數(shù)據(jù)

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

1.3　Alluxio世系關(guān)系

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

1.4　異步存儲架構(gòu)

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

圖1　異步存儲架構(gòu)

2　異步存儲策略實現(xiàn)

2.1　文件預(yù)處理模塊

2.1.1文件類型分配

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

2.1.2異步文件隊列

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

圖2　世系關(guān)系信息鏈舉例

2.1.3數(shù)據(jù)替換

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

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

2.2　異步存儲模塊

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

2.2.1異步文件優(yōu)先級分配

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

Pi=ax1+bx2+cx3+dx4

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

2.2.2傳輸策略設(shè)計

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

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

2.2.3數(shù)據(jù)一致性保證

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

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

針對傳輸過程發(fā)生的數(shù)據(jù)不一致現(xiàn)象,通過校驗和進(jìn)行檢查.完成持久化處理之后,由底層存儲的相應(yīng)機制來保證數(shù)據(jù)的一致性.

2.2.4異步開銷

為不影響當(dāng)前工作任務(wù),在執(zhí)行過程中將異步策略分配優(yōu)先級設(shè)置得較低.在文件進(jìn)行異步過程中,具有冪等性的大文件采用傳操作方式,避免占用計算集群資源和網(wǎng)絡(luò)資源,小文件使用直接傳輸數(shù)據(jù)的方式.異步策略的開銷對集群運行影響較小.

2.2.5異步與同步相結(jié)合

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

2.3　故障處理模塊

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

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

3　實驗

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

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

圖3　實驗工作流

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

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

實驗中采用文件丟失數(shù)來衡量數(shù)據(jù)丟失程度.當(dāng)某個文件丟失了部分?jǐn)?shù)據(jù)塊,則認(rèn)為該文件丟失.

3.1　運行時間分析

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

圖4　程序運行時間

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

3.2　數(shù)據(jù)結(jié)果分析

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

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

3.3　資源消耗分析

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

3.4　故障處理分析

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

4　結(jié)語

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

(a) 內(nèi)存使用對比

(b) 內(nèi)存緩存對比

(c) 網(wǎng)絡(luò)流量輸入對比

(d) 網(wǎng)絡(luò)流量輸出對比

圖6　故障處理分析圖

參考文獻(xiàn)(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.