Flink基础（七）：状态的使用

Flink官网说，Flink是数据流上的有状态计算。

那么问题来了，何为状态？

比如Word Count 程序来说，需要不断的对word进行计数，来一个计数一次，那么这个计数的值（count）我们就需要一直在处理过程中存着，那么，这个count就是一个状态。即在数据处理过程中过程中存储数据。
总结下来说，当任务运行过程中突然挂了，如果是批任务可以重新跑一遍；但如果是流任务，是不是需要知道数据消费到哪儿了，任务重启的时候需要冲哪儿开始消费，这时就需要状态了。state 中存储着每条数据消费后数据的消费点，当 Job 因为某种错误或者其他原因导致重启时，就能够从 checkpoint（定时将 state 做一个全局快照，在 Flink 中，为了能够让 Job 在运行的过程中保证容错性，才会对这些 state 做一个快照，后面会讲） 中的 state 数据进行恢复。
状态是跟当前任务绑定的，不能跨任务去使用状态。

Flink 中有两种基本的状态：Keyed State 和 Operator State。

Keyed State

Keyed State 通常和 key 相关，仅可使用在 KeyedStream 的方法和算子中。

Operator State

对于 Operator State (或者 non-keyed state) 来说，每个 operator state 和一个并发实例进行绑定。 Kafka Connector 是 Flink 中使用 operator state 的一个很好的示例。 每个 Kafka 消费者的并发在 Operator State 中维护一个 topic partition 到 offset 的映射关系。

Operator State 在 Flink 作业的并发改变后，会重新分发状态，分发的策略和 Keyed State 不一样。

Raw State 与 Managed State

Keyed State 和 Operator State 分别有两种存在形式：managed（原始状态） and raw（托管状态）。

Managed State 由 Flink 运行时控制的数据结构表示，比如内部的 hash table 或者 RocksDB。 比如 “ValueState”, “ListState” 等。Flink runtime 会对这些状态进行编码并写入 checkpoint。

Raw State 则保存在算子自己的数据结构中。checkpoint 的时候，Flink 并不知晓具体的内容，仅仅写入一串字节序列到 checkpoint。

所有 datastream 的 function 都可以使用 managed state, 但是 raw state 则只能在实现算子的时候使用。 由于 Flink 可以在修改并发时更好的分发状态数据，并且能够更好的管理内存，因此建议使用 managed state（而不是 raw state）。

注意： 如果你的 managed state 需要定制化的序列化逻辑， 为了后续的兼容性请参考 相应指南，Flink 的默认序列化器不需要用户做特殊的处理。