Page 265 - 《软件学报》2025年第7期
P. 265

3186                                                       软件学报  2025  年第  36  卷第  7  期


                 大规模实时数据场景下, 多个分区被并行消费时, 来自这些分区的事件会发生耦合, 造成数据间额外的乱序, 带来
                 额外的等待时间或更严重的时序耦合, 导致系统的吞吐率下降. 当节点数增加时, 乱序数据的耦合也会增加, 造成
                 Flink  的可扩展性下降.
                    (2) 节点负载不均: Flink  需要将计算负载进行划分以在多个计算节点并行计算. 当前, Flink                  使用受到广泛验
                 证的  murmurHash  作为分配依据, 将数据分配到键值组和对应的算子子任务上. 然而现有工作和实验分析表明, 负
                 载的划分和分发存在严重不均衡, 造成系统吞吐率的下降和轻负载节点上的资源浪费.
                    (3) 跨节点数据交换: 由于计算任务的算子间的数据传输使用内存传输和网络通信传输混合的模式, 且构成计
                 算任务的算子可能分布于多个节点, 随着数据量增加, 节点数量增加, 这一问题会愈发严重, 因而                           Flink  可扩展性受
                 限, 吞吐率下降.
                    针对以上    3  个导致性能瓶颈的根因, 本文设计和实现对应的优化策略.
                    (1) 键级水位线策略: 当不同数据源产生的数据具有不同的逻辑主键时, 由于网络时延地理位置等不确定因
                 素, 子任务级的水位线机制会导致不必要的时序耦合. 因此, 针对原有粗粒度的水位线机制, 本文设计键级水位线
                 机制和相应的系统算子, 从而检测并减少乱序数据比例, 提高系统吞吐率.
                    (2) 动态负载分发策略: 本文扩展数据分发算子的负载分发策略, 设计了分别适用于                        4  种不同数据分布场景的
                 数据分发新策略; 基于负载均衡状态在线监测提出运行时负载分发策略的动态调整机制, 从而实现流式处理系统
                 的自适应动态负载均衡.
                    (3) 基于键值的跨节点数据交换优化策略: 为了尽可能减少或消除跨节点的数据交换, 本文设计了                             3  种基于键
                 值的数据交换最小化策略, 减少或避免节点间的全量数据传输, 以提高吞吐率并降低传输延迟, 并实现对应的系统
                 算子.
                    本文基于    Flink  进行了上述优化策略的设计实现, 形成了原型系统              Trilink, 并通过实验验证了方法的有效性.
                 总体来说, 论文工作的贡献如下.
                    (1) 基于典型流式分析应用分析构建了通用的流式处理数据流模型, 通过分析与实验验证了导致分布式流式
                 处理系统水平可扩展性瓶颈以及吞吐率瓶颈的                3  个潜在问题;
                    (2) 从数据流处理的角度出发, 针对发现的            3  个水平扩展性问题设计了一系列优化策略, 包括: 键级水位线、
                 面向多种数据分布场景的动态负载分发和基于键值的跨节点数据交换优化, 实现时序化保证、负载均衡和数据传
                 输多维度的优化, 有效提高流式处理系统在分布式环境下的水平可扩展性;
                    (3) 基于  Flink  实现上述优化策略, 设计实现面向高吞吐的流式处理系统原型                 Trilink, 并在测试基准和真实应
                 用数据集上开展实验评估. 实验结果表明, 相较于原有                Flink, Trilink  单机吞吐率提升了  5  倍以上, 8  节点集群下水
                 平扩展加速比提升了       1.6  倍以上.

                 2   相关工作

                 2.1   流式处理系统
                    流式查询的概念最早源于          Tapestry [13] 系统, 流式处理系统历经  3  个阶段的发展   [14] . 第  1  代流式处理系统, 也被
                 称为流式数据管理系统, 由数据库系统和规则引擎组成. 用户通过定义规则中的触发条件和触发动作, 当新数据进
                 入系统时, 如果满足规则的触发条件, 触发动作会被执行以修改系统的内部状态. 典型的第                            1  代流式处理系统包
                 括  TelegraphCQ [15] 、Spade Stream Processing Engine [16] .
                    第  2  代流式处理系统已经开始专门用于处理流式数据, 也具有更直观的流式处理语义. 斯坦福大学研发的
                 STREAM [17] 在  SQL  上实现具有流式语义的    CQL (continuous query language); Aurora [18] 使用有向无环图来表示流
                 式计算过程, 图上的节点定义操作命令, 节点间的边表示数据流向和操作顺序; STREAM                        和  Aurora 都是单机系统,
                 Borealis [19] 对  Aurora 在分布式集群上扩展实现, 使其能利用集群上的多个计算节点并行计算.
                    MapReduce [20] 编程模型的出现深刻影响了大数据与分布式计算领域, 出现了第                  3  代流式处理系统, 即被广泛
   260   261   262   263   264   265   266   267   268   269   270