云数据管理系统中查询技术研究综述(2)

　　(2)基于调整后MapReduce的连接算法

　　原始的MapReduce框架是一个"过滤-聚集"的过程，这对处理同构的数据源比较有效[37]，然而在处理多表连接时会遇到两方面的问题.一方面，参加连接的数据源往往是异构的，因此在连接处理过程中需要对不同数据源的数据进行同构化处理，例如增加数据源标记等.同构化处理过程不但需要额外的存储开销，而且增加了数据传输量.另一方面，原始的MapReduce框架在处理多表连接时会产生大量中间结果和检查点，这也增加了数据传输量.

　　文献[34]针对异构数据源问题对MapReduce框架进行了扩展，在reduce步骤结束后增加了一个merge的步骤，形成Map-Reduce-Merge框架.Merge的输入数据可以来自不同reducer的输出，这样在一个MapReduce作业里可以处理多个数据源.实现连接的过程类似于传统MapReduce上的重分区连接，不过在map阶段不需要为不同表的数据登记标签，merge阶段可以将两个表对应reduer输出的排序数据进行合并连接.新加坡国立大学的研究人员提出了Map^Join-Reduce框架[35]，并对原始MapReduce的处理过程进行了两方面的扩展.针对第1个问题，文献[35]提出了"过滤-连接^聚集"的编程框架，连接函数可从多个数据源读入数据进行处理，连接函数内容和连接顺序由用户定义.针对第2个问题，Map-Join-Reduce对Map完成后的混洗过程进行了扩展，将原来的"一对一"模式扩展成"一对多"模式，Map函数输出的中间结果一次可以传给多个连接函数.这样通过相应的分区策略可以用一个MapReduce作业完成多表连接，从而减少多个作业处理过程带来的大量中间结果存储和传输问题.

　　与基于原始MapReduce的连接算法相比，基于调整MapReduc的连接算法可以通过较少的作业完成原始MapReduc框架需要多个作业才能完成的复杂连接，因此可以减少中间结果的数据传输和检查点数量.对MapReduce框架的调整主要通过增加处理函数或者扩展部分数据流程实现，这使得原来简单易用的MapReduce框架变得复杂，也增加了编程接口的使用难度.

　　3.2.3查询优化

　　在数据管理系统中，对于一个给定的查询，通常有多种处理策略，查询优化技术负责从多种策略中找出最有效的查询处理计划.云数据管理系统中的查询优化可以从两个方面进行：一方面在解析查询语句并生成MapReduce计划时进行，根据数据的元信息选择执行更为高效的MapReduce计划；另一方面在执行MapReduce任务时进行，根据数据的统计和资源分配等信息构造详细的任务执行策略.已有的查询优化工作主要集中在第2个方面，下面从任务的调度、任务的处理优化两个方面对已有工作进行总结.

　　(1)调度优化

　　云计算是一个多用户的环境，服务提供商依据签订的相关协议向用户提供不同级别的服务，因此对不同用户提交的查询进行调度以保证服务质量是非常必要的.另一方面，云计算环境通常是分布式异构的，查询往往被分解成多个任务并行执行，根据资源的占用情况和节点的运行情况对任务进行有效的调度对查询优化有着至关重要的作用.目前针对调度的优化已经有不少工作，根据调度对象的粒度，可以把已有工作分成3个类型：查询调度[38]、皿&9尺《^";作业调度[39]和MapReduce任务调度[16'4。].

　　文献[38]提出了一种在云环境下对用户提交的查询进行调度的算法iCBS.服务提供商和用户之间通过签订服务等级协议SLA(ServiceLevelAgree^ment)来保障云服务的质量和可靠性，SLA定义了为用户提供的服务标准以及服务商不能满足服务需求的惩罚代价.SLA涉及云服务中可用性、安全性等多个方面，iCBS主要关注查询响应时间.该算法根据查询的提交时间和该查询的SLA相关定义以增量的方式计算其优先系数，依据优先系数对查询进行调度，以尽量减少查询的响应时间，并减少服务提供商因不能满足SLA需求而产生的代价，CBS的时间复杂度为O(logN)，其中N为查询的数量.

　　文献[39]提出了一种对MapReduce作业进行调度的算法FAIR来优化作业的执行效率.传统的MapReduce作业调度方法是先进先出（FIFO)算法，这种算法实现起来比较简单，但是在多用户的环境下会影响作业的执行效率.FAIR提供了一种让用户公平获取计算资源的调度算法，它使用资源池组织作业，并把资源公平的分到资源池中.每个用户使用一个资源池，这样每个用户可以获得等同的资源分配.除此之外，FAIR允许赋给资源池保证最小共享资源（guaranteedsharedresourece),这样可以保证特定用户、群组或生产应用程序总能获取到足够的资源oPhan等人[40]关注异构环境下MapReduce作业的任务调度优化，把每个任务的执行时间、心跳检测时间间隔、数据输入时间等5个变量组合成约束集合，以最小化作业的延迟相应时间为目标函数，将MapReduce作业调度问题转化成约束满足问题(ConstraintSatisfactionProblem,CSP)进行解决.文献[6]的调度粒度也是MapReduce任务，主要关注掉队任务（stragglertask)的调度优化.在传统的MapReduce调度中，为了防止作业执行过程中"木桶效应"的出现，会将掉队任务进行备份执行.然而原有的掉队任务调度方法假设集群环境的同构性和任务执行的等速性，这在实际的云计算环境中往往是无法保证的.基于上述问题，文献[16]提出了LATE算法，根据所在节点的性能预测每个任务的剩余完成时间，并选择剩余时间最长的任务作为掉队任务进行调度.在调度过程中，如果有空闲的任务槽位（taskslot)出现并且正在运行的任务总数小于特定阈值，则创建该任务的执行副本.该算法需要对所有正在运行的任务进行剩余时间的预测和排序，算法复杂度为〇(M)，M为正在运行的任务个数.

　　(2)任务处理优化

　　基于MapReduce实现云数据的查询可以获得良好的扩展性、容错性以及较高的性价比，然而粗犷的批处理模式导致基于原始MapReduce框架的查询性能有很大的提升空间.查询任务处理的优化问题引起了学术界的广泛关注，已有的优化措施包括以下几种：

　　①任务共享.云环境中的数据查询通常是以批处理的方式处理大规模数据，在该模式下通过查询之间的任务共享来减少冗余计算将有效减少查询执行时间和耗费的计算资源.只^^[9]提供了一种用户自定义模式的数据扫描共享（scanshare),如果两个作业的输入数据文件相同，则会创建一个新的MapReduce作业负责数据的读入和解析，并为两个作业产生相应的临时输入文件.这种任务共享方法增加了一个MapReduce作业，而且还需要用户自已定义共享函数.另一类任务共享方法是把满足共享任务条件的作业分到一个组中，使用一个MapReduce作业来完成原来多个作业需要完成的工作，不需要用户自定义，也不需要产生临时文件[41-44].文献[42-43]主要支持数据扫描共享，而文献[43-44]则支持扫描共享、Map输入Map输出以及Map函数的共享.

　　②增量计算o目前在大多数云数据管理应用中，查询的数据规模往往随着新数据的产生而不断增加.如何使查询流程增量化，并利用已有的查询结果处理新的查询也是目前学术界关注的一个问题.根据增量计算的触发方法，已有的工作可以分为两类：对用户不透明的方法[45-46]和透明的方法[42,7-48].Google的Percolator建立在GFS-BigTable之上，它通过快照隔离实现了跨行和跨表数据的一致性，使得用户可以跟踪计算过程中的状态，并实现增量计算[5].Yahoo!的CBP提出了一个新的并行编程模型，用来存储和使用运行状态，并实现查询的增量处理[6].这两种方法的基本缺陷是要求用户自己编写动态程序来对数据进行有效的增量处理.Nova[42]在Pig/Hadoop基础上创建了一个数据流管理器，用来管理不同查询的数据集和查询结果，并支持有状态的数据追加操作.当查询提交后，管理器判断该查询任务是否可以利用已有的结果进行增量计算.与Nova不同，HaLoop[47]和Incoop[48]从MapReduce任务的层次进行增量计算的处理.Incoop在分布式文件层使用基于内容的数据块划分方法来增加map任务的重用度，并通过在combine阶段将混洗的数据粒度减小来最大化reduce任务的重用度.

　　③数据组织优化.云数据管理系统中的数据被分布到多个节点进行管理，在进行查询特别是多表查询时，需要在各个节点间进行数据传输.如果较多的相关数据存储在一个节点上，那么网络传输代价就会减少，查询时间也会随之减少，因此数据的组织方式会对查询性能产生很大的影响[49].HadoopDB将数据从分布式文件系统导入到每个节点上的关系数据库系统中，这样可以在本地的关系数据库上分别执行连接[8].Hadoop++[5°]将数据组织优化模块植入Hadoop系统之上，主要关注两表连接时的查询优化.Had〇〇p++在数据导入时对输入数据建立"特洛伊"索引，并将具有相同连接键值的数据放入同一个数据分片中，这样在实现连接时不需要进行数据的网络传输.该方法没有修改Hadoop，而是在导入数据时进行数据的重新组织.C〇Had〇〇p[51]则是修改了Hadoop的数据组织方法，为每个文件增加了"Locator"属性来标识其位置，而所有具有相同"Locator"属性的文件的数据块将被组织到同一个数据节点集合中.

　　除了上述查询优化方法，目前还有部分工作对MapReduce的参数设置进行优化[52-53]，其中文献[2]通过分组的数目对reducer个数进行优化，而文献[53]则是通过估计MapReduce作业的执行时间提供对多个参数的基于代价的优化.总的来说，目前已有的优化工作主要集中在数据控制层和数据存储层，而且大部分是基于规则的优化，基于代价的优化工作还比较少，亟待相关研究成果.

　　3.2.4在线聚集

　　在线聚集（OnlineAggregation,OLA)在查询处理过程中根据采样数据估计查询结果，并返回真实结果所在的置信区间[54].在线聚集的最大优势是可在较短时间内计算出接近实际的查询结果，当置信度和置信区间达到用户要求时，查询即可提前停止.对于原本执行时间特别长而且对结果精确性要求不高的复杂查询，在线聚集可以大大缩短查询时间.在线聚集最初提出是在单表上进行聚集的相关操作[55-56]，后来该工作被扩展到多表连接基础上的聚集操作[57-59]以及并行环境中的连接聚集[6M1].在线聚集基于关系数据库提出，并在研究领域取得了丰富的成果，但是相关成果在关系数据库领域带来的市场价值却很有限，原因有两点：首先，OLA要求查询处理的数据以随机顺序出现，这与排序、索引等查询优化算法的原则相违背，因此在已有的关系数据库系统上实现OLA需要对其内核进行大规模改动；其次，OLA的最主要目标是缩短查询运行时间和节省软硬件资源，然而在一个非弹性的数据中心，这个目标的吸引力并不大.在云计算环境下，OLA技术又重新引起了人们的关注.一方面，云计算提供了一种pay-as^yoirgo的服务模式，节省计算资源直接意味着节省开销；另一方面，不同于传统的关系数据库，云数据管理系统内核轻量易于修改.目前在云计算上的OLA已经有一些初步的工作，主要是在MapReduce框架上实现大规模数据的查询估计.其相关技术包括MapReduce在线化、数据采样、查询结果估计和收敛程度计算，下面我们分别分析这些技术的已有工作．

　　(1)MapReduce在线化.传统的MapReduce数据流是一个批处理的过程，无论是map任务还是reduce任务，必须处理完所有数据后才产生输出结果，而且reduce任务也必须在所有的map任务完成后才开始执行.OLA要求数据流是一个在线处理的过程，处理完部分样本数据后就输出估计的查询结果，MapReduce的在线化处理[2-63]为云环境下的OLA提供了实现平台.文献[2]的MapReduce在线化主要面向"自增迭代"的算法，通过map定期传送数据给reduce实现作业内部的在线化，并通过集群"共享内存"实现作业之间的在线化.这种在线化方法结构简单，易于实现，但是其扩展性及容错性不及传统的MapReduce.Condie等人[3]基于操作器（operator)之间数据流水线实现了在线化的MapReduce系统HOP.HOP结合网络负载状况以及combme操作的压缩比等因素设计数据流控制机制，从而动态控制mapper与reducer之间的数据传输粒度.当一个查询由多个MapReduce作业构成时，生产作业根据任务执行进度定期调用reduce并生成快照文件（snapshot)，消费作业通过读取快照文件从而实现数据在作业之间的流水化.HOP保留了传统MapReduce的扩展性和容错性，比较适合作为在线聚集的实现平台

　　(2)数据采样.为了保证估计结果和置信区间的准确性和收敛速度，在线聚集要求采样数据具有随机性和无偏性[55-56].从关系数据表进行采样的方法主要有三类[56,64]:顺序扫描、索引扫描和索引采样.Wu等人[1]提出了从分布式数据表采样的方法，首先根据表在各节点上的分布情况计算每个节点应采样的数据量大小，然后在每个节点上进行索引采样.在云环境下，很多数据以块（block)为单位直接存储在分布式文件系统上，MapReduce处理数据也通常以块为单位，因此上述基于关系数据库的采样方法无法直接使用.目前很多MapReduce的在线聚集工作假设数据以随机顺序存储或者假设一个随机数据输入队列的存在[54'3，通过顺序扫描数据队列即可获得随机无偏的数据.然而当数据以聚集相关列的顺序存储时，简单的顺序扫描便无法获取随机数据，因此在云环境下如何从直接存储在分布式文件中的数据中进行随机采样仍然是亟待解决的问题.

　　(3)查询结果估计.查询估计方法应当具有无偏性和持续性[57].无偏性是指如果不断重复采样和估计的过程，估计值的数学期望应该等于实际查询结果.持续性是指随着采样和估计步数的不断增加，估计值应该逐渐接近实际查询结果.目前已有的查询结果估计算法可以分为两类，一类是通过样本和总体数据量的大小对样本的聚集结果进行扩展[61'64].假设查询语句为SELECT〇汐（())FROM了.设随机变量为|7"|X⑴，当元组^满足查询选择条件时，rr^rrsiow#⑴的取值为rrfrrdow(i〇,否则取值为0,则总体均值"即为聚集查询结果，总体方差为ff2.根据中心极限定理，当采样数据随机且无偏时，样本数据的均值^趋近一个均值为…方差为ff2/"的正态分布.设T"是总体表了的采样数据集合，那么总体查询结果可通过用T和T"的大小比例对全表数据的⑴之和进行扩展得到.这种方法实现简单，而且支持增量计算.但是需要预先得到总体表的数据量，而且查询结果的估计受数据分布和采样质量的影响较大.

　　为了解决上述问题，Pansare等人[54]提出了利用未知样本概率分布进行估计的方法，假设每个数据块在MapReduce中的调度时间和处理时间均与聚集结果相关，并针对每个数据块6/〇成构造随机变量乙=(^，f严，iProc).该方法利用贝叶斯公式，根据已处理完数据块的聚集值计算未处理样本数据聚

　　集值的概率分布:P(0|X)=P(X|())(0)，其中，

　　表示未处理样本的聚集值；X表示已经处理完样本的聚集值.总体的查询结果通过对P(0|X)积分进行估计.这种方法通过贝叶斯理论从一定程度上消除了采样数据不均衡所带来的问题，但是算法的假设较强，而且只能支持一个MapReduce作业的查询处理，不支持由多个MapReduce作业构成的多表聚集的结果估计.

　　(4)结果收敛程度计算.结果收敛程度主要用来衡量当前估计值和实际结果的差距，帮助用户判断估计结果是否达到满意的程度.目前结果收敛程度的计算方法有两类，一类采用绘制"收敛曲线"的方法体现随着查询不断进行，估计结果的变化情况[62].变化的度量标准采用以下公式计算：METi?J&=A//Ug(尺），(心）），其中，心是到目前查询进程为止的最新结果是与i/相邻的估计结果；(i)代表结果i的一个标识，它可以是完整的结果i，也可以是能够代表i的一个压缩表征；山//()用于计算两个结果标识的欧氏距离.用户可以根据收敛曲线的斜率来推测查询结果后续的变化情况.这种方法计算量不大，实现起来也比较容易，收敛曲线可以让用户直观地观察出估计结果的变化.但其缺点是无法给出估计值的精确度，而且仅仅根据相邻结果的距离来体现收敛程度还不够准确.

　　另一类收敛程度衡量方法是给定置信度《，在每次采样并得到查询估计值后计算实际查询结果贫的置信区间[幻一s^+s][54,56-57,61]，这意味着A落入置信区间的概率为随着查询的不断进行，置信区间的宽度逐渐变窄，用户可根据区间的宽度判断查询是否提前终止.当样本数据随机且无偏时，根据中心极限定理，置信区间可表示为

　　其中，々是和置信度相关的分位点；-"是样本数据的方差，《是样本数据量.文献[4]通过贝叶斯公式计算未知样本的分布函数，并在此基础上使用Gibbs采样算法[654十算置信区间.通过置信区间可以比较精确的反应估计值的收敛程度，目前在云环境下的相关工作还局限于单个MapReduce作业，如何计算多表或者多个MapReduce作业构成的聚集查询的置信区间仍是待解决的问题.

　　4未来工作展望

　　作为一项高性价比管理海量数据的技术，云数据管理系统引起了工业界和学术界的广泛关注.本文依据云数据管理系统框架对云数据查询技术的相关工作进行了总结和分析.总体来说，目前该领域的研究工作处于起步阶段，还存在着大量有价值的研究问题：

　　(1)数据分布策略.数据的组织情况会直接影响数据插入以及查询的效率，均匀的数据分布将大大提高数据存取的性能.在云数据管理系统中，数据被划分到多个节点进行存储管理，其存储的节点位置往往由每条记录的主键值决定.现有的工作一般选择单个字段或者多个字段的简单组合作为主键值，而没有考虑到对数据分布的影响.对于这个问题，可以从以下两个方面来考虑：首先根据查询类型和数据分布情况选定生成主键值的字段，这些字段的组合应当能够唯一地确定主键值，并有利于数据的分散和查询时数据记录的定位；其次，设计从多维字段的定义域到线性主键值的映射函数，该函数要保证数据分布的负载均衡，并在查询处理过程中尽可能地缩小目标数据集大小.此外，这种数据分布策略应当具有自适应性，可以根据插入数据的不断变化而进行相应的调整.

　　(2)索引管理技术.目前在云数据管理系统中针对海量数据的索引已经有一些研究工作，并取得了相应的成果，在以下两个方面还有待深入研究.一方面，目前云数据管理系统中的索引方案大都是以关系数据库中的索引为基础，对其进行适当修改而成.这些索引都是基于磁盘的索引，比较适合于相对稳定的数据.但是对于数据频繁更新的情况，索引更新维护的代价比较高.因此，如何在云计算环境下，设计能支持频繁更新和多维查询的索引方案是一个富有挑战性的工作.另一方面，现有的索引大都能够支持点查询、范围查询等简单查询，但对于一些复杂查询无法提供很好的支持.特别是在一些特定的应用领域，如海量空间数据管理、海量时间序列数据管理等领域，往往需要支持一些相对比较复杂的查询.因此，针对某些特定的应用领域，设计相应的索引方案，能够支持一些特定的复杂查询，具有重要的意义.

　　(3)查询优化算法.查询处理方法和优化策略对云数据管理系统来说是一个关键性的问题.目前的研究工作主要侧重在利用MapReduce处理框架实现一些关系数据库中传统的查询处理算法，或者改进MapReduce调度算法和处理流程以适应查询处理算法，但是对云计算环境下数据存储和查询处理的特点考虑得较少.云计算环境和传统的单机数据库环境相比，数据量大而且分布存储，但是数据的划分技术却不如分布式数据库中的划分技术成熟，因此数据的分布往往比较粗犷，很难利用数据划分带来的查询优势；另外为了达到较高的可用性和容错性，数据往往存在多个冗余备份，我们认为利用备份数据进行查询并行度和数据传输方面的优化是很有意义的.在进行查询优化的过程中，增加并行度可以充分利用系统的计算资源，提高查询性能，但是单纯的增加并行度可能导致传输数据代价过大，从而造成网络拥塞和计算节点的空闲等待；而单纯的最小化传输代价则可能导致数据倾斜问题加重，因此如何寻求查询并行度和数据传输代价的平衡也是一个不容忽视的问题.以上讨论的是根据优化规则生成查询计划和执行查询计划的问题，然而对不同的数据量和数据分布其最优的查询计划也不相同，如何为不同的查询选择查询计划也是一个亟待解决的问题.查询计划的选择往往通过估算其查询代价进行，代价可以通过查询总开销和总时间表示.结合云计算环境下数据和查询的特点建立不同查询算法的代价计算模型也是颇具挑战性的问题.

　　(4)查询进程估计.相比于传统的分布式数据库，云计算环境中查询进程和剩余时间的估计有着更重要的作用.一方面，云环境下往往面临生物、气象等领域大规模数据的查询和分析，运行时间较长，有的查询甚至需要十几天[67]，提供查询剩余时间的反馈对用户来说有很强的实用价值.另外，对于云环境下的一些查询时间较短但是实时性要求比较高的应用，进程估计会给查询任务的调度提供重要的参考.对查询代价的估算、在线聚集的实现、云环境的性能调优和资源配置等问题来说，进程估计也是一个非常关键的步骤.在云环境下实现查询进程估计不仅任务并行带来的挑战，云环境中集群规模庞大、节点异构、高出错率、和数据倾斜等特点使得这个问题解决起来更加困难.目前的研究工作主要考虑了并行的因素[16，68]，但是对于其他云环境的特点没有考虑，如何在一个大规模的云环境下提供准确的查询进程估计还有很多研究工作要做.

　　(5)基于多表的在线聚集算法.从聚集结果估计和置信区间的计算来看，已有的相关工作主要侧重在包含一个MapReduce作业聚集查询的OLA算法设计.实际应用中经常涉及到基于多表的复杂查询，他们往往由多个MapReduce作业构成，实现这种查询的在线聚集是一个亟待解决的问题.在传统的MapReduce作业处理流程中，每个操作任务完成后将输出数据写入文件，后面的操作任务才能开始.OLA要求数据以增量的方式进行处理，因此多MapReduce作业的OLA必须在处理过程流水线化的MapReduce上实现.在设计聚集查询处理和置信区间计算算法时还需要结合MapReduce以及云计算环境的特点提高在线聚集的处理速度，比如减少混洗过程中数据传输量和reduce阶段的工作，尽量避免增量计算过程中的重复工作等.从数据采样的实现过程来看，样本的随机性和无偏性会直接影响查询结果估计的准确性以及置信区间的收敛速度，已有的研究工作往往假设数据以随机顺序存储或者假设一个随机数据队列的存在，从队头读取数据即可达到随机的效果.然而在实际应用中，数据的存储顺序往往与某个属性相关，如何从这种非随机分布的数据上进行随机采样是在线聚集过程中的一个关键问题.数据的随机采样技术在单机数据库上有很多研究工作[56'64,9-7〇]，提出的方法包括堆文件扫描[56]、索引扫描[64]、伯努利模型采样[69]等.云计算环境下数据分布在大量节点上，而且数据的读写以块为单位进行，这些特点增加了随机采样的难度，值得深入研究.文献[0]针对直方图估计提出了以数据块为单位的采样方法，并利用交叉验证的思想推导出估计值的准确性与样本大小和数据分布的关系公式，其思想可以借鉴到云数据在线聚集的采样算法中.不同之处是该文献提出的算法是一个一次性采样的过程，而在线聚集要求采样算法是在线并且增量的过程，即它能够保证样本大小平缓增长而且时刻保持随机的顺序.在线采样过程中不仅要保证数据随机性，还必须保证每步采样的数据与已采样本数据不重复，这也是算法设计中必须考虑的问题.

　　5结论

　　随着信息产业的不断发展，计算机要处理的数据规模呈指数级增长，各种应用对数据管理的需求也变得多样化，统一而复杂的关系数据库已经不能满足纷繁多样的应用.云数据管理系统为海量数据管理提供了一种高性价比的解决方案，日益成为学术界和工业界共同关注的热门问题.本文对近几年国内外在云数据查询领域的主要研究成果进行了总结，综述了云数据管理系统中查询技术若干主要问题的研究现状，包括云数据的索引管理、查询处理、查询优化以及在线聚集等，并对相关技术进行了深入的对比分析，最后指出仍然存在的问题和可能的解决办法.总的来说，云数据管理系统中查询技术的研究仍然处于刚刚起步的阶段，仍然有大量具有挑战性的关键问题需要深入研究，为国内的数据库研究者提供了广阔的研究空间.

　　参考文献

　　[1] AbadiDJ. Data management in the cloud： Limitations and opportunities. Bulletin of the IEEE Computer Society Tec^h- nical Committee on Data Engineering，2009，32(1) ： 3-12

　　[2] Zhou Ao-Ying. Data inl^ensive computing-challenges of data management techniques. Communications of CCF， 2009， 5(7): 50-54(in Chinese)

　　[3] ChangF，Dean J，Ghemawat S，Ilsieh W C，Wallach D A， Burrows M，Chandra T，Fikes A, Gruber R E. Bigtable： A distributed storage system for structured data//Proceedings of the 7th Conference on Symposium on Operating Systems Design and Implementation(OSDI2006). Seattle，2006 ： 7-15

　　[4] Cooper B F，Ramakrishnan R，Srivastava U，Silberstein A， Bohannon P， Jacobsen II，Puz N， Weaver D，Yemeni R. PNUTS： Yahoo! ?s hosted data serving plat!orm//Proceed- ings of the 34th Conference on Very Large Databases (VLDB2008). Auckland，2008: 1277-1288

　　[5] Pavlo A，Paulson E，RasinA，Abadi D J，DeWitt D J，Mad- den S" Stonebraker M. A comparison of approaches to large - scale data analysis//Proceedings of the 2010 International Conference on Management of Data (SIGMOD2009). Rhode Island，2009： 165-178

　　[6] Stonebraker MJ，Abadi D，DeWitt D J，Madden S, Paulson E，Pavlo A，Rasin A. MapReduce and parallel DBMSs： friends or foes? Communications of the ACM，2010，53(1)： 64-71

　　[7] Shi Y，Meng X，Zhao J，IIu X，Liu B，Wang II. Bench marking cloud-based data management systems//Proceeding so the 2nd Workshop on Cloud Data Management(CloudDB2010). Toronto，2010： 47-54

　　[8] Abouzeid A， Pawlikowski K B， Abadi D， Silberschatz A， Rasin A. HadoopDB： An architectural hybrid of MapReduce and DBMS technologies for analytical workloads//Proceedings of the 35th Conference on Very Large Databases (VLDB2009). Lyon，2009： 922-933

　　[9] ThusooA，Sarma J，JainN，Shao Z，Chakka P，Anthony S， Liu II，Wyckoff P， Murthy R. Hive： A warehousing solution over a map-reduce framework//Proceedings of the 35 th Conference on Very Large Databases (VLDB2009). Lyon， 2009： 1626-1629

　　[10] Robert L G, Yunhong G. On the varieties of clouds for data intensive computing. Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, 2009，32(1):44-50