一种基于起源信息的元数据预取策略

一种基于起源信息的元数据预取策略
吴国锦;胡程
【摘要】在分布式文件系统中,对元数据的预取能够减少元数据服务器的请求响应延迟时间.现有的元数据预取策略大多基于元数据的历史请求序列,并未考虑文件的起源信息.为此,提出一种基于起源信息窗口的元数据预取策略,通过分析进程行为与元数据请求的关联性,提取起源信息窗口,统计元数据文件之间的关联度,生成关联规则哈希表,进行更激进的元数据预取.实验结果表明,与传统的最近最少使用算法和基于权重有向图的元数据预取算法相比,该策略的Cache命中率分别提高49％和7％.与Nexus算法相比,能有效减少内存开销,提升关联规则的查询效率.
【期刊名称】《计算机工程》
【年(卷),期】2016(042)006
【总页数】6页(P1-6)
【关键词】起源信息;元数据;预取;文件关联;分布式存储
【作者】吴国锦;胡程
【作者单位】暨南大学信息科学技术学院计算机科学系,广州510632;暨南大学信息科学技术学院计算机科学系,广州510632
【正文语种】中文
【中图分类】TP311
中文引用格式：吴国锦,胡程.一种基于起源信息的元数据预取策略[J].计算机工程,2016,42(6):1-6.
英文引用格式： Wu Guojin,Hu Cheng.A Metadata Prefetching Strategy Based on Provenance Information[J].Computer Engineering,2016,42(6):1-6. 随着互联网的高速发展,高性能计算环境下存储系统的数据量剧增,数据存储量达到PB级别乃至EB级别。

数据量的指数级增长给传统存储系统带来巨大挑战,为提高存储系统的I/O性能,现今大多数分布式文件系统通常将文件数据和元数据分离,即数据流与控制流分离,从而获得更高的系统扩展性和I/O并发性,进而有效缓解了存储系统的I/O性能瓶颈[1-2]。

对于将文件数据与元数据分离的分布式文件系统,元数据的存储量只占总数据量的小部分,但元数据的I/O请求量却占所有I/O请求的50%～80%[3-4]。

另外,随着用户数据量与client数量的急剧增加,元数据服务器(Metadata Server,MDS)访问负载将越来越大,导致元数据请求响应时间延迟,降低了系统吞吐量。

利用数据访问的时间空间局部性特性,对元数据进行缓存预取能有效地提高元数据访问性能。

因此,本文利用起源信息,分析元数据的关联规则,给出一种基于起源信息的元数据缓存预取策略。

目前针对大规模存储系统的元数据预取策略的相关研究大多是通过分析历史的元数据请求流,挖掘文件之间的关联规则,从而预测未来的元数据访问请求。

文献[5]利用自然语言处理中的三元模型,分析历史的I/O请求流,计算文件之间同时出现的概率,提出AMP(Affinity-based Metadata Prefetching)预取机制;文献[6]利用可移动的历史窗口对元数据请求流进行关联性统计,存储在有向加权图中,提出基于有向加权图的元数据预取算法Nexus。

上述2种元数据预取算法相对于传统预取算法,一定程度地提高了元数据服务的I/O性能,但只是简单地对元数据的历史访问流进行分析,并没有应用元数据丰富的语义特性。

在应用元数据语义特性的研究中,文献[7]提出一种文件历史访问模式与文件属性相结合的文件关联性挖掘机制FARMER,有效地提高预取的准确率。

然而,FARMER
只是对文件属性进行相似度计算,同样没有考虑到文件被操作的进程行为信息,即起源信息。

文件的起源信息是一种记录该文件被操作的历史元数据,是文件演变的历史档案。

当前数据起源的相关研究集中在对起源信息的收集[8]、存储及查询的优化[9]。

在存储系统领域中,文献[10]结合起源信息提出一种云存储中元数据管理方法,有效地提高了元数据检索的性能。

上述工作只是单方面针对起源数据的研究,没有利用起源信息这种特殊的元数据去分析文件关联性,从而提高元数据服务的性能。

3.1 起源信息
根据开放起源信息模型(Open Provenance Model,OPM)[11]对起源信息的定义,起源信息由进程(P)、数据(A)、用户Agent(Ag)3个主体组成,三者的因果依赖关系包含5种关系模型:
(1) used:进程P存取过数据A;
(2) wasGeneratedBy:数据A由进程P产生;
(3) wasControlledBy:进程P的宿主用户是Ag;
(4) wasTriggeredBy:进程P1由进程P2触发;
(5) wasDerivedFrom:数据A2来源于数据A1。

由起源信息的因果关系可知,起源信息能够描述进程与文件、进程与进程、文件与文件之间的关系。

利用起源信息,能进一步挖掘出文件之间的关联性。

在存储系统中,文件不仅与文件存在关联性(wasDeriveFrom),文件也会与进程存在一定的关联性(used或wasGeneratedBy)。

如图1所示,用户看电影,触发进程P1请求访问元数据M。

随后,用户想撰写一篇文档,触发进程P2,P2先读取A文档,复制到新文档C,产生元数据请求A,C。

进程P3为打开PDF阅读器参考文献,产生元数据请求B,F,G。

进程P4为用浏览器查找资料,触发元数据请求D和E。

这一系列用户进程产生以下元数据请求:M,A,C,B,F,D,G,E。

根据OPM模型,图1中用户操作产生的起源信息如图2所示。

显然,在同一个时间段内被同一个进程操作的文件集合存在着关联性,如数据D,E。

此外,如果将互相触发关系(wasTriggeredBy)的进程集合称为一个任务,把这个任务的生命周期称为一个起源信息窗口,如进程集合P2,P3与P4构成的起源信息窗口。

显然,处于同一个起源信息窗口内被操作的文件集合也存在一定的关联性,如数据A,B,C,D,E,F,G。

对于2个不同起源信息窗口,如图1中存在看电影窗口与写文档窗口,生命周期分别为<1,2>与<3,8>,它们完成不同的工作,往往是不相关的,所请求的数据也是不相关的。

由此,处于同一个起源信息窗口下的I/O请求(A,B,C,D,E,F,G)之间是强相关的,处于不同的起源信息窗口下的I/O请求的关联性是弱相关的。

文献[5-7]都是简单地根据历史I/O请求流,忽略不同任务之间I/O请求的不相关性,降低关联规则的准确率。

如图1的I/O访问流M,A,C,B,F,D,G,E,看电影任务与写文档任务是不相关的,但上述研究都计算M与M,A,C,B,F,D,G,E的关联度。

因此,本文假设2个不同起源信息窗口里的I/O请求是不相关的。

通过提取起源信息窗口,过滤不相关任务之间计算关联性导致的噪声,从而提高预取的准确率。

3.2 起源信息窗口提取算法
为了更好地描述起源信息窗口以及相关算法,首先给出如下的相关基本概念。

定义1 一个进程P的生命周期表示为L(P),表示进程开始时刻st(start time)与进程结束时刻et(end time)的时间区间,即:
L(P)=[st,et]
定义2 对于2个进程Pa和Pb,存在时刻t,t∈L(Pa) 并且t∈L(Pb),则称Pa与Pb 是相关联的(wasTriggeredBy),表示为Pa∽Pb。

定义3 一个任务T是由n≥1个相关联的进程组成,表示为T={P1,P2,…,Pn}。

具有以下性质:
(1)任务T 的生命周期区间为:
(2)∀t∈L(T),∃P∈T,使得t∈L(P)。

(3)对于任何的2个不同任务T1,T2,具有不相交性:
L(T1)∩L(T2)=Ø
定义4 一个起源信息窗口为一个任务T的生命周期。

由于任务之间存在一定时间间隔,即定义3中性质(3)所描述的任务的不相交性。

因此,只要获取每个进程的生命周期,就可以式(2)决定每个起源信息窗口的边界。

对于常驻内存的后台守护进程,生命周期非常长,覆盖多个起源信息窗口,使得难以区分真实的用户起源信息窗口。

为解决这个问题,引入一个最大起源窗口长度的阈值max_strength时,当一个进程的生命周期大于max_strength,则认为是常驻的守护进程,通过这种方式,可以过滤无关的守护进程。

利用起源信息窗口的定义,算法1表示起源信息窗口的提取算法。

先对包含多个进程的生命周期列表按开始时间st进行排序,遍历整个进程列表。

当任务与新进程不相关联时,则生成一个新的起源信息窗口。

基于提取的起源信息窗口,进行后续的关联分数统计。

算法1的具体描述如下:
输入进程列表PLIST,包含开始时间和结束时间[st,et];最大起源窗口长度
max_strength
输出起源窗口列表TLIST
步骤:
1 任务 T;
2 //对进程列表PLIST按开始时间st排序
3 Sort(PLIST);
4 //用第一个进程的生命周期初始化任务T
5 T=P1;
6 forall进程P ∈ PLIST do
7 if P.et-T.st > max_strength then
8 //将大于最大长度,截断为新任务
9 TLIST.push(T);
10 T=[T.et,P.et];
11 else if P∽T then
12 //相关联,则继续扩长任务周期
13 T.et=P.et;
14 else
15 //不关联,产生新任务
16 TLIST.push(T);
17 T=P;
18 end
19 end
20 return TLIST
本节基于提取的起源信息窗口,介绍一种将起源信息窗口与元数据请求序列相结合的元数据预取策略ProMP。

ProMP可分为2步:(1)根据起源信息窗口内的元数据请求流,通过一个时间衰减的关联分数函数,统计两两的关联分数,并存储于键值数据库。

(2)根据历史的关联分数统计,生成关联规则列表,对未来元数据请求进行预取。

4.1 关联分数计算
在同一个起源信息窗口内,被请求的所有元数据都具有一定关联性。

按元数据请求的时间先后顺序,元数据请求与它的若干个后续请求存在关联。

为区别一个请求与其多个不同后续请求的关联强弱性,ProMP采用一个随时间递减的函数,为每2个不同元数据对象分配1个关联分数。

Sk=Sk-1-「Δt⎤,1≤k≤n
关联分数衰减函数用式(4)表示,具体如下:对于请求Q,后续请求为Q1Q2…Qn。

首
先分配一个关联初始分数值S0,经过Q与后驱请求Qk的时间间隔衰减,不断更新
关联分数Sk,则Q与Qk的关联分数为Sk。

循环直至关联分数Sk衰减到小于0,该元数据请求Q与后驱请求的关联分数计算结束。

通过图3来说明在一个起源信息窗口内的元数据对象两两之间关联分数统计算法。

假设S0为10,在一个起源信息窗口里面的元数据请求序列A,C,B,C,D,A,E以及请求的时间如图3所示。

对于A请求,利用式(4),计算出A与A的后驱请求的关联分数如下所示,如向量(A,C)表示元数据A到元数据C的关联分数:
(A,C)=S0-「0.5-0⎤=9→S1
(A,B)=S1-「1-0⎤=8→S2
(A,C)=S2-「1.1-0⎤=6→S3
(A,D)=S3-「3-0⎤=3→S4
(A,A)=S4-「3.5-0⎤=-1→小于0,停止。

同理,对每一个请求的元数据对象与
后驱的关联得分如图4所示,如果关联得分不大于0或者两对象相同,则获得的关联分数无效,用下划线表示。

通过公式计算每2个元数据对象的得分后,进行累加,可以得到这个起源信息窗口的两两关联分数值。

显然,2个不同的元数据对象的关联分数越大,其关联性越强。

当
起源信息窗口的数量不断增多时,元数据对象两两之间的关联分数将不断增加,文件之间的关联性将变得更加准确。

4.2 关联规则生成与存储
利用基于起源信息窗口的元数据关联算法,对大量的起源信息及历史元数据请求进
行关联分数计算,从而生成关联规则。

现今大数据处理模式可分为流处理和批处理
2种。

流处理是在线实时处理数据流,难度高,内存开销大。

批处理则是先存储后定
时离线处理,内存开销小,适用于实时性要求较低的应用场景[12]。

根据起源信息的
特性以及内存开销的考虑,ProMP的关联规则处理采用离线批处理模式。

ProMP为每一个元数据对象分配一个唯一对象号metanum,根据上述元数据关联算法,离线计算两两元数据的关联分数,存储于键值型数据库Tokyo Cabinet中。

根据关联分数数据库,选取每个元数据对象的强关联对象号列表,即关联分数最高的
少数元数据对象。

如图5所示,以元数据对象号metanum作为关联哈希表的索引,存储强关联列表。

在后续的元数据请求发生缓存不命中时,通过查找关联哈希表,选
择相应的元数据对象列表,向元服务器发送元数据请求,批量预取到客户端的缓存中,从而减少了元数据请求的网络通信开销。

5.1 实验环境
实验使用Lasr[13]、Web和Res[14]这3个现实世界的trace数据来评估和分析ProMP元数据预取策略。

表1描述这3个数据集的特征。

Lasr数据集是来自UCLA的计算机实验室,以系统调用的方式收集科学实验的I/O请求trace数据集。

Web数据集是一个在网上图书馆Web服务器集群收集的用户I/O请求trace数
据集。

Res数据集来源于运行在HP-UX 9.05机器上700台工作站集群的I/O请
求traces,主要是科研文档编写项目开发的工作类型。

这3个数据集包含文件数据和元数据的所有I/O请求,为评估元数据预取算法,这里过滤普通文件的I/O请求,如读写,只保留元数据I/O操作相关的系统调用作为元数据I/O请求流,以三元组<时间戳,系统调用,操作的元数据对象>代表一个元数据访
问请求。

表2为Web数据集所保留的系统调用,这些系统调用都将访问文件的元
数据。

这3个数据集不仅包括I/O相关的系统调用,还包括fork,exit等进程行为的系统调用。

以进程第一次执行I/O请求为开始时间st,以exit调用为结束时间et,从而获
取每个进程的生命周期。

利用算法1计算出起源信息窗口,进行关联分数统计。

为评估不同Cache大小对算法性能的影响。

实验通过假设每个元数据的大小相同,以Cache所能容纳元数据个数为标准,选取了Cache大小分别为100个、400个、700个、1 000个、1 500个元数据,评估ProMP在不同Cache Size下的效果。

5.2 预取命中率比较
由于传统的预取策略适用于容量较大的普通数据,预取错误将造成Cache浪费,性能惩罚大,使得预取准确率非常重要。

然而,针对容量较小的元数据,元数据预取可以贪心地预取多个元数据,实验中选取预取个数为8个,以充分利用Cache空间,提高Cache命中率。

因此,高的预取准确率并不能代表一个元数据预取算法能获得高Cache命中率。

在分布式存储中,总的Cache命中率包括3个部分:客户端本地Cache命中率,远程元数据服务器的Cache命中率以及协作缓存命中率。

客户端本地Cache命中率最能反映一个预取算法的性能。

因此,实验以客户端本地Cache命中率作为衡量预取算法性能的评估标准。

实验实现了3个不同缓存预取算法:(1)传统的缓存预取算法——近期最少使用算法(LRU)。

(2)文献[6]提出的基于有向加权图的元数据预取算法Nexus,是目前获得最好Cache命中率的元数据预取算法之一。

(3)本文所提出的基于起源信息窗口,离线计算关联分数得出关联列表的元数据预取算法ProMP。

利用Lasr,Web和Res数
据集,分别测试了LRU,Nexus和ProMP的客户端本地Cache命中率,并进行性能
对比。

图6为Lasr、Web和Res数据集的Cache命中率比较。

从图6(a)和图6(b)中可以得出,对于不同的Cache大小,ProMP的Cache命中率都明显大于LRU的Cache命中率,ProMP也比Nexus的Cache命中率有一定的提升。

综合比较Lasr和Web数据集,ProMP的Cache命中率以7%的优势大于Nexus算法,且与LRU算法比较,Cache命中率高出了49%。

对于Res数据集,如图6(c)所示,由于LRU的Cache命中率达到90%,Nexus算法
已经达到了95%,Cache命中率难以继续提升,因此ProMP算法较Nexus没有明显的Cache命中率提升。

此外,如图6(a)所示,对于Lasr数据集,ProMP能够在Cache空间较小时获得较好的Cache命中率。

当Cache大小为100时,ProMP的Cache命中率相当于Nexus在Cache大小为1 500时的Cache命中率。

这是由于ProMP采用起源信息窗口对不同任务进行隔离,减少不同任务间的I/O请求的属于噪音的关联计算,使得在统计关联分数时能够考虑更多正确的元数据对象,在进行大规模预取时,保证预取的准确率,因此有效地提高了Cache的空间利用率。

5.3 内存开销对比
ProMP预取算法采用离线批处理模式,空间开销由磁盘上的键值数据库与内存的关联规则组成。

起源信息和关联分数信息存储在磁盘上的键值数据库,离线更新关联规则存储在内存中,以供元数据预取。

相比于磁盘,内存容量小、价格贵,成为计算机性能的重要影响因素[15]。

因此,实验以内存开销作为衡量元数据预取算法好坏的另一个标准。

文献[6]中所提出的元数据预取算法Nexus根据元数据访问流计算文件关系图,存储在邻接矩阵描述的有向加权图中。

然而,在大规模存储系统中,数据对象个数达到十万级乃至百万级,使用邻接矩阵的Nexus算法占用内存空间过大,难以衡量。

因此,实验用稀疏矩阵代替邻接矩阵存储Nexus算法的有向加权图,与ProMP算法的内存开销进行比较。

图7为3个数据集下2个算法内存开销对比,可以发现ProMP 算法付出磁盘存储空间的代价后,在Web数据集下的内存开销比Nexus减少了一半;在Lasr和Res数据集中,内存开销也明显减少。

5.4 关联规则查询效率对比
由于元数据预取算法不同于传统普通文件预取,它将预取多个元数据,因此关联规则查询效率也是影响一个元数据预取算法的因素之一。

从图8中可以发现,ProMP的
关联规则查询响应时间明显快于Nexus算法。

这是由于Nexus算法实时更新文件关联图,选择预取对象时需遍历图,找出关联度最高的几个元数据对象。

相对
地,ProMP牺牲磁盘存储空间,离线统计关联度并更新内存中的关联规则哈希表,故关联规则查询复杂度为O(1),减少了关联规则的查询响应时间。

本文提出一种基于起源信息窗口的元数据预取策略ProMP。

ProMP通过收集用户的进程行为,提取起源信息窗口,以时间衰减函数离线计算起源信息窗口内元数据之间的关联性,应用在分布式文件系统的元数据服务中。

实验结果表明,本文的ProMP 预取策略能有效地利用Cache的空间,使得客户端本地元数据的Cache命中率相对LRU,Nexus 2个算法有所提高,从而在一定程度上解决元数据服务器的访问延迟问题。

此外,ProMP需在磁盘中存储起源信息,牺牲磁盘的存储开销后,能够有效减少内存开销,同时提升关联规则的查询效率。