基于云的连续查询优化

数据流处理技术

1 引言

最近，一类新的数据密集型应用已得到广泛认可：这类应用中的数据最好被建模为瞬态数据流，而非持久关系。然而，这些数据以多个、快速、时变、可能不可预测且无界的连续数据流形式持续到达，似乎带来了一些挑战。

全新的研究问题。这些应用还具有固有的实时需求，对流数据的查询应在各自的截止时间 [1, 2] 内完成。在此背景下，研究人员提出了一种基于流处理引擎（SPEs）的新型计算范式。SPEs 是旨在以最小延迟处理连续数据流的计算系统。数据流不会被存储，而是通过连续查询即时处理。后者与传统数据库系统中的查询不同，因为连续查询会持续“监控”流元组，并不断输出结果。在过去的几年中，数据流处理领域取得了显著进展。从集中式SPEs发展到分布式流处理引擎（DSPEs），后者将不同查询分布到节点集群中（查询间并行），甚至将单个查询的不同操作符分布到不同的节点上（操作符间并行）。然而，一些应用已经达到了当前分布式数据流基础设施 [3] 的极限。

由于输入速率的连续变化，DSPSs需要通过工作负载变化动态调整资源的技术。在何时以及如何根据工作负载变化更新资源分配做出决策，是一个重要问题。已有研究提出了有效的弹性资源管理和负载均衡算法，这些算法通过测量每个相关虚拟机的吞吐量 [3, 4, 5]，根据工作负载需求调整 DSPS部署中的虚拟机数量。因此，云计算作为一种灵活的方式，在前所未有的规模上促进了弹性应用部署的资源管理。云服务提供商通常基于基础设施即服务（IaaS）模型向云租户提供共享机器集。租户通过虚拟化技术在物理资源之上构建自己的虚拟基础设施，虚拟机（VMs）则作为应用程序的执行环境 [5]。

因此，我们将数据流中的研究挑战分为两类：（1）连续查询处理，主要关注连续查询优化、如何实现连续查询的实时应答、如何处理不同类型的连续查询，以及如何高效处理多个连续查询。（2）数据流执行环境，提出了多种用于执行数据流的环境，如并行、分布式和云环境。其中，利用并行性和分布技术来实现快速数据流处理，同时在云环境中利用虚拟化策略以提供响应工作负载需求的弹性处理环境。

本章其余部分组织如下：首先介绍相关背景，然后介绍连续查询的高效处理技术，包括用于有效连续查询优化的不同算法。接着，我们介绍了数据流的不同执行环境，包括并行、分布式和云环境。然后，我们阐述了相关的研究问题。随后，我们提出了基于云计算的数据流处理的提出系统。接下来，给出了未来研究方向。最后，我们给出了结论。

2 背景

2.1 数据流

数据流是由传感器网络、实时互联网流量分析和在线金融交易等大多数现代应用产生的数据。这类数据具有连续、无界、快速且时变的特性，不同于传统应用所产生的有限存储数据集。因此，传统数据库管理系统（DBMS）并不适用于此类数据。为了适应数据流的特性，提出了数据流管理系统（ DSMS）。DSMS处理的是瞬态（时变）数据而非静态数据，并响应持续性查询而非瞬态查询。

2.2 数据流处理

由于数据流的连续性和时变性，需要进行实时和连续处理。在数据流环境下的查询处理中，采用了连续查询。随着数据流的持续到达，查询会随着时间的推移被持续不断地求值。用户只需提交一次查询，便能随时间获得更新的结果，这具有实际意义。

2.3 滑动窗口

处理数据流的一个挑战性问题是它们具有无界的长度。因此，存储整个数据流是不可能的。为了高效地处理和应对无界的数据流，采用了滑动窗口模型。

在滑动窗口模型中，回答连续查询时仅使用最近的N个元素，随着时间推移必须删除旧数据，其中N是窗口大小。

2.4 连续查询优化

连续查询优化是基于两个因素的概念，即时间因素和准确性因素。基于时间因素的优化关注如何最小化对连续且快速的数据流的处理时间。而基于准确**性因素的优化则关注为数据流查询提供精确结果。

大多数传统数据库系统使用单查询优化器，该优化器基于数据的整体平均统计信息选择最佳查询计划来处理全部数据。然而，对于统计信息随时间变化的数据流而言，这种方法效率不高。由于使用单一计划进行数据流处理存在缺点，一些数据库系统确定预计算查询计划，并在运行时即时为元组提供最佳执行计划，作为其优化策略。

3 连续查询处理

本节介绍了用于有效连续查询优化的不同算法，这些算法可实现高准确性的实时应答。同时，还介绍了不同类型连续查询的处理方法。此外，还阐述了如何使用高效方法处理多个连续查询。

3.1 基于多个查询计划的连续查询处理

为了提高查询性能，生成了基于多因素的查询计划优化和迁移策略。该策略不仅能够根据可变数据流特征参数选择优化的查询计划，还能确保查询计划之间的平滑迁移 [6]。

查询网格（QM）框架在[7],中被提出，该框架计算多个查询计划，每个计划针对具有不同统计特性的数据子集进行设计。传统的查询优化器基于所有数据的总体统计信息为处理全部数据选择一个查询计划。由于数据流的特性和其非均匀分布，选择单一查询计划会导致查询结果效率低下。因此， QM 是文献中数据流处理方法的一个良好替代方案。QM 的执行时间比最先进方法最多提高 44%，但该方法因其离线工作而增加了内存使用。

语义查询优化（SQO）方法是在[8]中提出的。SQO在运行时利用动态子流元数据来查找处理输入数据流的最佳查询计划。SQO方法最重要的优势在于，它依赖于识别四种由信使启用的语义查询优化机会，以降低查询执行成本。因此，SQO在应用这些优化时无需使用成本模型。此外，与文献中的其他方法相比，SQO优化技术可将查询执行时间减少多达60%。尽管SQO具有上述所有优势，但它不适用于传感器观测的语义，尤其是在移动传感器的情况下。

林和巴布在[9]中提出了独眼巨人，以高效处理连续查询。独眼巨人是一个连续查询处理平台，用于管理由多个连续查询执行引擎组成的生态系统中的窗口聚合查询。独眼巨人采用基于成本的方法，为执行给定查询选择最合适的引擎和计划。独眼巨人最重要的优势在于：它能够从各种执行计划和执行引擎选项中选择组合来执行连续查询。独眼巨人展示了在三种不同执行引擎——Esper、Storm和Hadoop上，查询执行计划的成本谱系。独眼巨人的一个重要优势是，它提供了窗口聚合查询丰富执行计划空间的交互式可视化。

自适应多路径查询处理（AMR）在[10],中被提出，用于在高度波动的环境中处理流查询。AMR根据最新的系统统计信息动态地将输入元组路由到操作符，而不是使用相同的固定计划处理所有输入元组。提出了自适应多路径索引（AMRI），该索引采用位图时间分区设计。AMRI的主要优势在于它在连续数据流的高效处理与降低索引开销之间提供了平衡。与最先进的方法相比，AMRI将整体吞吐量提高了68%。

表1展示了四种优化连续查询技术的比较（QM 在 [7]中，SQO 在 [8],中，独眼巨人 在[9]中，以及 自动语音识别 在 [10]中），其中 QM、独眼巨人 和 自动语音识别 依赖于成本模型进行工作，但 SQO 不需要成本模型，因为它依赖于四个基于语义的查询

查询 优化 技术	目标	离线工作	成本模型	分配 plan	分类器
QM	查找多个 每个查询计划 对于子流	选择最佳 查询计划 用于训练 data	使用成本 模型以 估算成本 针对每个计划	在线	使用分类器 来分配 计划给每个 传入的 元组
SQO	查找多个 每个查询计划 对于一个子流	识别 语义 查询 优化 机会	无需 使用成本 模型	在线	不使用 分类器
独眼巨人	选择最合适的 合适引擎 和计划为 查询执行	选择最佳 计划引擎 pair	使用成本 模型到 选择 最佳对	在线	不使用 分类器
AMR	连续 元组路由 基于 最新的 统计信息	确定 最新的 统计信息	使用成本 模型以查找 最佳 索引	在线	不使用 分类器

配置

优化机会；这些机会可确保降低查询执行成本。QM 需要一个分类器在运行时测试输入元组。然而，SQO、独眼巨人和自动语音识别在其工作中并未使用分类器。

3.2 具有概率保证的连续查询

在[11, 12],中提出了两种不同的技术，为连续查询的答案提供了概率准确性保证。文献[11]中提出了一种称为ECM‐草图的草图技术。该技术研究了在滑动窗口模型下，对分布式、高维数据流进行复杂查询应答的问题。它能够在基于时间的和基于计数的滑动窗口上，对流数据进行有效汇总，并提供概率准确性保证。尽管ECM‐草图具有诸多优势，但它不支持不确定数据流。

张和程在[12],中提出了用于概率查询的概率过滤协议，该协议考虑了数据的不精确性，并在答案中提供统计保证。该协议的主要优势在于其能够适应部署大量传感器设备的普适应用，降低传感器设备的通信和能耗成本。

基于概率容差，概率过滤协议为连续查询提供准确的答案，并减少资源的使用。概率过滤协议的这些优势共同提升了整体性能。

在[11],中提出的ECM‐草图能够为复杂查询提供答案，而[12]未处理复杂查询。关于高维数据流处理，仅由ECM‐草图进行处理。ECM‐草图不适用于传感器网络，例如概率过滤协议。其中，概率过滤协议可降低传感器网络中传感器设备的通信和能耗成本。概率过滤协议考虑了多个用户查询请求，而ECM‐草图未考虑这些请求。

3.3 连续有界查询处理

在[13, 14]中提出了不同的算法用于回答连续有界查询。Huang和Lin在[13] 中提出了基于连续Within查询（CWQ‐based）算法和连续最小‐最大距离 有界查询（CM2DBQ）算法，以高效处理CM2DBQ。“给定一个移动查询 对象q、最小距离dm和最大距离dM，CM2DBQ在每个时间点检索出到q的 道路距离在(dm, dM)范围内的有界对象”。此外，还提出了一种有界对象 更新机制，用于在发生对象更新时对连续查询结果进行实时评估。

比德和拉马米萨姆在[14]中提出了凯科斯系统，用于高效处理数据流 上的连续有界查询。凯科斯系统的主要优势在于能够持续跟踪高度动态数据 流的演化信息，并有效地提供实时且最新的连续查询结果。此外，该系统提出了一种迭代算法以及一种高效的基于动态规划的算法，用于识别需要更新 的准确元数据，从而实现高效的连续查询响应。

凯科斯系统在[14]中提出，考虑了在多个并行机器上调度多个作业， 而[13]未考虑这一点，因为凯科斯系统运行在多处理器环境中。在准确性 方面，凯科斯系统依赖于提供精确结果的精确元数据，但[13]中的算法未解决此问题。在大型道路网络中提供分布式数据流的实时处理仅在[13]中被处理。

3.4 滑动窗口连接上的连续查询处理

在[15, 16]中提出了两种方法，用于改进滑动窗口连接上的数据流处理。钱等 人在[15]中提出了一种名为不确定数据窗口连接专用协处理器（UWJSP）的 硬件协处理器，以加速数据流的连接处理。该协处理器可在多个不确定数据流上 执行窗口连接操作。UWJSP的主要优势在于显著提升了不确定数据流管理系统 （UDSMS）的处理速度，同时提供了低成本和高性能。

金在[16]中提出了一种用于滑动窗口等值连接的结构，以高效处理数据流。 他们提出了一种替代的哈希表结构用于滑动窗口等值连接。这种所提出的结构的 最大优点是能够轻松查找过期元组并将其丢弃，因为这些元组始终集中在最老的 哈希表中。他们的结果表明，该方法提高了数据流处理的整体性能。

UWJSP在[15],中提出，用于处理多个不确定数据流，而这一点在[16]中未 被处理。此外，UWJSP使用指令集来高效跟踪变化的查询，而这一点在[16]中 未被采用。因此，与[16]中提出的结构相比，UWJSP提供了更高的可扩展性和 灵活性。然而，在[16]中提出的滑动窗口等值连接结构为滑动窗口区间内的每 组到达元组分配一个哈希表，而不是为每个数据流源分配，从而提升了滑动窗口 的性能，优于[16]中的方法。

3.5 连续模式挖掘

在[17–19]中提出了不同的算法用于连续模式挖掘。窦等人在[17]中提出了 索引算法，以在传感器网络中高效地实时回答历史在线查询（约束聚合查询、 历史在线采样查询和模式匹配查询）。这些查询的回答基于传感器设备的闪 存存储。提出了一种索引构建算法来创建多分辨率索引。此外，还提出了两种技术——检查点技术和重构，用于传感器设备的故障恢复。他们的结果证明了提出的算法的有效性。

杨等人在[18]中提出了用于增量检测基于邻居的模式的方法，特别是 基于密度的聚类和基于距离的离群点在滑动流窗口上的增量检测；因为针对 模式检测的连续查询进行增量计算是一个重要挑战。因此，这些方法的主要 优势在于能够在数据流的滑动窗口内实现模式的实时检测。此外，他们还开发了成本模型来衡量所提出策略的性能。

提出了一种称为滑动窗口top‐k模式树（SWTP树）的数据结构，用于 高效挖掘滑动窗口中的频繁模式。SWTP树持续扫描滑动窗口内的数据流。 同时，提出了一种改进的FP‐增长挖掘算法，基于所提出的SWTP树生成 top‐k频繁模式。该算法以频率降序获取top‐k模式。

关于约束聚合查询和历史在线采样查询，这些仅在[17]中处理。只有 [18]中的算法可适用于交通监控。连续模式挖掘在[18,19]中的介绍比在[17] 中更深入。

3.6 连续Top-K查询处理

李等人在[6]中提出了一种称为基于Voronoi图的算法（VDA）的方法，用 于高效回答top‐n双色反向k近邻（BRkNN）查询。此外，他们还提出了一 种查找BRkNN查询候选区域的方法。同时，他们提出了一种过滤‐精炼算法 以高效地回答BRkNN查询。他们的结果表明，所提出的算法能够提高回答 top‐n BRkNN查询的整体性能。

桑迪亚和黛维描述了如何在[20]中高效地回答Top‐K支配查询。 Top‐K支配查询选择k个数据对象，这些对象在数据集中影响的对象数量最 多。提出了改进的基于事件的算法（IEVA）以高效回答Top‐K支配查询。 IEVA利用事件调度和重新调度，避免检查点是否应包含在TOPK中。

在[21]中提出了一种基于分布式分位数滤波的算法，用于在无线传感器网 络中回答前k查询。该算法在无线传感器网络中评估前k查询，以最大化网络生 命周期。此外，还提出了一种在线算法，用于回答具有不同k值的时变前k查询。

[6, 20, 21]提出了不同的方法来回答Top‐K查询。用于获取前k个数据 点的安全区间仅在[20]中计算。该安全区间通过无需检查所有点是否应包含 在TOPK中即可获取前k个数据点，从而加快了查询响应时间。此外，无需 像[6]那样构建维诺图（VD），也无需像[21]那样构建SWTP树。此外， 更新安全区间比更新[21]中的节点更容易。在[6]中，构建维诺图（VD）对于 回答双色反向k近邻（BRkNN）查询非常重要，可避免为每个数据点都计算 BRkNN答案集。李等人在[6]中解决了其余方法未涉及的k近邻答案问题。 因此，在[6]中提出的算法在基于位置的应用中优于其他方法。[21]中的基 于分位数滤波的算法非常适合无线传感器网络；它是唯一一个考虑最大化无 线传感器网络生命周期的算法。

3.7 连续最近邻查询处理

王等人在[22]中提出了一种有效的过滤‐精炼框架，用于高效回答可见k近 邻（Vk NN）连续查询。“Vk NN查询检索出距离查询对象最近且可见的 k个对象”。提出了两种剪枝算法，分别为基于安全区域的剪枝和基于不可 见时间段的剪枝，以减少查询处理的搜索空间。他们的结果表明，所提出的 剪枝技术具有高效率。

提出了一种称为位向量R树（bR树）的二维索引结构，用于在无线网络 中高效处理广义k近邻（GkNN）查询，不仅适用于空间数据对象，也适用于非空间数据对象。提出了一种搜索算法，以有效剪枝bR树的搜索空间。 他们的结果证明了bR树在能耗、延迟和内存使用方面的高效性。

在[24]中提出了一种高效回答连续视场最近邻查询处理的方法。“给定 用户的视场和位置，视场最近邻查询会检索出距离用户位置最近且位于用户 视场内的数据对象”。这些查询的处理分为两个阶段：初始阶段和更新阶段。 针对初始阶段提出了两种算法，分别为朴素探索算法和扇形探索算法。此外， 针对更新阶段提出了扇形监控算法。

在[25]中提出了一种方法，用于在车载自组织网络中高效地回答连续范围k近邻（ CRNN）查询。提出了三种算法，分别称为decide currentvalid interval、decide next split point和find next split point；可高效地确定结果的当前有效区间。该方法的主要优势 在于最小化网络带宽使用、降低计算成本以及减少本地内存使用。

埃尔蒙吉等人在[26]中提出了用于回答时空系统中移动对象的连续聚 合最近邻（CANN）查询的算法。为了计算CANN查询结果，提出了一种整 体算法（H‐CANN）。此外，还提出了一种CANN的渐进式算法（ P‐CANN）；它提高了CANN查询回答的性能。

不确定图中的聚合最近邻查询（UG‐ANN）在[27]中被提出，用于通 过不确定图回答ANN查询，适用于社交网络分析和道路网络监控等应用。 提出了两种剪枝算法以提高UG‐ANN的性能，称为结构剪枝和实例剪枝。

在[28]中提出了一种名为SMashQ的服务器端空间融合框架，用于在时 变道路网络中回答k近邻查询。该框架解决了从道路网络中的车辆或路边传 感器收集实时交通数据的问题。该框架的主要优点是使数据库服务器能够访 问外部Web地图服务（如谷歌地图）中的路线和行驶时间信息。此外，还提出了贪心对象分组算法；以减少外部网络地图请求的数量。SMashQ的最大 优势之一是它可以扩展到大量对象。

提出了一种称为带Voronoi图的虚拟网格四叉树（VGQ‐Vor）的双层索引 结构，用于回答移动k最近邻（MkNN）查询[29]。该结构基于Voronoi图，以 实现对MkNN查询的高效处理。此外，还提出了一种基于VGQ‐Vor的移动k最 近邻（kNN）查询算法。该算法检查查询中移动对象所在邻近区域内的移动对 象。

方舟、国辉、李小松和丛提出了一种基于Voronoi图的方法，用于在[30] 中通过无线数据广播（BPNN）对不确定数据对象进行概率最近邻查询。该方法 利用不确定数据（UV‐图）来回答此类查询。提出了UV‐Hilbert分区方法，将 UV‐图划分为多个网格单元，并提出了一种组织方法来管理UV‐图的单元。为了 解决BPNN查询处理问题，还提出了一种名为UVHilbert‐DI的分布式索引。

关于新兴应用中的数据流处理，只有[22]中提出的框架是合适的。只有 [6, 29, 30]提出的算法依赖Voronoi图来回答最近邻查询。[23],中提出的 BR树处理了数据对象的空间与非空间属性，而其他方法未处理这些属性。 此外，[23, 30]中的算法是唯一针对无线广播系统中数据流处理的算法。只 有[27, 30]中的算法考虑了不确定数据流。 仅在基于范围的应用中的数据流处理中考虑了增强现实系统、导游系统 和基于闭路电视的监控系统。在车载自组织网络的数据流处理中，[25]中 提出的算法优于其他技术，因为其他技术 未考虑这些网络所需的具体规格。关于聚合最近邻查询，仅在[26, 27]中进行了讨论。关于道路网络，仅在[28]中进行了讨论。

3.8 基于树结构的连续查询处理

一种称为查询区域树（QR树）的查询索引结构在[31],中被提出，用于处理针 对移动对象的连续范围查询（CRQs）。“CRQ 是指持续检索当前位于给定 感兴趣查询区域内的移动对象的查询”。QR树的优点之一是减少了移动对 象与服务器联系以获取新驻留域或更新查询结果的频率。

在[32]中提出了不同的算法，以高效回答传感器网络中的连续区域查询。 提出了ECH树生成算法以降低传感器网络中的能耗。此外，还提出了一种时 间相关区域查询方法以高效回答连续查询。他们的结果保证了所提方法的有效性。

在[33]中提出了一种称为虚拟树（VT）的覆盖网络拓扑，用于在大规 模动态网络中高效回答区间有效聚合查询。同时，提出了一种称为覆盖管理 协议（OMP）的分布式查询协议，以保证VT中的连通性和路径稳定性。

Merkle Skyline R树和部分S4树在[34]中被提出，用于高效回答基于 位置的任意子空间skyline查询（LASQs）。LASQs的一个主要优势是它同 时考虑了空间和非空间属性。基于预取的方法被提出，以在外包数据库中为 LASQs提供高效的一次性认证，并减少服务器处理时间。

在[21, 23, 31–34]中提出了不同的基于树的解决方案。在[23, 31, 34]中 处理了数据对象的非空间规格；但其余未处理。此外，只有在 [23, 31, 32, 34]中提出的技術适用于基于位置的服务。[23]中的BR树是 唯一可适应无线广播系统的。而对等系统中的数据流处理仅在[33]中被讨论。 [33]中的技术是回答聚合查询的最佳方案。关于查询认证，仅由[34]进行了 讨论。只有[21]中提出的结构考虑了模式挖掘。

3.9 连续天际线查询处理

纳根德拉和坎丹在[35]中展示了如何计算数据流对上的skyline‐窗口‐连接（SWJ） 查询。给定一组数据对象，skyline查询返回那些不被其他对象支配的数据对象。提出了一种分层skyline‐窗口‐连接（LSJ），其中LSJ操作符将整个过程划分为 处理层。此外，LSJ 优于现有的未设计用于消除多个处理层之间冗余工作的方法。

在双层流式设置中，提出了一种用于连续天际线监控的两阶段方法[36]。在 初始化阶段，通过正确合并来自所有数据站点的局部天际线获得初始查询结果。 然后，根据数据元组在局部天际线和全局天际线中的成员关系对其进行分类。 该方法的最大优势之一是它最小化了服务器与数据站点之间的带宽消耗。

k‐天际带算法是在[37]中提出的，用于在不完整数据上高效回答k‐天际带 （kSB）查询。kSB查询不同于传统天际线查询，其特点是某些维度的值缺失。 该方法基于过期天际线、阴影天际线和厚度仓库这三个概念，以提升查询结果。 此外，还处理了针对不完整数据的约束天际线（CS）和分组天际线（GBS）查询。

黄昌和李在[38]中提出了用于在道路网络中高效回答两种基于距离的天际 线查询（即连续去天际线查询（Cde‐SQ）和连续k近邻天际线查询（ Cknn‐SQ））的算法。为了高效回答Cde‐SQ，提出了Cde‐SQ和Cde‐SQ +算法。此外，为了高效回答Cknn‐SQ，提出了Cknn ‐SQ和Cknn ‐SQ +算法。

在[39]中提出了基于索引（I‐SKY）和非基于索引（N‐SKY）的算法， 以高效回答基于范围的天际线查询。此外，还提出了这两种算法的增量版本， 以避免重新计算查询结果。它们的主要优势是为高度动态数据流节省计算成本。另外，还提出了有效计算每个天际线对象有效范围的高效方法。

在[40]中提出了一种滑动窗口天际线模型，用于高效回答不确定数据流 上的概率天际线查询。此外，提出了候选列表方法以高效确定候选天际线， 这些候选天际线未来可能成为天际线。同时，还提出了增强细化策略，以降低计算成本并提供更精确的结果。

一种名为FSKY的过滤算法在[41]中被提出，用于在传感器网络中高效 回答负相关和聚类数据库的天际线查询。此外，他们还提出了一种数据簇表 示方案。另外，提出了一种采样方法以降低通信成本并节省能量。尽管提出的算法具有优势，但未能处理近似天际线和子空间天际线查询。

在[35] SWJ处理了多数据流上的连续天际线监控，而此前提到的所有 天际线查询处理技术均未涉及此问题。此外，滑动窗口分层以消除连续窗口间的冗余工作仅在[35]中被考虑。 只有[36, 37, 41]中提出的算法解决了分布式环境中（如广域传感器网络）的天际线监控问题。此外，[36, 41]中处理了双层流处理，而其余部分未予处理。关于在不完整数据上的天际线计算、约束天际线以及 分组‐天际线；这些仅在[37]中处理。回答负相关和聚类数据库的天际线查询仅在[41]中处理只。有在[38]中提出的算法适用于道路网络。不确定数据处理仅在[40]中 被考虑。概率天际线计算也仅在[39, 40]中被考虑。[39]中的算法是适用于 基于位置的服务的合适算法。此外，数据的空间和非空间属性仅在[39]中被 处理。

3.10 多连续查询处理

为了为高度动态数据流与多个动态更新的连续查询之间的匹配提供切实可行 的解决方案，流处理系统应支持对新数据的增量评估，并支持针对连续查询 的查询优化，包括多个查询之间的计算共享。多查询优化已被证明是提高查询处理效率的有力技术。通过利用查询之间在共享操作符和数据流方面的重叠 [42]。

Ray 等人在 [43] 中展示了如何将多个查询表示为操作符树的形式，以 便于利用它们的共性进行多查询计划生成。操作符树展示了来自不同查询的 计划如何合并。对相同或相关的数据流的多个查询可以共享其处理，以减轻 处理、存储和通信开销。

连续查询可能很复杂，涉及各种操作符，并非所有操作符在操作符树的 每个节点上都受支持。考虑阻塞性操作符，如连接或计数。这些操作符在应用操作之前需要存储一组数据流元组。某些节点可能没有足够的存储能力来处理这些操作；这是操作符树面临的一个重要问题。

基于现场可编程门阵列（FPGA）的实时数据分析平台被提出[44]。 FPGA在利用并行性方面特别强大，因为任何形式的并行执行都可以直接映 射到硬件中的逻辑电路。此外，FPGA能够满足横向扩展所需的弹性，以应对不断增加的吞吐量需求。FPGA通过利用给定查询计划之间的重叠组件， 进一步提高资源利用率，并生成全局选择‐投影‐连接（SPJ）查询计划。因此，在处理连接操作符时，FPGA优于操作符树[43]。

陈等人展示了如何在[45]中为多个top‐k查询提供实时响应。共享查询结 果是节省计算成本并提供实时响应的关键因素。他们基于频率（该频率指定 了查询重新执行间隔的上限）来共享多个top‐k查询的结果。

在[46]中提出了自适应基于共享的扩展贪心优化方法（A‐SEGO）。A‐SEGO 可用于生成优化的全局 用于多个连续查询的执行计划。A‐SEGO 使用成本模型来确定当前优化的全 局计划是否变得不再高效。当当前计划不再高效时，A‐SEGO 会及时生成一 个新的优化计划。

在 [43–46]中，介绍了四种基于共享的多查询优化技术（操作符树、 FPGA、A‐SEGO 和基于频率的Top‐K）。表 2对这四种技术进行了比较。操作 符树、FPGA 和 A‐SEGO 均通过共享多个查询的处理来实现优化，但在处理连接操作符时，FPGA 和 A‐SEGO 优于操作符树。基于频率的Top‐K 共享具有相同频率的Top‐K查询的中间结果。A‐SEGO 依赖于成本模型，而其余技术不依赖成本模型。

多查询快速天空线计算（FAST）在[47],中被提出，用于处理数据流上的多个连续天空线查询。FAST采用一种过滤技术，能够及早丢弃那些不会 成为任何未来连续查询天空线成员的对象，并使用一种判别方法，能够高效 地确定内存中哪些对象是哪些查询的天空线对象。

4 数据流执行环境

本节介绍了用于数据流的不同执行环境，这些环境可实现高性能和低延迟。 同时介绍了弹性数据流处理算法和动态负载均衡技术。

4.1 并行和分布式流处理

数据流系统中查询处理最关键的要求数之一是快速处理。因此，使用多个处理 单元并行处理查询

方优法化	查询类型	共享策略	输出	基于成本
操作符树	选择‐投影 查询	共享查询处理	单一全局 查询计划	非基于
FPGA	选择‐投影‐ 连接查询	共享查询处理	单一全局 查询计划	非基于
A‐SEGO	多路连接 查询	共享公共连接 操作结果	单一全局 查询计划	基于
基频于率	Top‐K查询	共享查询 中间结果	单一全局 查询计划	非基于

将是一个很好的解决方案。通过多个处理节点实现数据并行性，需要将操作 符的输入流分区为不同的、独立的子流，以便各节点并发地处理[48, 49]。

同时，分布式流处理系统必须能够高效地处理到达率和数据分布波动的 数据流。在分布式数据流管理系统（DDSMS）中，数据流处理任务被分配 到多个处理节点上，然后通过这些节点的协作将结果聚合。因此， DDSMS在支持的数据流速率、可扩展性以及并发查询数量方面实现了更高 性能。

4.1.1 基于MapReduce框架的数据流处理

MapReduce框架已被引入作为一种可扩展且容错的数据处理框架，能够在 水平可扩展的商用机器集群上并行处理海量数据。然而，它并不足以支持实时流处理任务[51, 52]。

内存MapReduce（M3）在[51]中被提出，作为一个并行计算框架， 能够以高可扩展性、高性能和短响应时间高效地回答数据流上的连续查询。 M3扩展Hadoop，其中M3支持Map和Reduce阶段的持续执行，各个映射 器和归约器永不终止。

MapUpdate框架在[53]中被提出，用于数据流的并行和分布式处理。 MapUpdate是MapReduce框架的一个扩展。MapUpdate使开发者能够编写少量函数，这些函数会在一组机器集群上自动执行。同时，它实现了低延 迟和高可扩展性。MapUpdate的主要缺点是无法高效地对输入数据流进行 动态分区。

4.1.2 基于查询巨图（QMG）的数据流处理

Safaei等人在[48]中提出了动态元组路由（DTR）算法，用于在多处理环 境中并行处理连续查询。在DTR中，每个输入数据流元组通过QMG（ QueryMega Graph）中的最短路径进行处理[54]。

表 3展示了M3、MapUpdate和QMG框架之间的比较[48, 51, 53]。这三 个框架为数据流提供并行处理，并以高可扩展性、高性能和短响应时间高效 地回答查询。M3和MapUpdate扩展了MapReduce框架以处理连续数据流。 但QMG在查询巨图上处理数据流。

框架	元组执行	划分元组 执决行策单元	处数理量单元 每个元组	处通路理过由
M3	通过组 映射器和 归约器	基于速率分割	一个映射器和 一个归约器	通过远程方法调用
映射更新	通过组 映射器和 更新器	使用确定性的 打破平局 过程	一个映射器和 一个更新器	确通定过性的 打破平局 过程
QMG	通过K个逻辑 机器	基于成本 模型	每步一个	通过 处节理点本身
将是一个很好的解决方案。通过多个处理节点实现数据并行性，需要将操作 符的输入流分区为不同的、独立的子流，以便各节点并发地处理[48, 49]。

同时，分布式流处理系统必须能够高效地处理到达率和数据分布波动的 数据流。在分布式数据流管理系统（DDSMS）中，数据流处理任务被分配 到多个处理节点上，然后通过这些节点的协作将结果聚合。因此， DDSMS在支持的数据流速率、可扩展性以及并发查询数量方面实现了更高 性能。

4.1.1 基于MapReduce框架的数据流处理

MapReduce框架已被引入作为一种可扩展且容错的数据处理框架，能够在 水平可扩展的商用机器集群上并行处理海量数据。然而，它并不足以支持实时流处理任务[51, 52]。

内存MapReduce（M3）在[51]中被提出，作为一个并行计算框架， 能够以高可扩展性、高性能和短响应时间高效地回答数据流上的连续查询。 M3扩展Hadoop，其中M3支持Map和Reduce阶段的持续执行，各个映射 器和归约器永不终止。

MapUpdate框架在[53]中被提出，用于数据流的并行和分布式处理。 MapUpdate是MapReduce框架的一个扩展。MapUpdate使开发者能够编写少量函数，这些函数会在一组机器集群上自动执行。同时，它实现了低延 迟和高可扩展性。MapUpdate的主要缺点是无法高效地对输入数据流进行 动态分区。

4.1.2 基于查询巨图（QMG）的数据流处理

Safaei等人在[48]中提出了动态元组路由（DTR）算法，用于在多处理环 境中并行处理连续查询。在DTR中，每个输入数据流元组通过QMG（ QueryMega Graph）中的最短路径进行处理[54]。

表 3展示了M3、MapUpdate和QMG框架之间的比较[48, 51, 53]。这三 个框架为数据流提供并行处理，并以高可扩展性、高性能和短响应时间高效 地回答查询。M3和MapUpdate扩展了MapReduce框架以处理连续数据流。 但QMG在查询巨图上处理数据流。

框架	元组执行	划分元组 执决行策单元	处数理量单元 每个元组	处通路理过由
M3	通过组 映射器和 归约器	基于速率分割	一个映射器和 一个归约器	通过远程方法调用
映射更新	通过组 映射器和 更新器	使用确定性的 打破平局 过程	一个映射器和 一个更新器	确通定过性的 打破平局 过程
QMG	通过K个逻辑 机器	基于成本 模型	每步一个	通过 处节理点本身

4.1.3 基于任务图结构的数据流处理

在[55]中提出了两种复制方法论，即数据并行复制机制（DPRM）和任务复 制复制机制（TCRM），以有效提高并行和分布式数据流处理的吞吐量。 DPRM的主要优势在于对同一数据流的不同部分应用并发处理，从而减少处 理计算时间并降低延迟。

Ajwani 等人 在 [56] 中提出了一种基于图的框架，用于生成处理数据 流的任务图。所提出的图生成技术能够生成具有指定度分布的有向图。这些 技术最重要的优势之一是能够正确生成无向图。

在[55]中考虑了数据和任务并行性以提高吞吐量；但在[56]中未予考虑。 此外，任务复制仅由[55]处理。然而，[56]中提出的技术比[55]中的技术 更适合生成大规模流式任务图，因为它们能在合理的时间内完成生成。

4.1.4 交通分布式网络中的数据流处理

Anceaume 和 Busnel 在 [57] 中提出了 AnKLe 分布式算法，以在分布式 系统中高效处理数据流。该算法对观测到的数据流与预期数据流之间的相似 性进行在线估计，从而实时检测网络流量中的入侵。AnKLe 分布式算法的 最大优势之一是估计结果具有有保证的误差界限，并且在存储和处理方面所 需资源较少。

一个基于离散化流的框架在[58]中被提出，用于为大规模数据流提供可扩展的 流量估计。因此，提出了一种在线期望最大化（EM）算法。EM算法的主要优势 是；它通过增量在线更新高效地计算交通的行程时间分布。此外，该算法已 通过大量GPS轨迹数据集进行了验证。同时，该算法可扩展至大型道路网络， 并能在几秒钟内更新交通状态。

在[57, 58]中提出了两种不同的框架用于分布式系统中的数据流处理。 这两种框架都适用于交通网络，但[58]中提出的EM适用于超大城市网络的 交通估计。[57]中的AnKLe由于其具有有保证的误差界限的近似方法，能 够提供更精确的结果，同时也降低了内存使用。

4.1.5 在过载条件下控制数据流处理

单等人在[50]中提出了改进的成对算法，以调整DDSMS中处理节点的负载， 并在所有计算节点之间实现负载均衡。成对算法由两个主要步骤组成：（1） 初始分配（2）改进的负载均衡。基于初始分配算法，采用改进的成对算法 来调整处理节点的负载。

在[59]中提出了鲁棒负载分配（RLD），以在分布式处理环境中提供 鲁棒查询处理性能。RLD在负载波动下提供ǫ‐最优的查询性能，且不会因负 载迁移而遭受性能损失。

在[60]中提出了一种基于模糊逻辑的协同调度框架用于数据流处理。该方 法提出了一种动态控制方法，其主要优点是避免资源短缺和过度配置。在此控制 方法中，采用了模糊逻辑控制，使得CPU能够为数据流处理进行协同调度和协 同分配。同时，采用迭代算法，通过密切监控处理和存储状态来迭代分配带宽。

在[61]中提出了一种流式仓库模型，用于在实时数据流仓库中实时更新 调度。该模型结合了传统数据仓库以及数据流系统的实时和连续处理的主要 特性。为了解决流式仓库的更新问题，提出了一种调度算法。

在[62]数据流处理的自动流水线解决方案中被提出。该方案利用多核处 理器，以高效且透明的方式提高流式应用的吞吐量。此解决方案的有效性体 现在通过动态查找并利用流式应用中的流水线并行性来源，实现对资源的良 好利用。自动流水线采用基础优化算法，以实现对资源的良好利用。

曹等人在[63]中提出了一种名为感知功耗和截止时间的多核调度（ PDAMS）算法，用于多核系统中的实时处理。PDAMS的优势之一是实现 了多核系统的工作负载均衡和节能。此外，在PDAMS中，每个处理器核心 可以自我管理。尽管具有这些优势，但PDAMS并未同时考虑静态功耗以及 电压和频率调节开销。

在[50, 59–63]中提出了不同的算法，以避免因过载情况导致的系统故 障和性能下降。除了RLD之外，所有这些算法都依赖于动态更新和调度来实 现实时工作负载均衡。而RLD则依赖于提供健壮的物理解决方案作为其控制 方法。此外，只有RLD能够在多个逻辑计划上处理数据流。关于高效并行处 理以实现良好的资源利用率，仅在[62, 63]中得到处理。

4.2 基于云环境的数据流处理

云计算提供了弹性基础设施，分布式流处理系统（DSPS）可利用该基础设施按 需获取资源，但目前仍存在一个开放性问题，即如何提供一种可扩展且弹性的流 处理引擎来处理大规模数据流。在[64, 65]中提到了一种透明查询并行技术 “StreamCloud”，其弹性协议具有低侵入性，并能够根据输入负载实现资源 的有效调整。在StreamCloud中，用户表达的常规连续查询将被自动并行化。

Cervino 等人在 [4] 中提出了一种自适应算法，该算法通过调整 DSPS 部 署中的虚拟机数量来响应输入流速率，称为“自适应云流处理”。该方法在保持 给定吞吐量的同时维持低延迟，并使虚拟机运行在其最大处理能力范围内。自适 应云流处理算法周期性地被调用，并计算支持当前工作负载需求所需的新虚拟机 数量。

Fernandez 等人在 [5] 中描述了一种称为“容错扩展”的有状态操作符横 向扩展和恢复的集成方法。该方法根据需求按需扩展云托管机器的数量，在工作 负载增加时并行化操作符，并高效地恢复资源故障。在容错扩展算法中，为了支 持动态扩展，他们添加了一个基于系统统计信息的瓶颈检测器，以识别查询中的 瓶颈操作符。为了支持动态容错，他们添加了故障检测器以恢复故障操作符。

在[66]中，他们开发了一种基于复杂事件处理（CEP）的资源监控框 架，用于云上的数据流处理，该框架可持续监控资源利用率，并实时管理与 调整这些资源，以满足SLA，同时避免过度配置资源。它根据用户指定的规 则和指标（如增加或减少虚拟机的内存容量、核心数量和磁盘资源（纵向伸 缩））自动控制主机状态。

在[67]中提出了用于弹性数据流处理的自动伸缩技术。自动伸缩技术 解决了查找正确的时间进行资源收缩或扩展的问题，这是弹性系统的主要挑 战之一。自动扩展技术的目标是最大化系统利用率，同时保证低端到端延迟。

胡等人在[68]中提出了一种多步超前负荷预测方法，用于在云计算中的 数据流处理场景下按需调整资源数量。由于云计算具有复杂且动态的特性， 该方法基于统计学习技术和支持向量回归（SVR），提供了适应云计算环境 的高效解决方案。

在[69]中提出了一种自主云爆发方法，用于优化近实时、数据密集型、 独立计算的有序吞吐量。他们提出了三种调度启发式方法作为自主云爆发方 法的一部分。这些调度启发式方法能够在工作负载特征变化、带宽波动以及 可用资源变动的情况下优化有序吞吐量。基于工作负载特征，自主云爆发方 法可以在外部云中配置适当数量的资源，因为它能够确定在外部分云中可被 最优利用的实例数量。使用云爆发的主要优势是能够通过多个云高效执行在 线数据流工作负载。

在[70]中提出了一种用于数据流处理的弹性自动并行化解决方案。该方 案通过动态调整用于处理的通道数量，在实现高吞吐量的同时避免了资源的 不必要浪费。该自动并行化解决方案使用控制算法，该算法基于其维护的本 地运行时指标，周期性地重新评估应使用的通道数量。

在[71]中提出了云MapReduce（CMR）。CMR克服了传统 MapReduce的局限性，支持数据流处理。此外，CMR在Map和Reduce阶 段之间使用流水线。这种流水线化的MapReduce方法提高了Map和 Reduce阶段之间的并行性。同时，CMR充分利用了云计算的优势，通过 Amazon Cloud的竞价实例支持灵活定价。

在 [51, 53, 71]个MapReduce框架的扩展框架中被提出。表4 对M3、 映射更新和CMR框架进行了比较，这三个框架将MapReduce框架扩展以支 持流处理。此外，CMR利用了云计算的优势。

提出了一种信息流控制模型，用于在云上安全高效地处理数据流。此外， 该模型利用操作符树 [43] 共享对多个查询的处理。此模型的主要优势在于 能够保护信息，防止未经授权的泄露和篡改。

框架	支持 数据流 处理	基本 环境	基于云	Map和Reduce阶段之间的连接 和Reduce阶段
M3	Yes	MapReduce 框架	非云 基于	通过远程方法调用
映射更新	Yes	MapReduce 框架	非云 基于	通过确定性 打破平局的程序
CMR	Yes	MapReduce	基于云	通过流水线模型

防止在基于云计算处理数据的组织之间发生信息泄露。

除了在[72]中提出的基于云的框架外，所有上述提到的基于云的框架都 考虑了按需云资源供给。然而，信息流控制模型在安全性以及处理多个查询 方面优于其他模型，因为它是唯一一个处理这些问题的模型。

只有[17, 64, 65, 71]中的框架在云计算环境下处理了数据流的并行处 理。[5]中提出的方法是唯一基于资源供给来解决容错恢复问题的方法。 [68]中的方法是唯一基于SVR以更好地适应云计算环境的方法。此外，复 杂事件处理仅在[66]中被考虑。

5 个研究问题

基于我们对执行数据流的不同环境的综述，我们得出结论：云环境是执行数 据流的最佳环境，因为它比其他环境提供了更大的弹性和更高的性能。云计 算能够根据数据流输入速率的持续变化按需扩展或缩减处理虚拟机的数量。 它能够持续适应传入的工作负载，有效检测过载条件，并相应地扩展处理资 源（虚拟机）的数量；同时，当数据流输入速率降低时，也能缩减处理资源 （虚拟机）的数量。已有许多技术被提出，用于管理工作负载的连续性和可 变性，并根据这种可变的工作负载来配置处理虚拟机。云计算在处理资源上 实现了实时负载均衡。此外，已有大量研究探讨如何在云环境中高效地恢复 数据流处理过程中发生的故障。相比其他环境，云计算在故障恢复方面具有 额外的优势：它可以通过扩展处理资源的数量，将工作负载从损坏的虚拟机 路由到新的虚拟机。同时，多个连续查询在云计算环境中也能够被高效处理。 此外，云环境中还提出了多种并行化技术，支持数据流的并行与分布式处理。 同时，云计算为流处理提供了良好的安全性。基于以上所有原因，云环境是 执行数据流的最佳环境。

在表5中，我们展示了基于云的[4, 5, 64–71]与非基于云的[48, 50, 51, 59]执行环 境之间的比较。

环境 type	方法论	控过制载	弹性	过载 对⋯⋯的影响 data	性总能体
基于云	(1) StreamCloud 方法 横(2)向 容错展算法 (3) 自适应 资源调配 算法 (4) CMR (5) 基于CEP 资监控 (6) 多步超前 负载预测 (7) 自动扩展	数扩量展 VMs	弹性 环境	无影响 上(数据处理 pro visioned VMs)	更高 性和能更高 准确性
非云 基于	(1) M3方法 (2) DTR算法 (3) RLD算法 (4) 改进的 成对算法	Load 重新平衡	非弹性 环境	数据丢失	较低 性和能较低 准确性

6 解决方案和建议

从前面的章节可以看出，数据流的实时应答是一个非常重要的问题。现有的 系统都只是从单一角度为数据流处理提供解决方案。一些系统专注于优化技 术本身，而不考虑处理环境；另一些系统则仅关注改进处理环境。因此，我们提出了基于查询网格（QM）思想的优化的云查询网格系统，用于数据流 处理。QM方案的基本思想是基于多个查询计划进行数据流处理。我们提出 的系统解决了现有系统在单一角度改进流处理的问题，将两种改进视角结合 起来：一方面，在云环境中应用连续查询优化技术；另一方面，充分利用云 处理环境的优势，利用云计算虚拟化以弹性且可扩展的方式处理数据流。此外，该系统还应用了此前在云环境中未曾使用的连续查询优化技术，即基于 多个查询计划处理数据流，每个查询计划适用于具有相同统计特征的数据子 集，而不是使用单一查询计划基于整个数据流的平均统计特征来执行全部数 据。

我们将系统分为两个子系统，每个子系统负责一些功能。第一个子系统 是连续查询优化子系统，它是我们的离线阶段。它由两个主要模块组成：连 续查询优化器和操作符分发器。连续查询优化器负责获取一组查询计划，每 个计划对应具有不同统计特性的数据子集。而操作符分发器则负责生成适用 于连续查询优化器生成的所有查询计划的物理计划。第二个子系统是基于云 的流执行子系统，它是我们的在线阶段。它由四个主要模块组成（输入管理 器、执行机器、观察器和全局管理器）。输入管理器负责管理输入元组，并 为每个元组分配合适的计划。执行机器根据分配的计划执行每个元组。观察 器负责检测过载条件。全局管理器负责在出现过载条件时进行所需的虚拟机 资源调配（图 1）。

7 未来研究方向

文献中大多数关于数据流处理的研究都集中在通过提出新的查询优化技术来 提高性能，而不关注处理环境，或仅改进处理环境。然而，数据流处理面临 许多挑战，例如执行时间、内存使用和在线开销。仅从单一改进视角出发无 法有效应对这些挑战。

因此，未来的改进应从两个方面进行。为了实现数据流的实时处理，需 要进一步研究并提出混合技术。这些技术应重点关注这两个方面的改进。同 时，数据流应在弹性环境中进行处理，以适应数据流随时间变化的特性。这样，我们才能为连续查询获得实时且更准确的结果。

8 结论

在处理数据流时，由于连续查询需要实时应答，出现了许多研究挑战性问题。 其中，提供实时应答的能力是数据流处理中的一个重要考虑因素，因为数据 流具有易变性。此外，结果准确性与减少数据丢失也是重要问题。近年来的 许多研究致力于提供框架并提出新的数据流处理技术。同时，也提出了不同 的执行环境用于执行连续查询。本文综述了近年来关于数据流处理和连续查 询优化的算法，介绍了高效处理多个连续查询的技术，并展示了不同的数据 流执行环境。我们总结了关于并行与分布式处理数据流的最新工作，以及基 于云的流处理的新技术。基于数据流的研究挑战，我们提出将基于云计算的 连续查询优化系统作为未来的工作方向。该系统将为连续查询提供实时答案， 并根据数据流输入速率实现云资源的弹性扩展。