Flink de / serialise运营商的频率是多少？每次获取/更新或基于检查点？州后端会有所作为吗？
我怀疑，对于每个密钥具有不同密钥（数百万）和每秒数千个事件的密钥流，de /序列化可能是一个大问题 . 我对吗？
你的假设是正确的 . 这取决于州后端 .
在JVM堆上存储状态的后端（ MemoryStateBackend 和 FSStateBackend ）不会为常规读/写访问序列化状态，而是将其作为堆上的对象保留 . 虽然这会导致非常快速的访问，但您显然必然会遇到JVM堆的大小，并且可能还会遇到垃圾回收问题 . 采用检查点时，对象将被序列化并保留，以便在发生故障时进行恢复 .
MemoryStateBackend
FSStateBackend
相比之下， RocksDBStateBackend 将所有状态存储为嵌入的RocksDB实例中的字节数组 . 因此，它为每次读/写访问取消/序列化密钥的状态 . 您可以通过选择适当的状态原语（即 ValueState ， ListState ， MapState 等）来控制"how much"状态被序列化 .
RocksDBStateBackend
ValueState
ListState
MapState
例如， ValueState 始终作为整体进行de / serialized，而 MapState.get(key) 仅序列化密钥（用于查找）并反序列化密钥的返回值 . 因此，您应该使用 MapState<String, String> 而不是 ValueState<HashMap<String, String>> . 类似的考虑适用于其他状态原语 .
MapState.get(key)
MapState<String, String>
ValueState<HashMap<String, String>>
RocksDBStateBackend 通过将文件复制到持久文件系统来检查其状态 . 因此，在采用检查点时不会涉及额外的序列化 .
1 回答
你的假设是正确的 . 这取决于州后端 .
在JVM堆上存储状态的后端（
MemoryStateBackend和FSStateBackend）不会为常规读/写访问序列化状态，而是将其作为堆上的对象保留 . 虽然这会导致非常快速的访问，但您显然必然会遇到JVM堆的大小，并且可能还会遇到垃圾回收问题 . 采用检查点时，对象将被序列化并保留，以便在发生故障时进行恢复 .相比之下，
RocksDBStateBackend将所有状态存储为嵌入的RocksDB实例中的字节数组 . 因此，它为每次读/写访问取消/序列化密钥的状态 . 您可以通过选择适当的状态原语（即ValueState，ListState，MapState等）来控制"how much"状态被序列化 .例如，
ValueState始终作为整体进行de / serialized，而MapState.get(key)仅序列化密钥（用于查找）并反序列化密钥的返回值 . 因此，您应该使用MapState<String, String>而不是ValueState<HashMap<String, String>>. 类似的考虑适用于其他状态原语 .RocksDBStateBackend通过将文件复制到持久文件系统来检查其状态 . 因此，在采用检查点时不会涉及额外的序列化 .