CN108804556A - 基于时间旅行和时态聚合查询的分布式处理框架系统 - Google Patents
基于时间旅行和时态聚合查询的分布式处理框架系统 Download PDFInfo
- Publication number
- CN108804556A CN108804556A CN201810494066.9A CN201810494066A CN108804556A CN 108804556 A CN108804556 A CN 108804556A CN 201810494066 A CN201810494066 A CN 201810494066A CN 108804556 A CN108804556 A CN 108804556A
- Authority
- CN
- China
- Prior art keywords
- subregion
- node
- data
- index
- tense
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于时间旅行和时态聚合查询的分布式处理框架系统,包括分区单元、局部索引单元和全局索引单元;所述分区单元负责将所有数据分区到分布式节点;所述局部索引单元用于管理每个分区中的时态数据;所述全局索引单元用于管理分区间隔。本发明为时态大数据提出了一个分布式内存分析框架,该框架易于理解和实施,但不会损失效率,能满足高吞吐量和低延迟的需求。
Description
技术领域
本发明属于计算机领域,具体涉及时态数据的查询系统,尤其涉及一种基于时间旅行和时态聚合查询的分布式处理框架系统。
背景技术
对时态数据的管理已经研究了数十年,并且由于其广泛的应用,近来已经越来越受到关注[参见:M.Gupta,J.Gao,C.C.Aggarwal,J.Han:Outlier Detection for TemporalData:A Survey.In TKDE,2014;F.Li,K.Yi,W.Le:Top-k queries on temporal data.InVLDBJ,2010]。例如,用户可能希望在特定时间(例如,5年前)调查行政区域(例如加利福尼亚州)的人口统计信息。查询数据库的历史版本(如上所述)通常称为时间旅行[R.Elmasri,G.T.Wuu,and Y.J.Kim.The Time Index:An Access Structure for Temporal Data.InVLDB,1990;B.Becker,S.Gschwind,T.Ohler,B.Seeger,B.Widmayer:An asymptoticallyoptimal multiversion B-tree.In VLDBJ,1996;D.Lomet et al.Transaction TimeSupport Inside a Database Engine.In ICDE,2006]。另外一个例子,在质量保证部门,用户可能希望分析随着时间的变化有多少订单被延迟,从而在特定时间段内查询数据库的所有历史版本。像上面提到的查询通常被称为时态聚合[K.Cheng:On Computing TemporalAggregates over Null Time Intervals.In DEXA 2017;M.Kaufmann,P.M.Fischer,N.May,C.Ge,A.K.Goel,D.Kossmann:Bi-temporal Timeline Index:A data structurefor Processing Queries on bi-temporal data.In ICDE,2015;M.Kaufmann,A.A.Manjili,P.Vagenas,P.M.Fischer,D.Kossmann,F.F·arber,N.May:Timeline index:A unied data structure for processing queries on temporal data in SAP HANA.InSIGMOD,2013]。
在文献中,已经有大量的论文讨论了时间旅行和时态聚集查询的问题(参见[B.Becker,S.Gschwind,T.Ohler,B.Seeger,B.Widmayer:An asymptotically optimalmultiversion B-tree.In VLDBJ,1996;D.Lomet et al.Transaction Time SupportInside a Database Engine.In ICDE,2006;M.Kaufmann,A.A.Manjili,P.Vagenas,P.M.Fischer,D.Kossmann,F.F·arber,N.May:Timeline index:A unied data structurefor processing queries on temporal data in SAP HANA.In SIGMOD,2013;R.Elmasri,G.T.Wuu,and Y.J.Kim.The Time Index:An Access Structure for Temporal Data.InVLDB,1990;N.Kline,R.T.Snodgrass:Computing Temporal Aggregates.In ICDE,1995;T.C.Leung,R.R.Muntz:Temporal Query Processing and Optimization inMultiprocessor Database Machines.In VLDB,1992])。然而,以前的工作大部分都集中在开发基于单机的解决方案上,并且很少关注开发用于处理时态大数据的分布式解决方案。如今,各种应用(例如,网络应用和物联网应用)产生大量的时态数据。迫切需要有效处理大量的时态数据。特别是,在传统数据库系统中处理如此大量的时态数据是有挑战性的,因为基于单机的系统计算能力有限。显然,使用分布式系统处理如此大量的时态数据是一个不错的选择。最近,对大数据的分布式时态分析也进行了研究(例如[S.Zhang,Y.Yang,W.Fan,L.Lan,M.Yuan:OceanRT:real-time analytics over large temporal data.In SIGMOD,2014;B.Chandramouli,J.Goldstein,S.Duan:Temporal analytics on big data for webadvertising.In ICDE,2012])。这些工作至少有两个共同特征:(i)它们是基于磁盘的分布式时态分析系统;和(ii)他们的论文中没有包括时间旅行和时态聚合查询。随着数据量的激增,这些解决方案无法很好地满足高吞吐量和低延迟的需求。
Spark SQL[M.Zaharia,M.Chowdhury,T.Das,A.Dave,J.Ma,M.McCauley,I.Stoica:Resilient distributed datasets:A fault-tolerant abstraction for in-memory cluster computing.In NSDI,2012]就是这样一个引擎,它扩展了Spark(一种分布式内存计算引擎),使我们能够在Spark程序内使用SQL接口查询数据。为了支持具有高吞吐量和低延迟的时态大数据的分布式内存分析,本发明提出了一个基于内存的Spark两级索引解决方案(ITISS)。据我们所知,现有的大数据系统(例如Apache Hadoop,Apache Spark)都没有原生得支持时态数据查询,而且以前的工作都没有开发基于内存的分布式解决方案来处理时态大数据的时间旅行和时态聚合操作。
在时态数据库领域,先前的工作解决了与时态数据有关的各种问题。在文献中,大部分早期工集中在时态数据的语义[C.Bettini,X.S.Wang,E.Bertino,S.Jajodia:Semantic Assumptions and Query Evaluation in Temporal Databases.In SIGMOD,1995],逻辑建模[X.S.Wang,S.Jajodia,V.Subrahmanian:Temporal Modules:An ApproachToward Federated Temporal Databases.In SIGMOD,1993]和查询语言[I.Ahn,R.Snodgrass:Performance Evaluation of a Temporal Database ManagementSystem.In SIGMOD,1986]。最近,一些研究人员解决了从时态数据(如趋势分析[S.Gollapudi,D.Sivakumar:Framework and algorithms for trend analysis inmassive temporal data sets.In CIKM,2004]和数据聚类[Y.Yang,K.Chen:TemporalData Clustering via Weighted Clustering Ensemble with DifferentRepresentations.In TKDE,2011])中发现/挖掘有趣信息[C.Loglisci,M.Ceci,D.Malerba:A Temporal Data Mining Framework for Analyzing Longitudinal Data.InDEXA,2011]的问题。其他工作解决了时态数据的查询或搜索问题,如top-k查询[F.Li,K.Yi,W.Le:Top-k queries on temporal data.In VLDBJ,2010]和成员查询[G.Kollios,V.J.Tsotras:Hashing Methods for Temporal Data.In TKDE,2002]。还研究了与时态数据相关的一些最优问题,例如为时态大数据寻找最优分割器[W.Le,F.Li,Y.Tao,R.Christensen:Optimal splitters for temporal and multi-version databases.InSIGMOD,2013]。与通用数据库类似,在时态数据库中,连接操作也是常用操作;关于这个话题的研究可以在[D.Gao,S.Jensen,R.T.Snodgrass,D.Soo:Join operations in temporaldatabases.In VLDBJ,2005]中找到。由于时态数据涉及一个不断发展的过程,因此研究人员试图对进化轨迹进行建模[P.Wang,P.Zhang,C.Zhou,Z.Li,H.Yang:Hierarchicalevolving Dirichlet processes for modeling nonlinear evolutionary traces intemporal data.In DMKD,2017],并追踪时间数据库中的各种元素,如追踪不断发展的子空间群。上述工作与我们有关(因为这些工作也对时态数据进行处理)。然而,不难看出它们与我们的研究明显不同,因为我们的工作关注时间旅行和时态聚合查询,而不是上述问题,如趋势分析和逻辑建模。
尽管如此,现有的工作也着手解决了时间旅行和时态聚合查询问题。例如,考夫曼
等人[M.Kaufmann,A.A.Manjili,P.Vagenas,P.M.Fischer,D.Kossmann,F.F·arber,
N.May:Timeline index:A unied data structure for processing queries on
temporal data in SAP HANA.In SIGMOD,2013]提出了一种称为时间索引的统一数据结
构,用于处理对时态数据的查询,其中他们使用列存储来管理时态数据。通用时态索引结构
可以在[R.Elmasri,G.T.Wuu,and Y.J.Kim.The Time Index:An Access Structure for
Temporal Data.In VLDB,1990]中找到。此外,SAP HANA[F.Farber et al.The SAP HANA
Database{An Architecture Overview.In IEEE Data Eng.Bull.,2012]提供了基于恢复
过去事务快照的基本形式的时间旅行查询。ImmortalDB[D.Lomet et al.Transaction
Time Support Inside a Database Engine.In ICDE,2006]是另一个支持时间旅行查询的
系统。从行业角度来看,Oracle[Workspace Manager Valid Time Support.https://
docs.oracle.com/cd/B28359_01/appdev.111/b28396/long_vt.htm#g1014747],IBM
[C.M.Saracco et al.A Matter of Time:Temporal Data Management in DB2
10.Technical report,IBM,2012],Postgres[Postgres 9.2highlight-range
types.http://paquier.xyz/postgresql-2/postgres-9-2-highlight-range-types]和
SQL Server[Temporal Tables.https://docs.microsoft.com/en-us/sql/relational-
databases/tables/temporal-tables]等数据库供应商也将时间旅行查询集成到他们的系
统中。另一方面,Snodgrass等人[N.Kline,R.T.Snodgrass:Computing Temporal
Aggregates.In ICDE,1995]介绍了第一种计算恒定间隔的时态聚合算法。后来,提出了基
于AVL树的时态聚合算法[M.H.B·ohlen,J.Gamper,C.S.Jensen:Multi-dimensional
aggregation for temporal data.In EDBT,2006]。此外,还研究了使用范围谓词
[D.Zhang,A.Markowetz,V.J.Tsotras,D.Gunopulos,B.Seeger:On computing temporal
aggregates with range predicates.In TODS,2008]进行时间聚合,或者在极端情况下
(如空时间间隔[K.Cheng:On Computing Temporal Aggregates over Null Time
Intervals.In DEXA 2017])进行时态聚合。尝试使用多处理器机器进行时态聚合的工作可
以在[T.C.Leung,R.R.Muntz:Temporal Query Processing and Optimization in
Multiprocessor Database Machines.In VLDB,1992;M.Kaufmann,A.A.Manjili,
P.Vagenas,P.M.Fischer,D.Kossmann,F.F·arber,N.May:Timeline index:A unied data
structure for processing queries on temporal data in SAP HANA.In SIGMOD,2013]
中找到。在[R.Elmasri,G.T.Wuu,and Y.J.Kim.The Time Index:An Access Structure
for Temporal Data.In VLDB,1990]中讨论了支持时态聚合的高效索引结构。上述提议或
系统的一个主要特点是,它们专注于基于单机的解决方案,而很少关注开发用于处理时态
大数据的分布式解决方案。
实质上,我们也认识到,近年来,也有工作对时态大数据的分布式分析进行了调查[S.Zhang,Y.Yang,W.Fan,L.Lan,M.Yuan:OceanRT:real-time analytics over largetemporal data.In SIGMOD,2014]。它们与早期工作[J.A.G.Gendrano,B.C.Huang,J.M.Rodrigue,B.Moon,R.T.Snodgrass:Parallel Algorithms for Computing TemporalAggregates.In ICDE,1999](处理的数据相对较小)不同。尽管如此,这些作品至少有两个共同特征:(i)它们是基于磁盘的而不是分布式且基于内存的时态分析系统;和(ii)他们的论文中没有包括时间旅行和时态聚合查询。
因此,亟需研发一种基于时间旅行和时态聚合查询的分布式处理框架系统。
发明内容
本发明要解决的技术问题在于提供一种基于时间旅行和时态聚合查询的分布式处理框架系统,为时态大数据提出了一个分布式内存分析框架,该框架易于理解和实施,但不会损失效率,能满足高吞吐量和低延迟的需求。
为解决上述技术问题,本发明采用如下技术方案:
一种基于时间旅行和时态聚合查询的分布式处理框架系统,包括分区单元、局部索引单元和全局索引单元;所述分区单元负责将所有数据分区到分布式节点;所述局部索引单元用于管理每个分区中的时态数据;所述全局索引单元用于管理分区间隔。
作为本发明优选的技术方案,所述分区单元负责将所有数据分区到分布式节点,该分布式节点包括主节点和从节点,其中主节点负责分布式集群的资源调度和管理,从节点负责执行由主结点分配的任务;保证每个节点具有大致相同的数据大小,以保持负载平衡。
作为本发明优选的技术方案,所述局部索引单元,在每个分区中,维护局部索引以避免完整扫描;每个分区为全局索引的构建维护一个分区间隔,该分区间隔由一个分区中所有记录中时间间隔开始值的最小值和结束值的最大值组成。
作为本发明优选的技术方案,所述全局索引单元中,主节点收集从节点中每个分区的所有分区间隔,然后根据收集的分区间隔构建全局索引。
作为本发明优选的技术方案,所述分区单元采用如下分区方法:按时间间隔分割时间数据,包括如下步骤:
首先按时间间隔对时态记录进行排序,获得排序记录;将排序后的记录平均分成几个部分,即完成分区。
作为本发明优选的技术方案,所述局部索引单元,采用多版本B树MVB-Tree索引结构来支持时间旅行查询,采用SB-Tree索引结构来支持时态聚合查询;所述多版本B树MVB-Tree索引结构在每次对数据库进行更新(插入或删除)时生成一个新版本,从而一致性得记录数据库的更新记录,因此能查询数据库的历史版本;所述SB-Tree索引结构是一种支持时态数据聚集查询的索引结构,通过在索引内预计算聚集值,避免在查询时遍历所有数据记录,提高查询速度。
作为本发明优选的技术方案,所述全局索引单元,在主节点中,全局索引被设计为预先修剪查询不会涉及到的分区,以避免检查每个分区。
作为本发明优选的技术方案,所述每个分区间隔能通过起始值和间隔长度进行比较,使用二叉搜索树来维护分区的间隔信息;只对分区使用一个分区间隔;全局索引中的每个分区间隔对应于从节点中的分区,在查询处理中,如果一个分区间隔可以被修剪,则可以安全地修剪相应的分区;全局索引中的每个节点都维护一个键值对<Ip,id>,其中Ip和id分别指分区间隔及其相应的分区。
所述二叉搜索树(Binary Search Tree),(又:二叉查找树,二叉排序树)它或者是一棵空树,或者是具有下列性质的二叉树:若它的左子树不空,则左子树上所有结点的值均小于它的根结点的值;若它的右子树不空,则右子树上所有结点的值均大于它的根结点的值;它的左、右子树也分别为二叉排序树。
与现有技术相比,本发明具有以下有益效果:
1、本发明为时态大数据提出了一个分布式内存分析框架。本发明的框架易于理解和实施,但不会损失效率。
2、在Apache Spark中实现了本发明的框架,并扩展了Apache Spark SQL,使用户能够使用SQL语句执行时态查询。
3、本发明使用真实和合成时态数据集对提出的解决方案进行了全面的实验评估。实验结果证明了本发明解决方案的效率和竞争力。
4、本发明系统能满足高吞吐量和低延迟的需求,克服现有系统存在的缺陷。
5、本发明在分布式系统中使用内存计算技术,避免I/O(输入(Input)和输出(Output))瓶颈。
6、本发明使用了针对时态数据的二级索引结构,结合分布式内存计算,将时态操作的查询效率提高了1~2个数量级。
附图说明
下面结合附图和实施例对本发明进一步说明。
图1是本发明中一个时态数据库的示意图。
图2是本发明基于时间旅行和时态聚合查询的分布式处理框架系统的结构示意图。
图3是不同分区方法的比较示意图。其中,图3(a)为本发明采用的范围分区方法,图3(b)为哈希分区方法;
图4是本发明系统中使用的索引结构示意图。其中,图4(a)代表MVB-Tree索引结构,图4(b)代表SB-Tree索引结构,图4(c)代表全局剪枝索引结构。
图5是本发明实验中索引建立时间和存储开销示意图。其中,图5(a)代表局部索引构建vs.|D|,图5(b)代表局部索引大小vs.|D|,图5(c)代表局部索引构建vs.SP,图5(d)代表局部索引大小vs.SP,图5(e)代表全局索引构建vs.NP,图5(f)代表全局索引大小vs.NP。
图6是本发明实验中时间旅行和时态聚集查询(SX-ST数据集)示意图。
图7是本发明实验中时间旅行和时态聚集查询(SYN数据集)示意图。其中,图7(a)是运行时间和时间旅行精确匹配查询的相关示意图;图7(b)是吞吐量和时间旅行精确匹配查询的相关示意图;图7(c)是运行时间和时间旅行范围查询的相关示意图;图7(d)是吞吐量和时间旅行范围查询的相关示意图;图7(e)是运行时间和时态聚集查询的相关示意图;图7(f)是吞吐量和时态聚集查询的相关示意图;
图8是图7在|D|为(1~100)×106时的放大图。其中|D|的范围为1×106到100×106。其中,图8(a)是图7(a)在|D|为(1~100)×106时的放大图,图8(b)是图7(c)在|D|为(1~100)×106时的放大图,图8(c)是是图7(e)在|D|为(1~100)×106时的放大图。
图9是本发明实验中分区大小SP对时态查询性能的影响示意图。图9(a)代表运行时间,图9(b)代表吞吐量。
具体实施方式
现在结合附图对本发明作进一步详细的说明。这些附图均为简化的示意图,仅以示意方式说明本发明的基本结构,因此其仅显示与本发明有关的构成。
1、问题定义
具体而言,本发明试图在分布式环境中实现对时态数据的两种代表性操作(即时间旅行和时态聚合)。但是,我们稍后描述的框架和算法可以容易地扩展到支持其他时态操作(例如,时态连接)和其他数据(例如,双时间数据[R.Bliujute,C.S.Jensen,S.Saltenis,G.Slivinskas:R-tree based indexing of now-relative bitemporal data.In VLDB,1998],双时间数据,即同时包含有效时间(Valid time)和事务时间(Transaction time)的数据记录)。接下来,我们形式化定义我们的研究问题。(为便于参考,表1列出了常用符号。)
符号 | 说明 |
D | 时态数据集 |
ti | 时态数据集的第i个记录 |
Ip | 分区间隔 |
Qe | 时间旅行精确匹配查询 |
Qr | 时间旅行范围查询 |
Qa | 时态聚集查询或时态聚合查询 |
g | 时态聚集操作算子,如SUM,MAX |
表1常用符号
设时态数据集D包含|D|个时态记录{t1,t2,…t|D|}。每个记录ti(i∈[1,|D|)是(key,value,start,end)形式的四元组。其中key为记录ti的关键字,start和end是记录ti存活的时间间隔的开始和结束时间戳,value是记录ti的值。此外,给定版本号(或时间戳)v和记录ti,我们认为记录ti存在于版本v中(即记录ti在版本v中是存活的),当且仅当v∈[ti.start,ti.end)。
时间旅行为数据库建立了持续的历史视图,是时间数据库中最重要的时态操作之一。在本文中我们解决两个广泛使用的时间旅行操作,即时间旅行精确匹配查询和时间旅行范围查询。这两个操作都支持查询数据库的过去版本。它们的主要区别在于,精确匹配查询的输入为特定值,而范围查询的输入使用给定范围[参见B.Becker,S.Gschwind,T.Ohler,B.Seeger,B.Widmayer:An asymptotically optimal multiversion B-tree.InVLDBJ,1996]。具体而言,其正式定义如下。
定义1(时间旅行精确匹配查询)。给定时间旅行精确匹配查询Qe={key,v},时间旅行精确匹配查询查找所有记录中时间间隔包含所查询的时间版本v,并且记录关键字与所查询的关键字key相等的记录。我们从D中检索时态记录(记为θ)使得:
θ={ti∈D|ti.key=key∧ti.start≤υ∧υ<ti.end}.
其中,D为时态数据集,ti为时态数据集的第i个记录,简称时态记录。ti为一个四元组(key,value,start,end),其中ti.key为记录ti的关键字,ti.value代表记录ti的值,ti.start是记录ti存活的时间间隔的开始时间戳,ti.end是记录ti存活的时间间隔的结束时间戳。key为查询输入的关键字,v为要查询的时间版本。
例如,考虑一个简单的时态数据库,其中有7个时态记录,如图1所示。当Qe={21,v1}时,查询返回t3;相反,当Qe={21,v2}时,查询返回
定义2(时间旅行范围查询)。给定时间旅行范围查询Qr={start_key,end_key,v},我们从D中检索时态记录(记为θ)使得:
θ={ti∈D|.start_key≤ti.key∧ti.key≤end_key∧ti.start≤υ∧υ<ti.end}.
其中,start_key为查询范围的起始值,end_key为查询范围的终止值,v为要查询的时间版本。
例如(同见图1),当Qr={7,22,v1}时,查询返回{t2,t3};而当Qr={7,22,v2}时,查询返回{t2,t5,t7}。
时态聚合是时态数据库中的常见操作,并且通常是具有挑战性和耗时的。自[N.Kline,R.T.Snodgrass:Computing Temporal Aggregates.In ICDE,1995]提出时间聚合后,人们对时态聚合进行了深入的研究。在本文中,我们将重点放在在特定时间戳进行聚合(例如,MAX,SUM)上。形式上,时间聚合操作定义如下。
定义3(时态聚合查询)。给定时态聚合查询Qa={g,v},其中g为聚合算子,v为要查询的时间版本,如MAX,我们从D中检索聚合值(记为θ)使得:
θ=g{ti∈D|ti.start≤υ∧υ<ti.end}.
其中,D为时态数据集,ti为时态数据集的第i个记录(简称时态记录),ti.start代表记录ti存活的时间间隔的开始时间戳,ti.end代表记录ti存活的时间间隔的结束时间戳。
考虑图1所示的时态数据库。当Qa={MAX,v1}时,查询返回21(因为max{9,21,5}=21);作为对比,当Qa={MAX,v2}时,查询返回32(因为4+9+8+11=32)。
需注意的是,与以前的工作相比,本文中我们将重点放在分布式环境中的时态大数据上。正如背景技术所讨论的那样,基于现有分布式系统的直接实现是非常低效的。下面将详细介绍本发明的解决方案。
2、解决方案
在本节中,我们首先描述分布式处理框架。然后,我们展示如何基于所提出的框架来实现时间旅行和时态聚合查询。最后,我们讨论在经典分布式计算引擎—ApacheSpark—上部署框架的实现细节。
2.1系统框架
如图2所示,在高层次上,我们的框架由三部分组成:(i)分区单元。它负责将所有数据分区到分布式节点,该分布式节点包括主节点和从节点,其中主节点负责分布式集群的资源调度和管理,从节点负责执行由主结点分配的任务;通常,我们应该保证每个节点具有大致相同的数据大小,以保持负载平衡。(ii)局部索引单元。在每个分区中,维护局部索引以避免“完整”扫描,因此可以帮助我们提高查询效率。此外,每个分区还为全局索引的构建维护一个分区间隔(该分区间隔由一个分区中所有记录中时间间隔开始值的最小值和结束值的最大值组成)。(iii)全局索引单元。在主节点中,全局索引被设计为预先修剪查询不会涉及到的分区。这可以避免检查每个分区,从而可以帮助我们降低CPU成本和/或网络传输成本。在我们的设计中,主节点收集从节点中每个分区的所有分区间隔,然后根据收集的分区间隔构建全局索引。我们框架的系统框架如图2所示。很容易理解,我们的框架采用两级索引结构,可以尽可能避免访问不相关的候选项(例如分区和局部记录)。虽然框架背后的原理很简单,但如后面所示,它是高效的。接下来,我们讨论每个单元的相关问题。
2.2分区方法
在分区一般数据时,负载平衡通常是一个理想的目标。而对于时态数据,另一个期望的目标是最小化分区间隔的重叠。为了实现这些目标,在我们的设计中,我们按时间间隔分割时间数据(称为范围分区)。例如,假设我们想将图3(a)中所示的六个时态记录分成两个分区P1和P2。我们可以首先按时间间隔对这些时态记录进行排序,获得排序记录(t3,t2,t6,t4,t5,t1)。为了平衡每个分区的大小,我们可以将排序后的记录平均分成两部分。因此,P1包含前三个记录(t3,t2,t6),相应地P2包含(t4,t5,t1)。这样,P1的分区间隔是[v1,v3),而P2的分区间隔为[v2,v4)。特别地,P1和P2的区间重叠是v3-v2,这是最小的间隔重叠。
需注意的是,尽管哈希分区法被广泛用于其他数据类型,例如流式数据(因为数据可以通过这种方式均匀分配),但它可能不适合我们所关注的上下文。主要原因是以这种方式分区可能会导致很多重叠(分区间隔)。例如,考虑图3(b)所示的时态数据。哈希分区后,P′1包含(t3,t4,t6),P′2包含(t1,t2,t5)。可以很容易地看出P′11和P′2的分区间隔重叠是v′3-v′2,这比P1和P2的大得多。
2.3局部索引方法
如前所述,局部索引用于管理每个分区中的时态数据。在文献中,已经有了现成的索引结构来支持时间旅行查询,如多版本B树[B.Becker,S.Gschwind,T.Ohler,B.Seeger,B.Widmayer:An asymptotically optimal multiversion B-tree.In VLDBJ,1996]和时间索引[R.Elmasri,G.T.Wuu,and Y.J.Kim.The Time Index:An Access Structure forTemporal Data.In VLDB,1990]。在本发明中,我们使用多版本B树(缩写为MVB-Tree)作为示例。多版本B树(MVB-Tree)索引结构在每次对数据库进行更新(插入或删除)时生成一个新版本,从而一致性得记录数据库的更新记录,因此能查询数据库的历史版本。为了便于理解,图4(a)示出了该索引结构。根的第一个记录指向其孩子A,它包含从版本1到9(不包含)中的所有活动记录。在叶节点中,每个记录代表一条时态记录,其中*表示这个记录现在还活着。
同样,亦存在索引结构(例如[J.Yang,J.Widom:Incremental computation andmaintenance of temporal aggregates.In ICDE,2001;S.Ramaswamy:Efficientindexing for constraint and temporal databases.In ICDT,1997])以支持时态聚合查询。这里我们使用[J.Yang,J.Widom:Incremental computation and maintenance oftemporal aggregates.In ICDE,2001]中提出的索引(名为SB-Tree)作为例子。SB-Tree索引结构是一种支持时态数据聚集查询的索引结构,通过在索引内预计算聚集值,避免在查询时遍历所有数据记录,提高查询速度。SB-Tree节点由两个数组组成,如图4(b)所示。其中一个数组存储时间间隔,指向子节点,另一个存储聚合值。使用SB-Tree计算聚合时,可以从树根到树叶对树进行搜索,然后聚合其路径中的值。
请注意,虽然本文采用了MVB-Tree和SB-Tree,但并不强制使用这些索引。换句话说,其他已存在的时态索引或未来设计的更强大的索引也可用于我们的框架。
2.4全局索引方法
如前所述,全局索引管理分区间隔。由于每个分区间隔可以通过起始值和间隔长度进行比较,所以我们自然可以使用二叉搜索树来维护分区的间隔信息。请注意,对于从节点中的每个分区,有很多时间间隔(记录)。尽管如此,我们只对分区使用一个分区间隔。为了理解分区间隔,考虑一个简单的例子,分区中有三个时间间隔{[u1,u2),[u3,u4),[u5,u6)}。那么,分区间隔即为[min{u1,u3,u5},max{u2,u4,u6})。这样,全局索引中的每个分区间隔对应于从节点中的分区。这意味着,在查询处理中,如果一个分区间隔可以被修剪,则可以安全地修剪相应的分区。基于这种方法,在我们的设计中,全局索引中的每个节点都维护一个键值对<Ip,id>,其中Ip和id分别指分区间隔及其相应的分区。
3、在Apache Spark中的实现
在Apache Spark中,弹性分布式数据集(RDD)具有容错能力,可以存储在内存中以支持快速的数据重用而无需访问磁盘。在本节中,我们详细阐述如何在Apache Spark中实现我们的框架。
为了支持2.2节中提出的分区方法,我们扩展了Spark的RangePartitioner。请注意,Spark的RangePartitioner是为通用数据分区开发的;它不能有效地支持按区间划分。为了实现这个功能,我们实现了区间数据格式的比较函数,并将其集成到SparkRangePartitioner中。
对于Spark中全局索引的实现,我们首先收集分配于从结点中的所有分区间隔,然后在主节点上构建一个二叉搜索树作为全局索引。Spark中的局部索引的实现与上述过程不同。我们知道RDD是Spark中的基本抽象,它代表了被分区的可以并行操作的元素集合。同时,分区中的数据集记录是根据分区算法被包装入分区的。特别是,我们观察到RDD是为顺序访问而设计的。这使得我们不能直接在RDD上建立索引。要通过RRD部署本地索引,我们使用[D.Xie,F.Li,B.Yao,G.Li,L.Zhou,M.Guo:Simba:Efficient in-memory spatialanalytics.In SIGMOD,2016]中提出的方法。简而言之,我们首先将所有时间记录(在分区中)加载到内存中,然后构造局部索引结构;之后,释放用于存储原始时间数据的内存,并将局部索引保留在内存中以支持后续查询。
另外,最好可以让用户编写简洁的SQL语句来支持时态大数据的分析。但是,在Apache Spark中没有相应的SQL命令。为此,我们开发新的Spark SQL操作/命令来支持时态数据的分析。几个主要变化如下。
●我们设计了一个新的关键字“VERSION”以支持SQL语句的时态操作。通过修改Spark SQL引擎中的SQL计划并赋予其新的含义,该关键字可以帮助我们重新解释从SQLServer继承的AS OF子句。特别的,FOR VERSION AS OF version_number指定一个版本号,其中VERSION为新引入的关键字。例如,用户可以使用以下SQL语句来执行上述提到的时间旅行精确匹配查询。
●为了管理时态数据索引,我们还开发了相应的SQL语句对时态索引进行管理。用户可以使用USE index_type指定索引结构,其中index_type是特定索引的关键字(例如,MVBTREE,SBTREE)。例如,要为表D创建名为”sbt”的SB-Tree索引,可以使用以下SQL命令:
4、实验
4.1实验设置
在实验中,我们使用如下所述的真实和合成数据集。真实数据集SX-ST是从网站Stack Overflow[J.Leskovec and A.Krevl:SNAP Datasets:Stanford Large NetworkDataset Collection.http://snap.stanford.edu/data,2014]中的时态网络中提取的。网络中共有260万个节点,代表用户,共有6300万条边,每条边以(u,v,t)形式表示。其中u和v分别是源和目标用户的ID,t为这两个用户的交互时间。具体而言,我们提取多于一次与其他人进行互动的用户。我们将这些用户中的每一个用户作为记录,其中用户的两个连续交互时间戳被视为记录的间隔,并且记录的值是与用户相关的交互的总数。我们提取了约40万条记录。遵循SX-ST的模式,我们还生成了合成数据集,缩写为SYN。具体而言,在SYN中,记录的起始时间戳随机生成,并且间隔的长度在SX-ST中的最小和最大长度之间均匀分布。SYN的大小范围从100万到40亿(即[106,4×109])条记录,占用从32MB到166GB磁盘空间。默认设置是5×108条记录。
为了衡量我们系统的性能,我们采用了两个广泛使用的评估指标:(i)运行时间(即查询延迟)和(ii)吞吐量。为了获得运行时间,我们为每个测试用例重复执行10次查询,并计算平均值。另一方面,吞吐量评估为每分钟执行的查询次数。此外,我们还对系统中使用的索引进行了性能实验。
我们将我们的系统与两个基准系统进行比较:(i)基于Spark的Naive内存解决方案(NISS)。它使用Spark中的默认方法随机分配所有时态记录,并将数据存储在分布式系统的内存中。这些分区是通过RDD收集和管理的,这允许我们并行处理数据。为了实现时态查询,NISS使用Spark SQL提供的谓词(例如WHERE谓词)对数据进行扫描。根据查询输入中显示的条件检查每条记录,获取查询结果。例如,当进行具有MAX运算符的聚合查询时,NISS将并行检查每个分区。对于每个分区,它扫描整个分区并确定版本v中所有活动记录的最大值。最后,它从分区收集所有“局部”最大值并找到全局的最大值。和(ii)一个从OceanRT扩展[S.Zhang,Y.Yang,W.Fan,L.Lan,M.Yuan:OceanRT:real-time analytics over largetemporal data.In SIGMOD,2014]的名为OcRT的分布式磁盘解决方案。请注意,OceanRT根据记录的时态属性对时间数据块进行散列;这个行为实质上是一个全局索引。在我们的基准系统中,我们通过将间隔的起始值分组以形成分区来实现这个散列过程。另外,OceanRT在一个物理节点上运行多个计算单元,并使用远程直接内存访问(RDMA)连接这些单元;这种行为与Apache Spark中的Executor大致相同。更重要的是,我们改进后的解决方案OcRT将数据存储在磁盘上,这与OceanRT中的行为相同。
所有实验均在包含5个结点的集群上进行,采用双10核Intel Xeon E5-2630v4处理器(2.20GHz)和256GB DDR4RAM。所有这些结点都通过千兆以太网交换机连接,运行部署Hadoop 2.6.5和Spark 1.6.3的Linux操作系统(Kernel 4.4.0-97)。我们选择5个结点中的一个作为主结点,其余4个结点作为从结点。该配置共有960GB内存和144个虚拟内核。我们的集群部署在Spark Standalone下。在我们的实验中,HDFS块的默认大小为128MB。默认分区大小(a.k.a.,每个分区的大小)包含105个记录。局部索引的扇出值设置为100。
4.2实验结果
图5显示了我们系统的索引成本。对于局部索引,SB-Tree(SBT)的构建时间比MVB-Tree(MVBT)快得多,如图5(a)所示。这主要是因为MVBT需要进行节点复制并且有比SB-Tree大约2倍的操作(例如,插入和删除)。即便如此,索引时间也是可以接受的。例如,使用MVBT索引40亿条记录只需要1.54小时。正如预期的那样,图5(b)显示索引存储开销随着数据集的大小而增加。此外,我们还通过改变分区大小(SP)进行对比实验;参见图5(c)和图5(d)。可以看出,SP与索引建立时间之间存在非线性关系(参见图5(c))。这主要是因为索引建立时间不仅受每个分区大小的影响,还受分区数量的影响。在我们的实验中,“好”的分区大小在20K到200K的范围内,因此我们选择SP=100K作为默认分区大小(参见4.1节)。注意,适当选择分区数量和大小既可以提高系统吞吐量,又可以降低查询时延。同时我们可以看到SP对索引大小的影响较小(参见图5(d)),这进一步表明索引大小主要与数据集大小|D|有关;另一方面,可以看到,全局索引的构造非常快;即使NP设置为最大值,构建时间也只需330毫秒(参见图5(e))。这主要是因为全局索引规模较小,例如即使在NP=40K时也只有3MB左右(参见图5(f))。此外,正如我们预期的那样,全局索引的大小与NP成严格的线性关系。
接下来,我们将我们的方法与基准系统进行比较。我们首先讨论SX-ST数据集上的结果。从图6可以看出,尽管NISS也将数据存储在内存中,其执行速度却很慢。这主要是因为对分区中的数据集进行全面扫描非常耗时。至于OcRT,尽管散列过程可以执行分区修剪,但由于缺少本地索引,因此也需要对分区进行全面扫描,因此速度缓慢。OcRT比NISS慢的原因可能有两点:(i)OcRT是基于磁盘的解决方案;和(ii)当使用像SX-ST这样的相对较小的数据集时,OcRT的分区修剪效果很弱。与基准系统相比,我们的方法对于时间聚合查询仅需要约0.3秒,对于时间旅行而言只需不到0.2秒。它大约比NISS快3倍,比OcRT快约4倍。这证明了我们方法的竞争力。另一方面,可以看到不同聚合查询(例如SUM,MAX)有相似的查询时间。在下文中讨论聚合查询时,为节省篇幅,我们主要使用SUM聚合查询的结果。
图7涵盖了比SX-ST数据集大得多的合成(SYN)数据集的比较结果。对于时间旅行精确匹配查询,从图7(a)可以很容易地看出,我们的解决方案比OcRT快3-7倍。当数据集大小|D|范围从106到4×109个记录时,我们的解决方案在运行时间和吞吐量(参见图7(a)和7(b))上的性能优于NISS;特别是,当|D|=4×109时,它比NISS快接近两个数量级。这证明了我们解决方案的优越性。另外,我们可以看到,我们所提出的系统的性能比其他系统的性能下降得慢,这向我们展示了我们的系统具有更好的可扩展性。这主要是因为我们框架中的全局分区修剪在更大的数据集上作用更加明显。另一个有趣的现象是,这里的OcRT明显好于NISS(参见图7(a),7(c)和7(e)),而在先前的测试中其比NISS慢(参见图6)。这主要是因为与SYN相比,SX-ST数据集相对较小。图8很好地解释了这种现象(参见两条线的交点)。
当我们执行时间旅行范围查询时(参见图7(c)和图7(d)),我们的解决方案与精确匹配查询相比呈现出类似的性能。例如,两个查询的运行时间接近并具有相似的增长趋势。另一方面,对于时间聚合查询,从图7(e)可以看出,其运行时间比时间旅行操作的时间稍长。这主要是因为它需要检查更多的记录。类似地,在图7(f)中,聚合查询的吞吐量具有相似的特征。
图9显示了分区大小SP(变量)对时态查询性能的影响。从图9(a)可以看出,时间旅行和时态聚合查询的良好分区大小在20K到100K之间。同时,从图9(b)可以看出,吞吐量对分区大小更为敏感。这显示了分布式系统中分区数量的重要性。
以上述依据本发明的理想实施例为启示,通过上述的说明内容,相关工作人员完全可以在不偏离本项发明技术思想的范围内,进行多样的变更以及修改。本项发明的技术性范围并不局限于说明书上的内容,必须要根据权利要求范围来确定其技术性范围。
Claims (8)
1.一种基于时间旅行和时态聚合查询的分布式处理框架系统,其特征在于,包括分区单元、局部索引单元和全局索引单元;所述分区单元负责将所有数据分区到分布式节点;所述局部索引单元用于管理每个分区中的时态数据;所述全局索引单元用于管理分区间隔。
2.如权利要求1所述的系统,其特征在于,所述分区单元负责将所有数据分区到分布式节点,该分布式节点包括主节点和从节点,其中主节点负责分布式集群的资源调度和管理,从节点负责执行由主结点分配的任务;保证每个节点具有大致相同的数据大小,以保持负载平衡。
3.如权利要求1或2所述的系统,其特征在于,所述局部索引单元,在每个分区中,维护局部索引以避免完整扫描;每个分区为全局索引的构建维护一个分区间隔,该分区间隔由一个分区中所有记录中时间间隔开始值的最小值和结束值的最大值组成。
4.如权利要求3所述的系统,其特征在于,所述全局索引单元中,主节点收集从节点中每个分区的所有分区间隔,然后根据收集的分区间隔构建全局索引。
5.如权利要求1所述的系统,其特征在于,所述分区单元采用如下分区方法:按时间间隔分割时间数据,包括如下步骤:
首先按时间间隔对时态记录进行排序,获得排序记录;将排序后的记录平均分成几个部分,即完成分区。
6.如权利要求1所述的系统,其特征在于,所述局部索引单元,采用多版本B树MVB-Tree索引结构来支持时间旅行查询,采用SB-Tree索引结构来支持时态聚合查询;所述多版本B树MVB-Tree索引结构在每次对数据库进行更新(插入或删除)时生成一个新版本,从而一致性得记录数据库的更新记录,因此能查询数据库的历史版本;所述SB-Tree索引结构是一种支持时态数据聚集查询的索引结构,通过在索引内预计算聚集值,避免在查询时遍历所有数据记录,提高查询速度。
7.如权利要求1所述的系统,其特征在于,所述全局索引单元,在主节点中,全局索引被设计为预先修剪查询不会涉及到的分区,以避免检查每个分区。
8.如权利要求1所述的系统,其特征在于,所述每个分区间隔能通过起始值和间隔长度进行比较,使用二叉搜索树来维护分区的间隔信息;只对分区使用一个分区间隔;全局索引中的每个分区间隔对应于从节点中的分区,在查询处理中,如果一个分区间隔可以被修剪,则可以安全地修剪相应的分区;全局索引中的每个节点都维护一个键值对<Ip,id>,其中Ip和id分别指分区间隔及其相应的分区。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810494066.9A CN108804556B (zh) | 2018-05-22 | 2018-05-22 | 基于时间旅行和时态聚合查询的分布式处理框架系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810494066.9A CN108804556B (zh) | 2018-05-22 | 2018-05-22 | 基于时间旅行和时态聚合查询的分布式处理框架系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108804556A true CN108804556A (zh) | 2018-11-13 |
CN108804556B CN108804556B (zh) | 2020-10-20 |
Family
ID=64091322
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810494066.9A Active CN108804556B (zh) | 2018-05-22 | 2018-05-22 | 基于时间旅行和时态聚合查询的分布式处理框架系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108804556B (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110059149A (zh) * | 2019-04-24 | 2019-07-26 | 上海交通大学 | 电子地图空间关键字查询分布式索引系统和方法 |
CN110825733A (zh) * | 2019-10-08 | 2020-02-21 | 华中科技大学 | 一种面向多采样流的时间序列数据管理方法及系统 |
CN114661957A (zh) * | 2020-12-22 | 2022-06-24 | 南京航空航天大学 | 一种基于Spark GraphX的时态RDF查询方法 |
WO2023273727A1 (zh) * | 2021-07-02 | 2023-01-05 | 华为云计算技术有限公司 | 数据处理方法、装置、存储介质及程序产品 |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103412897A (zh) * | 2013-07-25 | 2013-11-27 | 中国科学院软件研究所 | 一种基于分布式结构的并行数据处理方法 |
CN103425723A (zh) * | 2012-04-30 | 2013-12-04 | Sap股份公司 | 删除多级存储架构中的记录而不进行记录锁定 |
CN103617162A (zh) * | 2013-10-14 | 2014-03-05 | 南京邮电大学 | 一种对等云平台上构建希尔伯特r树索引的方法 |
CN105117497A (zh) * | 2015-09-28 | 2015-12-02 | 上海海洋大学 | 基于Spark云网络的海洋大数据主从索引系统及方法 |
US20150356427A1 (en) * | 2014-06-09 | 2015-12-10 | Cognitive Scale, Inc. | Method for Performing Graph Query Operations within a Cognitive Environment |
US20160042039A1 (en) * | 2014-08-06 | 2016-02-11 | Martin Kaufmann | Timeline index for partitioned temporal database tables |
CN106202114A (zh) * | 2015-05-07 | 2016-12-07 | 骑记(厦门)科技有限公司 | 路径导航方法和装置 |
CN106897374A (zh) * | 2017-01-19 | 2017-06-27 | 浙江大学 | 一种基于轨迹大数据最近邻查询的个性化推荐方法 |
CN107430613A (zh) * | 2015-03-23 | 2017-12-01 | 甲骨文国际公司 | 知识密集型数据处理系统 |
-
2018
- 2018-05-22 CN CN201810494066.9A patent/CN108804556B/zh active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103425723A (zh) * | 2012-04-30 | 2013-12-04 | Sap股份公司 | 删除多级存储架构中的记录而不进行记录锁定 |
CN103412897A (zh) * | 2013-07-25 | 2013-11-27 | 中国科学院软件研究所 | 一种基于分布式结构的并行数据处理方法 |
CN103617162A (zh) * | 2013-10-14 | 2014-03-05 | 南京邮电大学 | 一种对等云平台上构建希尔伯特r树索引的方法 |
US20150356427A1 (en) * | 2014-06-09 | 2015-12-10 | Cognitive Scale, Inc. | Method for Performing Graph Query Operations within a Cognitive Environment |
US20160042039A1 (en) * | 2014-08-06 | 2016-02-11 | Martin Kaufmann | Timeline index for partitioned temporal database tables |
CN107430613A (zh) * | 2015-03-23 | 2017-12-01 | 甲骨文国际公司 | 知识密集型数据处理系统 |
CN106202114A (zh) * | 2015-05-07 | 2016-12-07 | 骑记(厦门)科技有限公司 | 路径导航方法和装置 |
CN105117497A (zh) * | 2015-09-28 | 2015-12-02 | 上海海洋大学 | 基于Spark云网络的海洋大数据主从索引系统及方法 |
CN106897374A (zh) * | 2017-01-19 | 2017-06-27 | 浙江大学 | 一种基于轨迹大数据最近邻查询的个性化推荐方法 |
Non-Patent Citations (1)
Title |
---|
刘义等: "基于R-树索引的Map-Reduce空间连接聚集操作", 《国防科技大学学报》 * |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110059149A (zh) * | 2019-04-24 | 2019-07-26 | 上海交通大学 | 电子地图空间关键字查询分布式索引系统和方法 |
WO2020215438A1 (zh) * | 2019-04-24 | 2020-10-29 | 上海交通大学 | 电子地图空间关键字查询分布式索引系统和方法 |
CN110825733A (zh) * | 2019-10-08 | 2020-02-21 | 华中科技大学 | 一种面向多采样流的时间序列数据管理方法及系统 |
CN114661957A (zh) * | 2020-12-22 | 2022-06-24 | 南京航空航天大学 | 一种基于Spark GraphX的时态RDF查询方法 |
WO2023273727A1 (zh) * | 2021-07-02 | 2023-01-05 | 华为云计算技术有限公司 | 数据处理方法、装置、存储介质及程序产品 |
Also Published As
Publication number | Publication date |
---|---|
CN108804556B (zh) | 2020-10-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Yang et al. | Qd-tree: Learning data layouts for big data analytics | |
Tao et al. | Minimal mapreduce algorithms | |
Kim et al. | Parallel top-k similarity join algorithms using MapReduce | |
Herschel et al. | Scalable iterative graph duplicate detection | |
CN108804556A (zh) | 基于时间旅行和时态聚合查询的分布式处理框架系统 | |
Davoudian et al. | A workload-adaptive streaming partitioner for distributed graph stores | |
Ahmed et al. | Data processing in Hive vs. SQL server: A comparative analysis in the query performance | |
Tinnefeld et al. | Elastic online analytical processing on ramcloud | |
Peixoto et al. | Scalable and fast top-k most similar trajectories search using mapreduce in-memory | |
Reif et al. | A scalable and generic approach to range joins | |
Mesmoudi et al. | Benchmarking SQL on MapReduce systems using large astronomy databases | |
CN108664662A (zh) | 时间旅行和时态聚合查询处理方法 | |
Güting et al. | Distributed arrays: an algebra for generic distributed query processing | |
Wang et al. | Sparkarray: An array-based scientific data management system built on apache spark | |
Ge et al. | LSShare: an efficient multiple query optimization system in the cloud | |
Pavlovic et al. | Transformers: Robust spatial joins on non-uniform data distributions | |
Yao et al. | Distributed in-memory analytics for big temporal data | |
Samoladas et al. | Tree Data Structures and Efficient Indexing Techniques for Big Data Management: A Comprehensive Study | |
Chen et al. | ITISS: an efficient framework for querying big temporal data | |
Ahmed et al. | Triangle enumeration for billion-scale graphs in rdbms | |
Mohamed et al. | Hash semi join map reduce to join billion records in a reasonable time | |
Bhattu et al. | Generalized communication cost efficient multi-way spatial join: revisiting the curse of the last reducer | |
Heinis et al. | Challenges and opportunities in self-managing scientific databases | |
Bhatnagar et al. | DASC: data aware algorithm for scalable clustering | |
Balakayeva et al. | Modeling the processing of a large amount of data |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |