【RocksDB 内核机制】生产嵌入对照：Flink · TiKV · Kafka Streams
内容提要
本文讨论了Flink中EmbeddedRocksDBStateBackend的机制，重点在于KeyGroup前缀、增量checkpoint的实现及其与RocksDB的关系。增量checkpoint依赖于不可变SST文件和MANIFEST，以确保数据一致性。文章还比较了Flink、TiKV和Kafka Streams在状态管理和容错机制上的差异，强调了设计与参数调优的重要性。
关键要点
-
EmbeddedRocksDBStateBackend 为每个 subtask 打开独立 RocksDB，每种 registered state 对应一个 Column Family。
-
KeyGroup 前缀决定 key 排序区间，增量 checkpoint 上传自上次 completed checkpoint 以来新增的 SST。
-
增量 checkpoint 依赖于不可变的 SST 文件和 MANIFEST，以确保数据一致性。
-
Flink 的 KeyGroup、Namespace 和 UserKey 在 RocksDB InternalKey 排序中具有重要意义。
-
Rescale 时必须保留 KeyGroup 前缀，以确保状态的正确迁移。
-
TiKV、Kafka Streams 和 Flink 在状态管理和容错机制上存在差异，特别是在 DB 实例边界和 CF 划分方面。
-
增量 checkpoint 的实现依赖于 Flush 操作和 Checkpoint API 的硬链接机制。
-
Compaction 会影响 Flink 的 shared state 引用链，导致 checkpoint 争抢磁盘 I/O。
延伸解读
增量Checkpoint的关键机制
增量Checkpoint依赖于不可变的SST文件和MANIFEST，以确保数据一致性。Flush操作是生成不可变SST的前提，只有在Flush后，Checkpoint才能正确上传增量数据。这一机制对于维护系统的稳定性和性能至关重要，尤其是在高负载情况下。
Flink与其他系统的比较
Flink、TiKV和Kafka Streams在状态管理和容错机制上存在显著差异。Flink采用每个subtask独立的RocksDB实例，而TiKV和Kafka Streams则在DB实例边界和CF划分上有所不同。这种设计差异影响了系统的扩展性和容错能力，开发者在选择时需考虑具体应用场景。
KeyGroup前缀的重要性
KeyGroup前缀在Flink的RocksDB内部排序中起着关键作用。它决定了key的排序区间，并在Rescale过程中确保状态的正确迁移。理解这一机制有助于优化状态管理和提高系统的性能，特别是在处理大规模数据时。
延伸问答
Flink中的EmbeddedRocksDBStateBackend是如何工作的？
EmbeddedRocksDBStateBackend为每个subtask打开独立的RocksDB，每种注册状态对应一个Column Family，使用KeyGroup前缀决定key的排序区间。
增量checkpoint在Flink中是如何实现的？
增量checkpoint依赖于不可变的SST文件和MANIFEST，上传自上次完成的checkpoint以来新增的SST，并通过Flush操作确保数据一致性。
Flink、TiKV和Kafka Streams在状态管理上有什么不同？
Flink每个subtask对应一个独立的DB实例，而TiKV和Kafka Streams则在不同的边界和CF划分上存在差异，特别是在容错日志的处理上。
KeyGroup前缀在Flink中有什么重要性？
KeyGroup前缀决定了key的排序区间，在Rescale时必须保留该前缀，以确保状态的正确迁移。
Compaction如何影响Flink的shared state引用链？
Compaction会合并SST文件，影响Flink的shared state引用链，导致checkpoint争抢磁盘I/O。
在Flink中，如何确保增量checkpoint的数据一致性？
通过Flush操作生成不可变的SST文件，并在MANIFEST中记录新文件，确保数据在checkpoint过程中的一致性。
