Flink同一未修改字段连续keyBy是否触发网络Shuffle？并行度为2场景

首先给出明确结论：(2)处的keyBy("key")仍然会产生网络Shuffle，不会自动采用Forward策略来避免通信开销，具体原因如下：

• 1. keyBy()的本质是强制重分区 #

Flink的keyBy()算子核心逻辑是根据key的哈希值，将数据分配到对应的keyGroup（每个并行任务负责若干个keyGroup）。它默认不会检查上游数据的分区是否已经符合当前key的分区规则——哪怕你明确知道上游process()算子没有修改key，Flink运行时也不会自动推断这一点，而是会执行完整的哈希计算和数据重分配流程，因此必然触发网络Shuffle。

• 2. Forward策略的触发条件不满足 #

Forward策略（数据直接在同一任务槽内传递，无需网络传输）的触发需要两个核心条件：

• 上下游算子的并行度完全相同；

• 上游算子的输出分区方式与下游算子的输入分区要求完全匹配。
  而keyBy()本身是显式的重分区操作，它会打破原有的分区逻辑，强制按照新的key规则重新分配数据，因此不符合Forward策略的触发条件。

• 3. 额外优化建议 #

你代码中process(func2)之后需要再次keyBy()，是因为KeyedProcessFunction（即process(func2)的实现类）的输出是普通DataStream，而非KeyedStream——即使它没有修改key，流的“keyed状态”也会丢失。如果想避免这次不必要的Shuffle，其实可以调整逻辑：如果process()的输出不需要改变key的分区逻辑，且后续的窗口操作依赖同一个key，你可以尝试将窗口逻辑整合到KeyedProcessFunction中，从而省去后续的keyBy()操作。

内容的提问来源于stack exchange，提问作者Qoobee