Keyed State与Operator State区别

Keyed State与Operator State在Flink状态管理中各自扮演着不同的角色，具有显著的区别。

首先，Keyed State是与特定键(key)相关联的状态，它是基于数据流的键进行访问和更新的。在Keyed Stream中，状态的访问和更新都是基于数据的键进行的。这种状态通常用于需要对具有相同键的数据进行聚合、关联或查询的操作。例如，使用KeyBy操作对流进行分区后，可以使用Keyed State来存储和操作每个键的聚合结果。Keyed State由Flink自动管理和分区，确保每个键的状态在任务执行过程中正确维护和更新。从底层实现上看，Keyed State类似于一个分布式的映射(map)数据结构，所有的状态都以键值对(key-value)的形式保存，并根据键进行组织。

另一方面，Operator State是与算子(Operator)相关联的状态，它与算子的实例相关联，并在算子的整个生命周期中保持不变。它适用于存储算子内部的中间结果和状态信息。Operator State的作用范围被限定为当前算子任务，与数据的key无关。因此，不同key的数据只要被分发到同一个并行子任务，就会访问到同一个Operator State。Operator State的实际应用场景不如Keyed State多，一般用在Source或Sink等与外部系统连接的算子上，或者完全没有key定义的场景。比如，在Flink的Kafka连接器中，就使用了算子状态。当给Source算子设置并行度后，Kafka消费者的每一个并行实例都会为对应的主题(topic)分区维护一个偏移量，作为算子状态保存起来。

总的来说，Keyed State和Operator State在Flink状态管理中各自扮演不同的角色。Keyed State主要用于基于键的聚合、关联或查询操作，而Operator State则更多地用于存储算子内部的中间结果和状态信息。在选择使用哪种状态时，需要根据具体的业务场景和需求进行决策。

Keyed State

• 数据分区：Keyed State 是与特定的键（Key）相关联的状态，它是分区的。在 Flink 中，当你使用 keyBy() 方法对数据流进行分区时，每个键都会维护自己的状态。
• 作用：Keyed State 通常用于每个键的聚合操作，如计算每个用户的点击总数。
• 访问：状态的访问和更新是基于每个键的。
• 生命周期：Keyed State 的生命周期通常与键相关，如果一个键不再有数据流入，其状态可能会被清理，这取决于配置的时间限制或状态清理策略。
• 使用场景：适合于需要按照不同分组键进行独立处理的场景，如按键聚合、窗口计算等。

Operator State

• 全局性：Operator State 是与操作符（Operator）实例相关联的状态，它不是分区的，是全局的。在 Flink 的每个并行实例中，Operator State 都是独立的。
• 作用：Operator State 用于全局聚合操作，如计算所有用户的总点击次数（如果数据流被分区，这将涉及到在不同分区间的状态汇总）。
• 访问：状态的访问和更新是全局的，与键无关。
• 生命周期：Operator State 的生命周期与操作符实例的生命周期相关，通常在操作符实例被取消或重启时会丢失，除非进行了持久化处理。
• 使用场景：适合于需要全局状态信息的场景，如全局统计、累加器等。

其他区别

• 状态大小：Keyed State 的大小可能会非常大，因为它为每个键维护状态。而 Operator State 通常较小，因为它是全局的，且每个操作符实例只有一个副本。
• 状态后端：Flink 中的状态后端（State Backend）对这两种状态的处理方式可能不同，因为它们对性能和存储的要求不同。
• 容错：Flink 使用 Checkpoint 机制来进行状态的持久化和容错。Keyed State 和 Operator State 都需要考虑在 Checkpoint 中的序列化和反序列化。

在选择使用哪种状态时，需要根据具体的业务逻辑和性能要求来决定。通常，Keyed State 更适用于按键处理的场景，而 Operator State 更适合全局操作。