本文由 Flink PMC Member&Committer，Flink CDC 项目负责人徐榜江（雪尽）老师翻译自 Yaroslav Tkachenko 的原创文章《Fluss: First Impression》[1]，内容分为以下7个部分：
- Fluss 简介
- Table(表) 作为核心概念
- PrimaryKey Table(主键表)
- 更深层次的一体化
- Flink SQL 的 Delta Join
- Fluss 实现细节
- 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 Source10]）。
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 倍。
参考链接:
[1]https://www.streamingdata.tech/p/fluss-first-impression
[2]https://github.com/alibaba/fluss
[3]https://www.ververica.com/blog/fluss-is-now-open-source
[4]https://alibaba.github.io/fluss-docs/docs/concepts/architecture/
[5]https://alibaba.github.io/fluss-docs/docs/table-design/table-types/log-table/
[6]https://alibaba.github.io/fluss-docs/docs/table-design/table-types/pk-table/
[7]https://www.streamingdata.tech/p/data-platforms-in-2030
[8]https://docs.redpanda.com/current/manage/topic-iceberg-integration/
[9]https://alibaba.github.io/fluss-docs/docs/streaming-lakehouse/overview/
[10]https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/datastream/hybridsource/
[11]https://alibaba.github.io/fluss-docs/docs/engine-flink/reads/#aggregations
[12]https://rockset.com/blog/how-we-use-rocksdb-at-rockset/
[13]https://sap1ens.com/blog/2020/12/12/streaming-systems-and-global-state/
[14]https://cwiki.apache.org/confluence/display/FLINK/FLIP-486%3A+Introduce+A+New+DeltaJoin
[17]https://www.arroyo.dev/blog/why-arrow-and-datafusion
[19][https://alibaba.github.io/fluss-docs/roadmap]
更多内容
活动推荐
阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动：
新用户复制点击下方链接或者扫描二维码即可0元免费试用 Flink + Paimon
实时计算 Flink 版（3000CU*小时，3 个月内）
了解活动详情：https://free.aliyun.com/?utm_content=g_1000395379&productCode=sc
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。