Flink流分区与并行度的关联及相关理论验证咨询

以下是针对你提出的6个观点的逐一验证与补充：

• 观点1：正确。并行度指的是Flink作业中算子的并行实例数量，这些实例可以是同一JVM进程内的线程，也可以是分布式集群中不同机器节点上的进程/线程，它们是真正执行数据处理的“处理单元”。

• 观点2：不完全准确。Flink的默认分区策略分两种情况：

  • 当上下游算子属于one-to-one算子链（比如连续的map、filter等无数据重分配的算子），默认使用ForwardPartitioner，即上游实例的元素直接转发给下游对应的并行实例，不会做轮询分发；
  • 只有当上下游算子并行度不一致（需要数据重分配）时，非键控的默认分区策略才是轮询（RoundRobinPartitioner）。

• 观点3：正确。一旦开发者显式指定了分区策略（比如keyBy、partitionCustom等），Flink会完全遵循该策略进行数据分区，不再使用默认的分区逻辑。例如keyBy会基于键的哈希值进行分区，将相同键的元素路由到同一下游实例。

• 观点4：正确。当并行度设为1时，所有数据都会由同一个处理单元处理，任何分区策略都不会改变数据的处理路径，因此不会影响处理速度。此时使用keyBy的核心价值就是进入键控上下文，从而可以使用键控状态、键控窗口、键控定时器等只有在键控场景下才支持的功能。

• 观点5：正确。keyBy仅保证相同键的元素一定会被同一个处理单元处理，但同一个处理单元可以负责多个不同键的元素处理，且每个键的状态（如键控状态）是完全独立的，互相不会干扰。

• 观点6：基本正确。如果分区策略最多只能生成2个分区（比如自定义分区器固定将数据分到2个组），而算子并行度设为3，那么第三个并行实例会一直处于空闲状态，不会处理任何数据，这种设置会浪费集群资源，没有实际意义。合理的做法是将并行度调整为与分区数匹配，或者修改分区策略以适配并行度。

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