Page 272 - 《软件学报》2025年第7期

秦政 等: 面向 Apache Flink 流式分析应用的高吞吐优化技术 3193

Flink 上的数据流往往使用 KeyBy 进行数据交换, 同时将任务并行化, 分配负载到多个执行节点上并行处理.
当前, KeyBy 使用受到广泛验证的 murmurHash [44] 作为分配依据, 将数据分配到键值组和对应的算子子任务上.
在基于 Flink 的 KeyBy 算子负载均衡情况测试实验中, 消息的主键为自增的数字 ID, 并行度为 60, 总数据量
为 1 百万条. 理想情况下, 60 个算子的子任务都应处理约 16 666 条数据, 即 1.67% 的负载. 然而, 实验结果如表 3
所示, 13.3% 的子任务承担 2.17% 以上的负载, 而超过一半的子任务仅承受不足 1.57% 的负载, 最高负载节点甚至
比最低负载节点承受额外 111.0% 的负载, 这使得最高负载节点相比负载均衡情况下计算时间增加 60.8%, 导致系
统整体吞吐率受限和轻负载节点的资源浪费.

表 3 Flink KeyBy 算子负载均衡测试

负载百分比 (%) 1.27 ⩽ x ⩽ 1.57 1.57 < x ⩽ 1.87 1.87 < x ⩽ 2.17 2.17 < x ⩽ 2.47 2.47 < x ⩽ 2.77
子任务数量 33 19 0 4 4
所占资源比例 (%) 55 61.7 0 6.7 6.7

为了衡量负载均衡的状况, 本文定义负载均衡度和超额计算时间两个指标及其计算公式如下:

最低负载节点处理数据量
负载均衡度 = (1)
最高负载节点处理数据量

最高负载节点处理数据流−平均负载
额外计算时间 = (2)
平均负载
其中, 负载均衡度在 [0, 1] 之间, 越接近 0, 表明系统负载越不均衡; 越接近 1, 表明系统负载均衡状况越好. 额外计
算时间反映因系统的负载不均衡导致的最高负载节点的额外计算时间, 也反映系统整体吞吐率的受限情况.
如图 7 KeyBy 算子负载均衡测试所示, 随着主键数量增大, 系统负载趋向于均衡, 但即使全量数据均有独立
Key 时, 负载均衡度也仅有 0.47. 节点间负载不均将造成计算资源的不充分利用, 造成系统吞吐下降. 另一方面, 由
于负载不均, 子任务间计算进度将出现差异, 若后续计算流程中包含跨任务间聚合等计算时, 会造成额外的等待
时延.

0.6

负载均衡度 0.4

0.2

0
500 1 000 10 000 100 000 1 000 000
图 7 KeyBy 算子负载均衡测试

3.4 跨节点数据交换
流式分析结果往往与数据主键相关联, Flink 使用 KeyBy 进行基于键值的数据交换, 从而将同一主键的数据
聚合到同一计算节点上进行分析汇总. 这种全量的数据交换可能使得网络带宽成为系统性能瓶颈, 并增加数据的
处理延迟, 降低系统的吞吐率.
由于节点间的数据交换带来的性能开销很难直接度量, 本文通过测试 Flink 系统在默认配置下, KeyBy 会造
成的节点间交换数据量, 以此来帮助判断 KeyBy 数据交换会给流式处理带来的额外性能开销. 同样的, 本实验中
采取键值均匀分布的数据执行第 3.2 节中的计算任务, 通过识别经过 KeyBy 后数据是否仍在原有节点来进行数据
交换量计算.
如表 4 KeyBy 节点间数据交换量所示, 实验发现当前 KeyBy 算子在进行基于键值的数据交换时, 需要高比例