为何Flink Table Store未采用Hudi或Iceberg格式存储数据？

关于Flink Table Store选择自研基于LSM树的存储组件，而非直接基于Hudi或Iceberg这类现有方案，核心原因集中在对Flink生态的深度适配、性能优化以及架构独立性上：

• Flink原生流批一体的深度绑定
  Flink Table Store从诞生起就是为了完美适配Flink的流批一体模型，自研存储可以完全贴合Flink的checkpoint机制、状态管理逻辑，实现原生级的exactly-once语义保障。如果基于Hudi/Iceberg，必然要在这些第三方存储的现有框架上做妥协，很难做到和Flink计算引擎的无缝对接，比如checkpoint和存储版本的一致性就容易出现兼容问题。

• 针对流处理场景的极致优化
  Hudi和Iceberg本质上是从批处理场景演化来的，流处理能力属于后续扩展的附加功能。而Flink Table Store的LSM树存储从底层就为流处理量身定制：内存层可以直接对接Flink状态后端，减少不必要的数据落盘开销；针对实时更新场景设计了更轻量的索引结构，避免了第三方存储中元数据管理带来的性能损耗，更适合高吞吐、低延迟的实时业务场景。

• 架构轻量化与避免依赖绑定
  基于Hudi或Iceberg会引入额外的依赖栈，这些存储本身有一套独立的元数据管理、版本控制体系，会让整个系统变得臃肿，增加部署和运维成本。自研存储可以保持架构的轻量化，用户不需要维护额外的存储服务或元数据组件，同时也能不受限于第三方存储的迭代节奏，更灵活地跟随Flink生态的需求快速调整功能。

• 真正的流批统一查询体验
  虽然Hudi/Iceberg支持多引擎查询，但它们的流查询是在批存储基础上做的扩展，流批查询的语义和性能存在天然差异。Flink Table Store的自研存储则实现了真正的流批统一：实时流读取和批式全量读取共用同一套存储结构和查询逻辑，既能保证语义一致性，也能让两种场景的性能都达到最优。

内容的提问来源于stack exchange，提问作者Kyle Liao