在火花SQL查询执行优化

文摘

火花SQL是一个大数据处理结构化数据的查询和分析的工具。然而,由于火花的执行SQL,有多次中间数据写入磁盘,减少火花SQL的执行效率。针对现有的问题,我们设计和实现之间的一个中间数据缓存层底层文件系统和上层火花核心减少随机磁盘I / O的成本。通过使用查询系统论模块,我们可以动态调整的能力不同的查询缓存层。和分配模块可以为集群中每个节点分配适当的内存。根据火花的中间数据的共享SQL工作流程,提出了一种基于成本的相关合并算法,可有效减少冗余数据读写的成本。本文发展了SSO(火花SQL优化器)模块和集成到原始引发系统来实现上述功能。本文比较了与现有火花SQL查询性能通过实验数据生成的tpc - h的工具。实验结果表明,SSO模块可以有效地提高查询效率,减少磁盘I / O成本和充分利用集群内存资源。

1。介绍

的日益普及电子商务、社交网络、人工智能和其他新的互联网应用程序,存储和处理的数据量由政府、企业和研究机构已经急剧增加。变电站在电力系统生成每分钟100000报警数据,和Facebook每天产生超过400 TB的日志。这是一个紧急的问题,为企业和研究机构如此大规模数据存储在硬盘持续和检索所需的信息由用户在很短的时间内。数据存储和处理系统在大数据环境下近年来受到越来越多的关注。

早期的大数据处理系统主要是围绕Hadoop平台。为了解决这个问题,Hadoop平台经常读和写在HDFS中间数据,方法在内存中缓存Hadoop的洗牌数据提出了史等。1]虽然这个方法可以有效地减少大量的随机磁盘I / O成本造成的阅读和写作中间数据,这是呆板的缓存大小由这种方法固定在不同的应用程序。一定数量的内存会浪费一些少量的洗牌的应用程序数据。解决问题的Hadoop平台,基于内存的分布式计算框架Apache火花出现。

火花是一种高速的大数据处理引擎。它是基于抽样的实现(2)(弹性分布式数据集),并实现了数据分布和容错。如图1,当前引发生态系统包含三层:底层、中层和顶层。从HDFS底层可以读取输入数据3],Amazon S3, HyperTable HBase [4]。中间层使用资源调度管理平台独立、纱(5和便6)完成应用程序的分析和处理。顶层由一系列先进的工具,包括火花流(7],GraphX [8],BlinkDB [9],MLlib [10)和火花SQL (11]。火花SQL开发从鲨鱼12),它提供的功能像蜂巢13),允许用户直接通过输入SQL语句处理结构化数据。催化剂生成和优化火花SQL执行计划将用户提交的SQL查询语句的执行代数优化和生成火花工作流,报执行。

然而,火花的SQL系统目前面临两个问题。一个问题是,经常阅读和写作的中间数据之间的数据交互过程引发的任务导致严重的随机磁盘I / O的成本。中间文件的数量由一个简单的程序在火花图所示2。

另一个问题是,没有合适的优化规则的工作流。火花工作中间数据相关性需要反复从磁盘读取相同的输入数据,导致冗余磁盘I / O的成本。

在上述背景下,本文旨在改善火花SQL的执行效率。主要贡献如下。(1)降低随机磁盘I / O成本在洗牌阶段通过添加火花核心层之间的一个中间数据缓存层和底层的分布式文件系统。(2)减少相同的中间数据的读/写成本之间的火花工作通过使用一个基于成本的相关合并算法,进一步提高数据分析系统的性能。

2。系统架构

SSO(火花SQL优化器)原型系统的设计和发展。其系统结构如图3。

现有的火花在主从式系统运行。司机流程在主节点收到查询请求从客户端提交。工作进程在奴隶节点上执行特定的查询任务。SSO系统优化,改进了原来的火花,动态调整优化器模块添加名为动态调整优化器在主节点。火花的原始框架也修改为包括催化剂成本模型模块更名为SQL工作流优化器。阅读和写作对分布式内存文件系统接口的奴隶节点被添加到洗牌地图任务,慢慢减少。优化用户查询的过程通过SSO系统描述如下。

用户提交的查询是由解析器解析SQL工作流优化器模块组成一个逻辑执行计划。然后,优化执行计划提交给动态调整优化和DAG调度程序。动态调整优化计算的大小产生的中间数据优化SQL查询使用查询系统论模块。然后分配模块在缓存层分布式内存文件系统上执行缓冲区分配。最后,生成的工作流执行计划将提交任务分配DAG调度程序的奴隶节点。

3所示。火花洗牌中间数据缓存层

在现有的火花系统中,数据之间的交互阶段会经常产生磁盘I / O开销。因此,缓存直接数据提出的策略。动态调整优化器是用于创建缓冲区大小不同的分布式内存文件系统动态SQL工作流不同的火花。随机磁盘I / O的成本将减少缓存洗牌洗牌阶段中间数据在内存中。

3.1。查询系统论模块

下面的查询执行过程分析显示当火花SQL将中间数据写入磁盘。查询语句是:选择l_partkey、l_quantity l_extendedprice从lineitem,部分在哪里p_partkey = l_partkey和l_quantity < 40

分析表明,查询只包含一个连接操作。SQL查询的执行过程下火花图所示4。

上述执行引发的过程分为三个阶段。阶段0读取一部分表和属性p_partkey上投影操作运行。阶段1读取lineitem表并执行投影操作的三个属性l_partkey, l_quantity l_extendedprice以及选择操作l_quantity < 40岁。第二阶段读0和1阶段的中间结果,执行连接操作p_partkey = l_partkey最后将查询结果写入磁盘。

这个查询的分析表明,该查询执行工作流的火花可以分为两个阶段。一是S-Stage投影、选择和聚合操作,另一种是J-Stage连接操作。

S-Stage,下面的规则可以用来计算输出数据在这个阶段的大小。(1)投影 l_箴代表的投影长度属性,l_D代表所有属性的总长度。(2)选择 的价值β_费尔有关具体的选择条件和原始表的数据分布。(3)聚合 聚合操作返回的总和或平均价值属性,所以输出尺寸是可以忽略不计。

例如,图5这个SQL查询的运行状态图在火花。输入数据大小阅读阶段0 = 233.2 MB, Lpartkey = 10,l_D= 194。通过上面的分析,可以计算|这个阶段的输出D_出| =β_箴|D_在| = 10/194≈233∗13 MB。它接近实际的输出阶段0 10 MB。同样,输入数据大小阅读阶段1是7.3 GB, Lpartkey = 10, Lquantity = Lextendedprice = 15,l_D= 231。抽样显示,元组与l_quantity > 40元组约占总数的60%。所以这个阶段的输出是|D_出| =β_箴∗β_费尔|D_在| = (10 + 15 + 15)/ 231∗∗7.3 GB 0.6≈776 MB,这接近824 MB的实际输出生成的第一阶段。

3.2。连接操作的成本分析

J-Stage,下面的规则用于计算这个阶段的输出数据大小。

如果没有联接条件C,它变成了笛卡儿积γ= 1。如果没有元组满足联接条件C,γ= 0。通常0≤γ≤1。如果联接条件D₁·一个=D₂·B,有三个特殊的情况。(1)如果一个的主键吗D₁每个元组,D₂匹配一个元组D₁,这是|D_出(加入)|≤|D_在2 |。所以,γ≤1 / |D_在1 |。如果B的主键吗D₂,γ≤1 / |D_在2 |。(2)如果一个不是主键的D₁和B不是主键的D₂和属性一个和B服从均匀分布在相同的领域米,然后γ= 1 / |米|。(3)如果一个不是主键的D₁和B不是主键的D₂和属性一个和B不服从均匀分布,γ需要根据特定的采样数据集,表结构和数据的大小。至于连接操作的成本分析方法在非均匀分布,直方图方法中提到的想法(14)是指开发一种方法适用于火花SQL。假设R是一个关系,C是一个属性的R和的值范围C(min,…,最大),最小和最大的最小和最大价值C的关系R分别。(min,…, max)划分为若干个区间,称为直接或桶。元组的数量C在这些间隔计算属性值。为了分析连接操作的成本通过直方图方法,第一步是构造不同宽度的分布直方图。算法的流程算法所示1。算法的输入频率分布直方图,记录每一个属性的值及其发生时间。从小型到大型的属性值排序。输出是不同宽度的直方图分布直方图由桶。每个直方图桶记录的起始和结束值属性,在范围和频率属性的总和。有桶之间没有交集。算法,声明一个变量最大记录当前的最大频率直方图桶。以下为每个属性和频率对,如果频率值和最大值之间的差异只占5%或更少的频率值,可以认为该属性服从同一分布每个属性在当前直方图桶。因此,这个属性也包含在当前的直方图桶。如果上述条件不满足,创建一个新的直方图桶的起始值是当前属性值和最大的频率值对应的属性值。 Continue the above steps until all attributes and frequency pairs have been traversed.

构建不同宽度的分布直方图后,加入后的算法来计算总元组数算法所示2。

算法的输入是关系的不同宽度的分布直方图R和的关系年代。输出元组的总数后,两人关系的连接操作。算法寻求重叠两个从第一个直方图直方图桶桶之间的关系R和的关系年代直方图。直方图桶是均匀分布,templeft tempright可以重叠的大小除以直方图桶的宽度,然后把结果乘以的总频率直方图桶。Templeft和tempright代表等价属性的频率直方图桶的关系R和的关系年代分别。templeft乘以tempright除以重叠的大小,然后总元组数生成的连接操作的直方图桶与重叠。如果没有重叠两个直方图桶和桶的范围h_我r小于桶的范围h_j年代桶的范围h_{我+ 1}r和水桶h_j年代需要比较。继续上面的步骤,直到所有的直方图桶的关系R或关系年代遍历。

3.3。缓存层分配模块

计算的总大小的缓存层后,接下来的问题是有多少内存分配给集群中的每个节点。由于火花数据局部性原理,当读取HDFS文件时,火花将分配数据存储最近的遗嘱执行人。对于存储多个输入数据的节点,应该分配更多的内存。输入数据在HDFS组织块,和一块的默认大小是128 MB。所以,在解析用户的查询语句来获取所需的表,有必要分析集群中的每个块的分布表。因为在HDFS中每个块的大小是一样的,内存大小米_我分配给每个节点可以通过计算每个节点的批号的比率B_我总块B_总。

Q1查询之前提到过,Lineitem表的大小是7.2 GB包括60块。表的大小是233 MB包括两个街区。这些块的分布在集群如图6。

在获得输入数据的分布在集群中,根据计算出的总大小的缓存层查询缓存层中的系统论模块和公式分配模块,每个节点所需的内存大小是790∗2/62≈25.48 MB, 790∗21/62≈267.58 MB, 790∗3/62≈38.22 MB, 790∗20/62≈254.83 MB, 790∗4/62≈50.96 MB, 790∗5/62≈63.71 MB。结果近似实际洗牌表中的数据1。

由于火花是一个基于内存计算框架,操作弹性分布式数据集洗牌之前或之后都是在内存中进行操作。集群是否有足够的内存,即使一定大小的内存空间分配了中间数据缓存层,剩余的内存足够的火花任务来执行计算。如果集群的内存资源有限,系统论的查询模块将计算洗牌的缓存大小之前查询运行时,通过缓存层和分配内存分配模块。这将导致占用内存洗牌操作之前执行。显然这不是一个合理的方法。缓存层分配模块采用延迟分配方案来解决这个问题。星火计划将尽可能多的内存分配给火花在non-Shuffle阶段工作。在洗牌阶段,火花工作不需要计算内存资源。然后在火花工作内存资源的一部分,剩下的内存资源集群中被称为中间数据缓存层。

4所示。基于成本的相关合并算法

SQL查询的优化过程的催化剂框架在传统的火花系统如图7。首先,用户输入的查询语句解析SQL解析器来形成一个逻辑执行计划树。然后用代数方法规划树优化SQL优化器在某种程度上。在当前的火花SQL工作流,反复阅读和写作的中间数据相同。有多个任务逻辑执行计划树的节点输出相同的中间数据,导致额外的磁盘I / O的成本。因此,优化规则可以被添加到原始SQL优化器合并相同的中间数据。虽然合并将减少写作输出数据在磁盘上的成本,后续任务将他们不需要读取中间数据也带来了额外的磁盘读成本。因此,它需要成本核算是否合并任务中间数据相关性。介绍了成本模型模块框架基于最初的催化剂。合并任务和中间数据相关时,SQL优化器将决定是否执行优化成本核算的统治。 The optimized Catalyst framework is named as SQL workflow optimizer and its framework is shown in Figure7。

4.1。成本模型

执行火星任务的成本模型应该建立以合并火花任务中间数据相关性。然后合并的收益和额外的成本应该基于模型计算决定是否合并相比之下。

建立任务执行成本模型的火花,我们Singhal和辛格提出的改进方法15)并添加排序操作所产生的成本。在计算阶段成本、读取输入数据、合并和排序中间数据,和写作输出数据被认为是

因为两个C_读(阶段),C_写(阶段)我/O成本,成本计算公式C_我/O=C₀T +C₁x。每个参数的定义如表所示2。

阶段阅读阶段的成本C_读(阶段)可以计算

|D_在|的大小是由源输入数据或其他阶段的输出数据。的价值α是0.3。它是由默认three-copy HDFS的存储策略,一个当地,一个在同一架和一个远程机架上。的数量我/O发生取决于特定的阶段。S-Stage,如果源读取输入数据,T= 1作为源数据存储。如果其他阶段的输出是阅读,的价值T是由生成的文件数量的中间数据在之前的阶段。火花写中间数据缓冲区的第一个任务,然后覆盖磁盘缓冲区满时形成一个文件。假设前一个阶段产生的数据大小|D_出|,|D_出| / B将生成中间文件,B是火花任务缓冲区的大小。的数量我/O发生T= |D_出| /B。J-Stage,这个阶段必须的输入输出的其他两个阶段将两个表的连接操作。假设前两阶段生产|D_出|大小输出数据,如果使用双向归并排序加入算法,⌈日志2 (|D_出| /B)⌉需要扫描的时候,和数量我/O发生|D_出| /B⌈日志2 (|D_出| /B)⌉。总之,成本的计算公式如下的阅读阶段阶段。

阶段的写作阶段的成本C_写(阶段),因为中间数据覆盖到本地磁盘,这个过程不涉及网络传输成本。计算公式是 在|D_出|可以由第二章中描述的方法计算。的数量我/O发生T是由中间文件的数量。|中间文件的数量计算D_出| /B。然后写的计算公式是由成本阶段

每个任务阶段需要排序和合并所有产生的中间数据文件本身。如果一个|D_出| /B生成中间文件,可以认为每个任务生成|D_出| /B_米中间文件,米在每个阶段任务的数量。所以,排序阶段的成本C_排序(阶段)计算

假设的数量排序P= |D_出| /B_米⌈日志2 (|D_出| /B_米)⌉,引发了一个阶段的执行成本

4.2。洗牌中间数据的格式

为了合并中间数据,洗牌中间数据的格式是首次引入,然后共享字段合并算法。

火花的MapTask洗牌阶段提取所需的数据扫描源数据文件的每一行。然后它存储数据的键和值<键,值>双和输出到本地磁盘。工作第一阶段在图8作为一个例子,相应的查询选择l_partkey、l_quantity l_extendedprice lineitem的一部分p_partkey的地方=l_partkey。

解析后的工作流程都是加入了减少任务的火花SQL。在MapTask阶段,从lineitem表读取的数据行,然后l_partkey保存为关键,l_quantity和l_extendedprice保存的值。在减少方便连接操作,实际表单的<键,值>对< l_partkey, l_quantity | l_extendprice | >。

同样,第三阶段在图8、查询选择l_partkey l_quantity lineitem的供应商那里s_suppkey = l_suppkey s_nationkey = 2。<键,值>对生成的洗牌阶段< l_suppkey, l_partkey | l_quantity >。

字段l_partkey出现在中间数据输出的第一阶段和第三阶段,作为一个关键和其他的价值。与此同时,l_quantity也出现在这两个阶段的价值。因为两个子查询只涉及连接和投影操作,没有选择操作,输出数据从阶段1和阶段3包含MapTask lineitem表中的所有行。可以认为,这两种类型的对包含所有l_partkey l_quantity lineitem表,这样他们就可以被合并。虽然合并减少写当前阶段的成本,也增加了阅读后续阶段的成本。例如,第二阶段加入表和lineitem表部分,但合并后读取意外l_suppkey字段。同样,第五阶段加入供应商表和lineitem表,但合并后读取意外l_extendedprice字段。因此,保存的写作成本字段和阅读成本增加的字段应该在洗牌重来确定是否合并中间数据。这个问题可以通过共享字段合并算法来解决。

4.3。共享字段合并算法

假设阶段的SQL语句_我是选择我₁,我₂、…我_n从表_我,<键,值>的格式对生成的是<我₁,我₂|我₃|…|我_n>。<键,值>的格式对生成的阶段_j是<j₁,j₂|j₃…|j_米>。让年代_我= {我₂,我₃、…我_n},年代_j= {j₂,j₃、…j_米},那么<键,值的格式>对<合并后我₁∪j₁,年代_我∪年代_j-i1∪j₁>。首先比较两双的关键。统一成一个字段,如果字段名称相同,否则,由“|一起加入两个字段。“下一个,合并两双的值集和删除已经出现在关键的领域。总之,合并后的数据格式的中间数据阶段1和阶段3是< l_partkey | l_suppkey, l_quantity | l_extendedprice >。

测量了写作的好处字段和字段的阅读成本增加,成本模型的定义 在|D_写| = |D_出|l_{save_cols}/l_总、|D_读| = |D_出|l_{add_cols}/l_总。l_{save_cols}写作的是保存字段的长度。l_{add_cols}阅读是增加字段的长度。l_总是总字段的长度。|D_出|可以由第二章中描述的方法计算。例如,合并后对以上,重复写l_parkey和l_quantity可以减少,和l_{save_cols}=l_{l_partkey}+l_{l_quantity}。同样,阅读l_extendedprice l_suppkey增加,冗余l_{add_cols}=l_{l_extendedprice}+l_{l_suppkey}。让E= Savings-Costs。如果E> 0,这意味着共享冗余字段的降低成本的成本大于阅读附加字段。中间的公共字段数据可以合并。否则,如果收入< 0,这些字段不会合并。是否要合并的中间数据需求比较储蓄的价值和成本的价值。

5。实验

我们验证了SSO系统的性能在这一节中。测试数据生成的tpc - h基准测试工具。查询语句的一部分提供的tpc - h被选中来测试这个系统的性能在两个部分:中间数据缓存合并测试和中间数据关联算法测试。

5.1。实验环境和数据集

硬件环境如下。实验集群10包括一个主节点和子节点。节点通过千兆以太网连接。每个节点配置了2.7 GHz CPU(8核16个线程,20 m缓存,涡轮频率),64 GB的DDR3 1600和500 GB SAS机械硬盘。

至于软件环境,操作系统使用的头节点和奴隶节点Centos6.7。每个节点安装JDK 1.8.0, Hadoop 2.6.0,引发2.0.1和Scala魅惑。实验中使用的编程语言开发Java和Scala。IDE是在开发环境中使用。

这里使用的实验数据集被tpc - h基准测试工具生成的。TPC - h是一个标准数据库管理系统性能测试由TPC(美国事务处理性能委员会),一个非营利性的组织。它可以用来模拟业务应用程序环境在现实生活中,被广泛用于评估决策支持系统的综合性能。使用命令生成的测试数据dbgen - s x提供的tpc - h的地方x表示生成GB的数据大小。除了测试数据集,tpc - h也提供了22 Q1-Q22查询语句。用户使用命令qgentpc - h来生成这些查询提供的性能测试。

5.2。火花洗牌中间测试数据缓存

在完成内存分配的火花洗牌在每个节点缓存层,选择几个具有代表性的查询在tpc - h Q1, Q5,网上购物的时候,问题19。Q1和问题19大的输入数据和更少的中间数据。Q5,你校的时候有更少的输入数据和更大的中间数据。查询程序提交给SSO系统和原引发体系,和查询执行时间被记录。实验结果如图所示9。

Q5结果表明,网上购物的时候他们的中间数据远远大于输入数据,中间数据缓存层可以解决高的问题随机磁盘我/O成本。优化的效果是显而易见的。但对于Q1和问题19的输入数据大于中间数据,读取输入数据占多数的磁盘我/O。中间数据缓存层的优化效果的查询是相对有限。

磁盘的变化我/O在查询过程如图10。从图可以看出,自源数据存储顺序,阅读的过程产生的输入数据集中的磁盘我/O。在这两个系统,磁盘读取率大约是80 MB / S的峰值性能稳定的机械硬盘。在运行过程中,阅读和写作的程序进入洗牌阶段中间数据。在这个时候,引发系统随机生成的原始磁盘我/O和磁盘读取率波动很大。它花了很长时间来完成洗牌过程在最初引发体系。使用SSO系统中间数据缓存层,和中间数据在内存中读取和写入。所以,SSO的洗牌阶段系统没有生成磁盘I / O的成本。SSO系统查询任务完成速度比原来的引发体系。图11显示两个系统的内存使用相似上半年的查询过程,都稳步上升。当进入洗牌阶段,SSO系统由查询系统论模块计算所需内存大小和分配的每个节点的内存缓存层分配模块。因此,内存使用SSO系统将增加瞬间。这部分内存将查询结束后发布。查询的整个过程中,主节点有足够的内存(64 GB),而查询网上购物所产生的中间数据的大小仅为14.1 GB。可以创建一个块作为中间数据缓冲区内存空间。SSO系统内存使用率较高,这是主要原因之一SSO系统的执行效率就越高。

5.3。中间数据相关性测试合并算法

通过合并相同的中间数据字段,生成中间数据的大小可能会进一步降低,从而减少内存使用的中间数据缓存层。来验证算法的有效性,在这一节中,选择篮的tpc - h查询提交给SSO系统和原来的火花SQL系统分别。同时,不使用中间数据相关性合并算法,原始火花SQL系统在两种情况下进行了测试:使用中间数据缓存层。查询执行时间被记录下来,如图12。

结果表明,SSO系统和火花SQL的执行时间和中间数据缓存层既短比火花SQL系统没有任何优化,而前两个系统的执行时间往往是相同的。为了比较这两个系统中,每个节点使用的缓存大小的监测结果见表3。

缓存的使用SSO系统合并中间数据关联算法比火花的SQL系统在每个节点没有优化算法。这是因为通过共享相同的字段l_partkey l_quantity,中间1.5 GB的数据可以减少和写作的数据导致磁盘成本19.2秒。冗余读取字段l_extendedprice和l_suppkey也生成。阅读1.26 GB的数据引起的磁盘我/O的16.4秒。比较表明,保存的成本大于生成的成本。所以,在这种情况下,算法将会合并相同的中间数据。然而,中间数据在内存中读取和写入后采用缓存层和内存读/写率超过几十GB每秒。前提是缓存层缓存所有的中间数据,缓存使用的数量几乎没有影响任务执行效率。这是主要原因的查询时间前两个实验往往是一致的。但在集群内存资源紧张的情况下,合并中间数据关联算法可以降低缓存的使用,从而节约有效的内存资源。

6。结论

成熟的内存计算框架,火花,代表内存计算框架,吸引了越来越多的注意力从企业和研究小组。数据分析师和引发系统之间的桥梁,火花SQL扮演重要的角色。优化火花SQL查询的性能,提高了现有火花SQL和SSO原型系统的开发。通过添加火花洗牌中间数据缓存层,高磁盘我/O成本引起的随机读写的中间数据减少洗牌阶段。为了解决冗余的中间数据读写的问题引发的SQL,合并算法,提出了一个基于成本的相关性。它被用来决定是否合并任务相关的重合并的好处和额外的成本,从而提高查询的执行效率。实验平台构建和SSO系统开发。tpc - h基准测试工具用于生成测试数据。与现有火花SQL性能比较系统的有效性进行了验证工作。

数据可用性

所有数据用于支持本研究的结果包括在本文中。

的利益冲突

作者宣称没有利益冲突。

确认

这项工作是公司支持的科技项目叫做“通用组件的关键技术的研究和应用的新一代电网调度控制系统平台,”协同创新中心和部分支持的新的软件技术和无线通信技术的工业化和协同创新中心。

引用

1. l . x, m . Chen他et al .,“猛犸象:杠杆hadoop mapreduce向内存密集型应用程序,”IEEE并行和分布式系统,26卷,不。8,2300 - 2315年,2015页。视图:出版商的网站|谷歌学术搜索
2. m . Zaharia m . Chowdhury t Das et al .,“弹性分布式数据集:内存中的集群计算的容错抽象,”学报》第九届USENIX大会网络系统设计和实现美国加利福尼亚州圣何塞USENIX协会,2012年4月。视图:谷歌学术搜索
3. 旷k Shvachko, h, s拉迪亚et al .,“hadoop分布式文件系统,”学报2010年IEEE 26日大规模存储系统和技术研讨会上(MSST)IEEE,页1 - 10,斜坡村,NV,美国,2010年5月。视图:谷歌学术搜索
4. Apache HBase,http://hbase.apache.org/。
5. v . k . Vavilapalli a . c .没吃,道格拉斯c . et al .,“Apache hadoop纱:另一个资源谈判”第四年度研讨会上云计算的程序美国,ACM,圣克拉拉,CA, 2013年10月。视图:谷歌学术搜索
6. 几何,a . Konwinski m . Zaharia et al .,”便:一个细粒度的资源共享平台的数据中心,“NSDIp。卷。11日,22日,2011年。视图:谷歌学术搜索
7. m . Zaharia t Das,李h . et al .,“离散流:一个高效和容错模型进行流处理大型集群,”HotCloud,12卷,p。2012。视图:谷歌学术搜索
8. r . s .鑫j·e·冈萨雷斯·m·j·富兰克林et al .,“Graphx:火花弹性分布式图形系统,”学报第一国际研讨会图数据管理经验和系统ACM,纽约,纽约,美国,2013年。视图:谷歌学术搜索
9. Agarwal, b . Mozafari a .熊猫et al。”BlinkDB:查询与有界非常大的数据上的错误和有界的响应时间,”学报》第八届ACM欧洲计算机系统页29-42 ACM,布拉格,捷克共和国,2013年4月。视图:谷歌学术搜索
10. 孟x, j·布拉德利,b•et al .,“Mllib:机器学习在apache火花,”2015年,https://arxiv.org/abs/1505.06807。视图:谷歌学术搜索
11. m . Armbrust r . s .鑫c连et al .,“火花,火花sql:关系数据处理”学报2015年ACM SIGMOD国际会议管理的数据ACM,页1383 - 1394年,墨尔本,澳大利亚,2015年6月。视图:谷歌学术搜索
12. r . s .鑫j . Rosen m . Zaharia et al .,“鲨鱼:SQL和丰富的大规模分析”学报2013年ACM SIGMOD国际会议管理的数据2013年,页24里面,ACM,。视图:谷歌学术搜索
13. a . Thusoo j . s . Sarma n . Jain et al .,“蜂巢:仓库解决方案通过使用映射-规约模式框架中,“美国养老,卷2,不。2、1626 - 1629年,2009页。视图:出版商的网站|谷歌学术搜索
14. d . Vengerov a·c·Menck m . Zait和s . p . Chakkappen“加入大小估计过滤条件,”美国养老,8卷,不。12日,第1541 - 1530页,2015年。视图:出版商的网站|谷歌学术搜索
15. r·辛格尔和p·辛格火花的平台,性能保证模型应用程序”绩效评估和基准测试的技术会议施普林格,页131 - 214年,慕尼黑,德国,2017年9月。视图:谷歌学术搜索

版权

版权©2020 Xuechun et al。这是一个开放的分布式下文章知识共享归属许可,它允许无限制的使用、分配和复制在任何媒介,提供最初的工作是正确引用。