如题,我生产中目前一直都是使用的FileStateBackend,然后使用一个对象存储服务作为后端。
按照我的理解,这种方式下,状态的操作性能很高,都是在内存内部,只有检查点时候才会输出到对象存储中。但是,不支持增量检查点。
RocksDB支持增量检查点,但是缺点是每个状态的操作都是需要序列化/反序列化,至于是文件还是内存操作可能还和rocksdb的块大小,多久刷新等有关。
不过我现在在想,既然我的任务的状态当前使用内存存储,也就是内存存储是能够容纳我的全状态的。
那么是否我从FileStateBackend切换到RocksDB其实性能也不会降低很多呢? 就是牺牲很少性能,换来增量检查点。
此外,还有个点。RocksDB的增量检查点在每次检查点时候,输出到对象存储的部分也是增量?还是全量。
只是rocksdb自身使用增量状态,然后检查点存储的时候是全量到对象存储吗?
还是说,对象存储中存储的ckpt-1,ckpt-2,ckpt-3等也是增量的,即ckpt-3可能依赖ckpt-2等这样。*来自志愿者整理的flink邮件归档
是否我从FileStateBackend切换到RocksDB其实性能也不会降低很多呢?
这个涉及到RocksDB这种LSM架构的DB读写路径了,即使逻辑数据量可以全部存储在内存中,由于RocksDB的write buffer默认会存储相同key的不同value,而且checkpoint时候仍然会触发flush,很难避免数据落盘,数据落盘之后的读路径肯定没有Flink的内存state backend性能好,二者性能还是有些差异的,不过实际生产中可能不需要 FsStateBackend 那么高的性能。
RocksDB本地的checkpoint其实是全量的,只是上传远程存储的时候是增量的,ckpt-3有可能会依赖ckpt-2中的部分文件。*来自志愿者整理的FLINK邮件归档
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。