关于Flink DataStream keyBy方法在并行度场景下的疑问

你这里的核心误区是混淆了Flink算子并行实例的创建逻辑和客户端Function对象的生命周期，同时可能忽略了数据本身的分布情况，导致出现不符合预期的结果：

1. 为什么只看到一个哈希值？ #

首先明确：当你设置process算子并行度为3时，Flink确实会启动3个并行子任务，但你看到单一哈希值的原因可能有两个：

• 数据分布问题：如果你的NumberSource生成的元素经过_%3计算后，只得到一种key值（比如只生成3的倍数），那么所有数据都会被路由到同一个并行子任务，自然只会打印该子任务对应Function实例的哈希值。
• System.identityHashCode的验证方式问题：你在processElement中打印的哈希值，若你的本地运行环境所有并行子任务都在同一个JVM进程中，且你没有验证多个key的情况，可能误以为只有一个实例在工作。另外，Scala匿名类的序列化不会导致哈希值固化，每个并行实例的identityHashCode必然不同——只要有数据分发到对应的子任务。

2. 验证并行实例的正确方式 #

要确认3个并行实例是否都在工作，你可以做以下调整：

• 确保数据覆盖所有key：修改NumberSource生成包含0、1、2三种key的元素（比如生成0到100的连续整数）。
• 在open方法中打印实例哈希：open方法是每个并行实例启动时唯一执行的初始化方法，能准确反映实例的数量：

  override def open(parameters: Configuration): Unit = {
    println(s"Process instance hash: ${System.identityHashCode(this)}")
  }
  

• 替换打印内容：在processElement中同时打印当前key和实例哈希，这样能直观看到不同key对应不同的实例：

  out.collect(s"Key: $key, Value: $value, Instance Hash: ${System.identityHashCode(this)}")
  

3. 关于keyBy的路由逻辑 #

你的理解是对的：keyBy会将相同key的元素路由到同一个并行子任务，不同key会分配到不同的子任务（当算子并行度大于等于key的数量时）。只要数据包含多种key，3个并行实例都会被触发工作，你就能看到多个不同的哈希值。

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