第6期 王春凯，等：易变数据流的系统资源配置方法 ·1279· 处理具有较高的吞吐率和较低的处理延迟。这往 拓扑的策略和基于流量的动态调度策略设计了两 往需要用户预先设置相关的系统参数，如查询算 个调度算法，以降低元组处理的延迟时间和减少 子的并行度、查询进程的内存使用率等。然而， 多个拓扑节点间的传输流量。然而，Aeolus和 由于数据流的易变性和查询任务的不同，为确保 DRS需要明确每个算子的具体处理时间，并且仅 实时处理查询请求的同时尽量减少资源使用情况 用于固定的查询应用场景。文献[11]仅考虑传输 是一个非常有挑战性的问题。接下来举例说明该 延迟，而未关注资源使用的情况，并且不能对算 问题的普遍性。 子的并行度做动态调整。 我们以交通监控系统实时分析路况为例，使 2)机器学习技术。文献[12]提出了一种基于 用流处理系统Storm和轨迹数据集GeoLife实 混合密度网络)的模型来评估数据流处理任务 现如下查询任务。查询包含一个映射处理逻辑， 的资源使用情况。该模型可帮助用户判断是否向 用于接收由GPS设备采集的轨迹数据，并通过函 流处理系统提交新的查询任务。ALOJA项目 数映射找到使用该GPS设备的对象所在的道路 针对Hadoop1的执行情况开发了开源平台用于 信息。此外，包括一个测速处理逻辑接收来自映 预测查询任务的执行时间和异常监控。ALOJA 射处理逻辑发送的数据，并实时计算出不同道路 是基于ALOJA-MLI设计的框架，ALOJA-ML利 上的各GPS设备对象的平均行驶速度。 用机器学习技术分析了运行在Hadoop上的不同 然而，配置查询任务的参数不能动态感知数 查询任务的基准性能数据，并以此支持查询任务 据流的变化，导致了查询延迟的增加和系统资源 的性能调优。Jamshidi等设计了一种自动优化 的浪费。为应对此问题，文献[6-刀已进行了相关 流处理系统参数配置的贝叶斯优化算法BO4- 研究。但是，文献「6]需要重启查询任务，数据阻 CO。以MySQL和Postgres为实验平台，Otter-. 塞和查询延迟的问题较为突出；文献[7]通过保 Tunet81利用经验数据的监督学习方法和新搜集 存状态信息避免了查询任务的重启操作。然而， 信息的非监督学习方法，针对不同查询请求选择 针对流速频繁改变的易变数据流，文献[6-7]均会 出对系统性能影响最大的参数，并通过历史查询 导致系统延迟的缓慢增加，以至于超过用户自定 任务对新的查询任务进行预测，利用深度学习框 义的查询延迟阈值。为此，本文提出了应对易变 架TensorFlow9向用户推荐最佳参数配置。然 数据流的系统资源动态配置方法OrientStream+。 而，文献[12]不能动态改变流处理系统的调度策 与文献[6-7]提出的OrientStream相比，Orient- 略和各个算子的并行度，且不可以预测系统资源 Stream㎡+可较好解决易变数据流的资源配置问题， 的使用情况。ALOJA-ML框架仅可预测Hadoop 进一步降低流处理系统的查询延迟并提高系统的 的处理平台，OtterTune系统仅可预测数据库管理 吞吐率。 系统，均不能用于数据流的查询场景。BO4C0只 针对系统资源动态配置的相关工作可总结为 能以流处理系统的历史数据作为训练集，不能对 如下3个方面： 新收集的性能数据作增量分析。 I)动态加载调度策略。Aeolus⑧是柏林洪堡 3)针对关系查询系统的资源预测。正如我们 大学和惠普实验室联合研发的Storm优化器，用 所知，关系查询系统往往具有类SQL的查询接 于动态设置算子的并行度和节点内部数据的批量 口。因此，有些研究也致力于检测SQL查询的资 大小。Aeolus定义了处理单条元组所需时间的代 源消耗。针对微软的SOL Server数据库的不同杳 价模型，其中包括元组的传输时间、等待时间、计 询请求，Li等2o设计了两种特征抽取的机制用于 划处理时间和实际处理时间。依据该模型，针对 预测SQL查询的资源消耗情况。两种特征包括 不同的查询请求和数据流特征（如数据流速、数 粗粒度的全局特征和细粒度的算子特征。Ak- 据分布情况等)，Aeolus可计算出算子并行度和数 dere等2u为预测不同查询计划的查询性能，构建 据批量传输大小的最佳配置样式。为避免资源浪 了3种层次模型：查询计划层模型、算子层模型 费或无法实时获取正确的查询结果，FU等9设计 和针对嵌套查询的混合模型。然而，模型2仅 了基于云环境的大规模数据流管理系统的动态资 考虑了静态特征的选择过程，不能对系统进行动 源调度器。该调度器借助开放排队网络理论 态监控，并且没有考虑位于关系查询系统下面的 来度量已使用资源和查询响应时间的关系、制定 数据处理系统的有关特征。 最佳资源配置方案以及使用最小开销测量系统的 本文提出的OrientStream+框架不同于以上工 负载等。Aniello等针对Storm平台，利用基于 作。OrientStream+构建了以延迟阈值为间隔片段处理具有较高的吞吐率和较低的处理延迟。这往 往需要用户预先设置相关的系统参数，如查询算 子的并行度、查询进程的内存使用率等。然而， 由于数据流的易变性和查询任务的不同，为确保 实时处理查询请求的同时尽量减少资源使用情况 是一个非常有挑战性的问题。接下来举例说明该 问题的普遍性。 我们以交通监控系统实时分析路况为例，使 用流处理系统 Storm[4] 和轨迹数据集 GeoLife[5] 实 现如下查询任务。查询包含一个映射处理逻辑， 用于接收由 GPS 设备采集的轨迹数据，并通过函 数映射找到使用该 GPS 设备的对象所在的道路 信息。此外，包括一个测速处理逻辑接收来自映 射处理逻辑发送的数据，并实时计算出不同道路 上的各 GPS 设备对象的平均行驶速度。 然而，配置查询任务的参数不能动态感知数 据流的变化，导致了查询延迟的增加和系统资源 的浪费。为应对此问题，文献 [6-7] 已进行了相关 研究。但是，文献 [6] 需要重启查询任务，数据阻 塞和查询延迟的问题较为突出；文献 [7] 通过保 存状态信息避免了查询任务的重启操作。然而， 针对流速频繁改变的易变数据流，文献 [6-7] 均会 导致系统延迟的缓慢增加，以至于超过用户自定 义的查询延迟阈值。为此，本文提出了应对易变 数据流的系统资源动态配置方法 OrientStream+。 与文献 [6-7] 提出的 OrientStream 相比，Orient￾Stream+可较好解决易变数据流的资源配置问题， 进一步降低流处理系统的查询延迟并提高系统的 吞吐率。 针对系统资源动态配置的相关工作可总结为 如下 3 个方面： 1) 动态加载调度策略。Aeolus[8] 是柏林洪堡 大学和惠普实验室联合研发的 Storm 优化器，用 于动态设置算子的并行度和节点内部数据的批量 大小。Aeolus 定义了处理单条元组所需时间的代 价模型，其中包括元组的传输时间、等待时间、计 划处理时间和实际处理时间。依据该模型，针对 不同的查询请求和数据流特征 (如数据流速、数 据分布情况等)，Aeolus 可计算出算子并行度和数 据批量传输大小的最佳配置样式。为避免资源浪 费或无法实时获取正确的查询结果，FU 等 [9] 设计 了基于云环境的大规模数据流管理系统的动态资 源调度器。该调度器借助开放排队网络[10] 理论 来度量已使用资源和查询响应时间的关系、制定 最佳资源配置方案以及使用最小开销测量系统的 负载等。Aniello 等 [11] 针对 Storm 平台，利用基于 拓扑的策略和基于流量的动态调度策略设计了两 个调度算法，以降低元组处理的延迟时间和减少 多个拓扑节点间的传输流量。然而，Aeolus 和 DRS 需要明确每个算子的具体处理时间，并且仅 用于固定的查询应用场景。文献 [11] 仅考虑传输 延迟，而未关注资源使用的情况，并且不能对算 子的并行度做动态调整。 2) 机器学习技术。文献 [12] 提出了一种基于 混合密度网络[13] 的模型来评估数据流处理任务 的资源使用情况。该模型可帮助用户判断是否向 流处理系统提交新的查询任务。ALOJA 项目[14] 针对 Hadoop[15] 的执行情况开发了开源平台用于 预测查询任务的执行时间和异常监控。ALOJA 是基于 ALOJA-ML[16] 设计的框架，ALOJA-ML 利 用机器学习技术分析了运行在 Hadoop 上的不同 查询任务的基准性能数据，并以此支持查询任务 的性能调优。Jamshidi 等 [17] 设计了一种自动优化 流处理系统参数配置的贝叶斯优化算法 BO4- CO。以 MySQL 和 Postgres 为实验平台，Otter￾Tune[18] 利用经验数据的监督学习方法和新搜集 信息的非监督学习方法，针对不同查询请求选择 出对系统性能影响最大的参数，并通过历史查询 任务对新的查询任务进行预测，利用深度学习框 架 TensorFlow[19] 向用户推荐最佳参数配置。然 而，文献 [12] 不能动态改变流处理系统的调度策 略和各个算子的并行度，且不可以预测系统资源 的使用情况。ALOJA-ML 框架仅可预测 Hadoop 的处理平台，OtterTune 系统仅可预测数据库管理 系统，均不能用于数据流的查询场景。BO4CO 只 能以流处理系统的历史数据作为训练集，不能对 新收集的性能数据作增量分析。 3) 针对关系查询系统的资源预测。正如我们 所知，关系查询系统往往具有类 SQL 的查询接 口。因此，有些研究也致力于检测 SQL 查询的资 源消耗。针对微软的 SQL Server 数据库的不同查 询请求，Li 等 [20] 设计了两种特征抽取的机制用于 预测 SQL 查询的资源消耗情况。两种特征包括 粗粒度的全局特征和细粒度的算子特征。Ak￾dere 等 [21] 为预测不同查询计划的查询性能，构建 了 3 种层次模型：查询计划层模型、算子层模型 和针对嵌套查询的混合模型。然而，模型[20-21] 仅 考虑了静态特征的选择过程，不能对系统进行动 态监控，并且没有考虑位于关系查询系统下面的 数据处理系统的有关特征。 本文提出的 OrientStream+框架不同于以上工 作。OrientStream+构建了以延迟阈值为间隔片段 第 6 期 王春凯，等：易变数据流的系统资源配置方法 ·1279·