基于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异步文件优先级分配

需要异步的文件分为无法重计算得到的文件、世系关系中的检查点文件和正常可重计算的文件3种.文件分配优先级的策略是基于文件的属性和文件被读取的次数.不可重计算获得的文件优先级比可重计算的文件优先级高,生成文件操作不具有幂等性的文件优先级比具有幂等性的文件优先级高,被多次读取的文件优先级比相同条件下读取次数少的文件优先级高,作为检查点的文件优先级比其他世系关系信息中记录的文件优先级高.因此,分配文件优先级的考虑因素包括该文件是否可以通过重计算获得、操作是否具有幂等性、是否作为检查点文件及其被读取次数.按权重配比,对于文件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.