Flink中keyBy逻辑分区含义及与partitionCustom物理分区的差异疑问

一、keyBy的“逻辑分区”与shuffle行为 #

官方文档称keyBy为“逻辑分区”，是从语义层面的定义：它核心是给数据流打上“按key分组”的逻辑标记，告知Flink后续计算需基于key做隔离（比如状态管理）；而物理层面，当上下游算子并行度不同时（比如你给出的Source(并行度2) -> keyBy(_.id) -> Process(并行度3)示例），一定会触发shuffle——Source的subtask会根据_id的哈希值，将数据路由到Process对应的subtask，且保证相同_id的记录必然进入同一个Process subtask。

之所以用“逻辑分区”表述，是因为keyBy的重点并非物理路由本身，而是它定义了“哪些数据属于同一计算单元”的逻辑规则，物理哈希分区只是实现这个逻辑的手段。

二、keyBy与partitionCustom的核心差异 #

两者虽都会触发shuffle，但定位和能力完全不同：

• 语义目标不同
  • keyBy是为了按key做逻辑分组，服务于后续的有状态计算（比如聚合、KeyedState使用），核心是保证同key数据聚合并隔离。
  • partitionCustom是纯粹的物理路由控制，仅负责按用户自定义规则把数据发到指定subtask，没有“分组”语义，也不关联任何状态隔离逻辑。
• 路由约束不同
  • keyBy有硬约束：同key的数据必须进入同一个subtask，否则后续的keyed状态会出现一致性问题。
  • partitionCustom无强制约束：用户可自定义任意路由逻辑，甚至可以把同key的数据分到不同subtask，完全由路由函数决定。
• 后续算子能力不同
  • keyBy输出的是KeyedStream，后续算子可使用KeyedState、KeyedTimer等按key隔离的状态API。
  • partitionCustom输出的还是普通DataStream，后续算子只能使用全局的OperatorState，无法基于key做状态隔离。

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