新一代流存储Fluss核心架构主键表与Flink集成深度解析-开发者社区-阿里云

Fluss: First Impression

2025-03-01 202

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： Fluss: First Impression

摘要：本文由 Flink PMC Member 徐榜江（雪尽）老师翻译自 Yaroslav Tkachenko 的原创文章《Fluss: First Impression》[1]，内容分为以下7个部分：

Fluss 简介
Table(表) 作为核心概念
PrimaryKey Table(主键表)
更深层次的一体化
Flink SQL 的 Delta Join
Fluss 实现细节
Fluss 总结

Fluss [2] 是阿里巴巴前几周开源的一个新一代流存储，请查看其公告文章[3]。Fluss 与其他流存储（如 Apache Kafka、Apache Pulsar、Redpanda 等）非常相似，但在某些方面也存在显著差异（并且确实具备一些独特的功能），比如Fluss被设计成与 LakeHouse（如 Apache Iceberg 和 Apache Paimon）紧密集成。

目前，Fluss 还没有支持 Kafka 协议，但这已被列入Fluss 的 Roadmap 中。这使得我们的评估较为困难 —— 目前，你需要使用 Apache Flink或 Apache Paimon与之交互。不过，从架构上看，Fluss 的模型设计和 Kafka 比较类似：使用 Table 而不是 Topic；使用 Bucket 而不是 Partition等。

Fluss 架构[4]

Table (表) 作为核心概念

在查看 Fluss 文档时，最引人注目的一个点是，Fluss 将数据流组织为结构的 Table，而不是 Topic。在 Kafka 中，通常使用 Avro 或 Protobuf 格式配合 Schema Registry 一起来管理数据的 schema，但这并不是必需的。对于 Kafka 来说，每一条记录的值只是一个字节数组，这使得它能够处理半结构化或非结构化数据。

Fluss 要求在写入任何数据之前必须先定义 Schema，我个人认为这使得处理半结构化数据或需要频繁演变 Schema 的数据流更加困难。

将Table作为核心概念，也表明 Fluss 更像是一个数据库，而不是单纯的流存储。这与其宣传的用例非常契合：为实时数据提供快速摄取，并与 LakeHouse 实现 Union Read（下文会提到）以进行实时分析。

PrimaryKey Table(主键表)

Fluss 支持普通的 Append-only 日志表（Log Table）[5]，以及主键表（PrimaryKey Table）[6]。第一眼看上去，主键表是 Fluss 最令人印象深刻的特性。点查(lookup query)一直是 Kafka 的痛点：在几乎所有 Kafka 兼容的产品中，从某个Topic中查找一条特定的消息是非常通用的一个需求，而实现这一点几乎总是需要从头开始扫描整个Topic……这可能需要数小时。分层存储(Tiered storage) 可以改善这个问题，但改善幅度极其有限。

Fluss 的主键表通过 RocksDB 支持，用于支持更新、删除和高效的点查！因此，用户可以在 Flink SQL 中对Fluss中的表，执行类似于 “SELECT * FROM users_table WHERE user_id = 123” 的查询，并且能够相对快速地获取结果。

主键表同时支持完整的 Changelog 生成（changelog semantics）和部分列更新(Partial Update ）功能。当然，天下没有免费的午餐，我认为Fluss 主键表的性能可能会比日志表低一个数量级。

更深层次的一体化

我在 2023 年写过一篇题为《展望 2030 的数据平台》文章[7]，在那篇文章中，我预测在 2030 年，数据平台将会统一，流存储（ streaming log, 如 Kafka ）、湖仓（lakehouse, 如 Iceberg）和 OLAP 数据库（如 ClickHouse）三者将变得更加统一，形成一个易于使用和管理的“一体化数据引擎”，而不是三个独立的系统。现在看来我可能预测错了，因为我们可能会更早看到这一变化。多个厂商已经宣布将 Kafka 与 Iceberg API 集成（Redpanda 已经在 Beta 版本中支持 Iceberg[8]），Fluss 也不例外，它深度集成了 LakeHouse（Paimon，Iceberg*[9]），并突出了 Union Read 的用户案例（在 Apache Flink 中也被称为 Hybrid Source[10]）。

Fluss 除了很好地在流存储和 Lakehouse 两个维度实现一体化之外，其主键表的抽象更是超越了这两个维度。因为 Fluss 底层的 RocksDB 数据库不仅可以支持高效的点查（lookup query），还可以用于聚合查询(aggregation query)！Fluss 文档中提供了一个小示例[11]。你们需要知道，RocksDB 也被 Rockset 用作其 OLAP 引擎的底层存储[12]，因此，在 Fluss 上支持这些 OLAP 功能是完全可行的，起码在一定规模下是可行的。

Flink SQL 的 Delta Join

Delta Join 是我几年前就一直期待在 Flink 中支持的功能，这可能终于要实现了！

这个想法非常简单：

在经典的 "无窗口" 的双流 JOIN 中，左右两条流都需要在state中保存全量数据，这在大规模下变得极具挑战，我之前也对这个挑战写过一篇文章[13]。
流处理平台可以提供一种类似分层存储 (Tired Storage)的实现，保留永不过期的 state 数据。
因此，相比于保存数据到State中，不如在需要时通过点查直接查询分层存储。某种形式的批处理可能是必需的。
在典型的分层存储实现中，这些点查在 Apache Kafka、Confluent 或 Redpanda 中并不那么高效。但在 Fluss 中，主键表使得这变得可能。我想 Fluss 的贡献者也可以决定去增加二级索引功能来加快点查速度。

请随时查看 Flink 社区的 Delta Join 的 FLIP [14]设计了解更多详情。

Fluss 实现

Fluss 是用 Java 实现的，目前需要 Zookeeper 来进行协调。Table 的数据分区和复制类似于 Kafka 的 Topic。数据存储在本地磁盘上。总体而言，这种设计虽然可靠，但稍显过时（这是2019年的设计吗？Rust 到哪里去了呢？！😜）。不过，Fluss 的 Roadmap 已经提到一些计划中的改进，如去除 Zookeeper 和 Zero-Disk 架构。

在阅读部分源代码时，我不禁产生一种印象：Fluss 就是 Flink（参考了其类型系统）、Paimon（参考了部分设计）和 Kafka（类似的设计抽象、配置等）的结合体。不过这一点都不令人惊讶，因为 Fluss 的核心开发团队同时也是 Flink 和 Paimon 的贡献者。

Fluss 使用 Apache Arrow 这一列格式作为主要的数据交换协议，这使得 Fluss 非常有趣。生产者将 Arrow 向量进行攒批，并通过 Arrow IPC 将它们发送到 Server 端。

如果你想了解 Arrow 的攒批写入是如何工作，我邀请你阅读 ArrowLogWriteBatch.java[15] 和MemoryLogRecordsArrowBuilder.java [16] 这两份代码。

如果你仍然质疑向量化的列存格式是否适合流系统，我建议你阅读 Arroyo 的《我们在 Arrow 和 DataFusion 之上构建了一个新的SQL引擎》文章[17]，其中的关键观点如下：

观点翻译：

但我认为，在流处理中，为何批处理有意义的理由很简单：对于任何给定的大小的批，系统吞吐量越高，我们攒批所需等待的时间就越少。例如，如果我们希望批中至少有100条记录来分摊固定的成本，那么我们需要等待接收100条记录完成时间将取决于系统吞吐量：
● 每秒10个事件，需要1秒
● 每秒1,000个事件，只需要0.01秒（100毫秒）
● 每秒1,000,000个事件，只需要0.0001秒（0.1毫秒）

译者注：此处作者 Yaroslav 的观点是流系统里使用 Arrow 的 RecordBatch 来攒批是合理的，引用业界的真实案例说明攒批并不一定会影响延时，在高吞吐的流处理场景，一个100大小的攒批只需要0.1毫秒就可以完成。

Fluss 的协议是基于 Protobuf 实现的，非常容易理解：完整的说明可以在这里查看[18]。这块目前的代码量还不到 1000 行, 我很好奇未来在支持消费组(Consumer Group)功能之后会变成什么样子。

Fluss 总结

Fluss 是一个真正具备独特价值的系统，它试图将实时数据流建模为结构化的表。虽然Fluss处于非常早期的阶段，但我个人会保持关注：主键表和 Delta Join 可能会成为其杀手级特性。

Apache Flink 用户应该对 Fluss 的 Roadmap 感到非常兴奋：

Fluss 规划中Flink集成部分 [19]

Fluss 规划中 Flink 集成部分翻译：

Flink 集成

Fluss将与Apache Flink深度集成，为用户提供单一引擎即可构建实时分析应用的体验，包括：

● 支持使用 Flink 的 DataStream API读写 Fluss
● 支持全新的 Delta Join，以解决双流 Join 的痛点
● 支持更多的下推优化：过滤下推、分区裁剪、聚合下推等
● 将 Flink SQL Planner 中的基于规则的优化器(RBO)升级为基于成本的优化器(CBO)，利用 Fluss 表中的统计信息优化 Flink SQL

在 Fluss 的 Roadmap 里，Fluss 会深度集成 Flink，包括支持更多谓词下推（predicate pushdown）优化，将 Flink SQL优化器升级为 CBO，利用 Fluss 表的统计信息优化 Flink SQL 等未来规划，这些规划确实能够使得 Fluss 的性能提升 10 倍甚至 100 倍。