1.state
1.1.状态管理:
flink有两种状态:keyedState和operatorState
| state | keyedState | operatorState |
|---|---|---|
| 支持的算子 | keyedState只能用在keyedStream的算子中每个key对应一个state | 可以用于所有算子常用于source,例如:FlinkKafkaConsumer |
| key和state | 一个operator实例处理多个key,访问相应的多个state并发改变,State随着key在实例中迁移 | 一个operator实例对应一个state并发改变时,有多种重新分配方式可选:1.均匀分配 ;2.合并后每个得到全量 |
| 接口实现 | 通过runcontext访问:RichFunction | 实现CheckPointed接口或ListCheckPointed接口 |
| 支持的数据结构 | valueState,ListState,ReducingState,AggregatingState,MapState | ListState |
KeyedState 和 OperatorState 都有两种形式存在:
1、原始状态 RawState
原始状态,是由用户自行管理状态具体的数据结构,框架在做 checkpoint 的时候,使用 byte[]来读写内容,对其内部数据结构一无所知
2、托管状态 ManagedState
托管状态是由 Flink 框架管理的状态
通常,在 DataStream 上的状态,推荐使用托管的状态,当实现一个用户自定义的 Operator的时候,会使用到原始状态
| RawState | ManagedState | |
|---|---|---|
| 状态管理方式 | 用户自己管理 需要自己序列化 | FlinkRuntime管理 自动存储,自动恢复 内存管理上有优化 |
| 状态数据结构 | 字节数组:byte[] | 已知的数据结构:value,map,list… |
| 推荐使用场景 | 自定义operator时可使用 | 大多数情况下均可使用 |

本文深入探讨了Flink中的状态管理机制,包括keyedState和operatorState的区别与应用,介绍了托管状态与原始状态的实现方式及优缺点,适用于自定义operator的场景。
862

被折叠的 条评论
为什么被折叠?



