Fluss：重新定义实时数据分析与 AI 时代的流式存储

引言：一场关于流式存储的范式变革

欢迎阅读对 Apache Fluss（孵化中） 的深度解读——这是一项突破性的流式存储解决方案，旨在彻底重塑实时数据分析与人工智能（AI）基础设施的未来。

本文内容基于伍翀在 Flink Forward Asia 2025 新加坡大会上的主题演讲，旨在介绍 Fluss 作为下一代流式存储系统的核心理念与技术优势。我们将深入探讨 Fluss 如何弥合传统流处理系统与现代湖仓（Lakehouse）架构之间的鸿沟，显著提升机器学习特征工程、多模态 AI 数据摄入等前沿场景下的存储能力。

我们将一起了解：

• 为什么我们需要 Fluss？

• 它的架构优势是什么？

• 在真实生产环境中如何落地？

准备好，一起进入 Fluss 的世界。

传统数据架构的困境

在当今“数据驱动”的时代，Apache Kafka 已成为几乎所有流式数据架构的基石。它在微服务间的事件通信、高吞吐日志采集等方面表现出色。

当我们需要从流数据中获取实时洞察时，通常会使用 Apache Flink 进行处理与转换。而为了实现分层建模，我们常将数据写回 Kafka 的多层主题（Topic）中：比如青铜层（bronze）、银层（silver）、金层（gold）——即所谓的“数据湖勋章架构（Medallion Architecture）”。

但问题来了：

当你要做一次 key-value 查询来丰富数据，该怎么办？

Kafka 本身不支持高效的 KV 查询。于是我们不得不把数据复制一份到 Redis 这类 KV 存储中，只为支持维度表关联。

当你想对 Kafka 主题进行数据探索或调试呢？

Kafka 并不是为“可查询”而设计的。你只能再次复制数据，导入 ClickHouse 等 OLAP 系统才能做交互式分析。

如果你想构建一个支持批处理的数据湖仓？

对不起，还得再复制一次——这次要转成 Iceberg、Paimon 等开放格式。

于是，同样的数据在 Kafka、Redis、ClickHouse、Iceberg 之间被反复复制，形成“数据影子系统”。

这带来了四大问题：

1. 成本飙升：多份副本显著增加存储与网络开销；

2. 架构复杂：运维多套系统，一致性难保障；

3. 数据孤岛：各系统之间割裂，难以统一治理；

4. 延迟累积：每次复制都引入额外延迟。

更关键的是，在这种架构下，Kafka 主题本身几乎没有任何业务价值。它既不能被查询，也不适合长期存储，更不支持更新——只是一个“黑盒中转站”。

这并不是 Kafka 的错。Kafka 的设计初衷是高吞吐、低延迟的事件分发，而非分析或 AI 场景。它缺乏：

• 内置 Schema 管理

• 更新语义支持

• 面向长期存储的优化

因此，把它用在大数据场景本质是个误用。

正是基于这一深刻认知，Fluss 项目在两年前应运而生——一个从零构建、专为分析与 AI 场景优化的流式存储系统。它的目标很明确：终结数据重复复制，打造统一、高效、低成本的实时数据底座。

Fluss：流式存储的新范式

Fluss 代表了流式存储技术的一次重大跃迁。

它是一个支持亚秒级读写延迟的流式存储系统，底层基于 Apache Arrow 构建，采用列式日志结构（columnar log）。这一设计赋予了 Fluss 天然的分析优势。

核心优势一览

✅ 强大的分析能力

得益于 Arrow 的列式格式，Fluss 支持流式列裁剪与流式分区裁剪。查询时仅读取所需列与分区，大幅降低网络传输开销，提升分析效率。

✅ 高性能的实时更新与查询

Fluss 支持高并发、低延迟的 KV 查询与更新，可直接作为 Flink 的维度表进行 Lookup Join，无需再引入 Redis。

✅ 与湖仓无缝集成的分层存储

Fluss 支持将热数据保留在本地高速存储中，冷数据则自动归档至湖仓（如 Iceberg、Paimon），实现成本与性能的平衡。归档数据采用标准开放格式，可被 Spark、Trino、StarRocks 等引擎直接读取。

✅ 统一读取（Union Read）：打通流与批

Fluss 引入了 Union Read 特性，智能合并热数据（Fluss）与冷数据（湖仓）。它先读取历史数据，再无缝衔接实时流，无重复、无遗漏。Flink 已原生支持 Union Read，StarRocks 集成也在推进中。

Fluss 构建真正的“实时流式湖仓”

通过 Fluss，企业可以实现一个真正统一的实时湖仓架构——数据只存一份，却能同时满足：

• Flink 流式分析：亚秒级读写

• 维度表 Join：KV 查询支持

• OLAP 查询：Union Read 支持

• 批处理：开放湖格式兼容

需要强调的是，Fluss 并非要取代湖仓，而是为湖仓注入强大的流式能力。它让数据在“流”与“湖”之间自由流动，实现真正的数据融合。

如何实现数据共享？

Fluss 内置一个分层服务（tiering service），持续将 Fluss 中的数据转换为 Iceberg/Paimon 等格式，写入湖仓。这一机制类似于数据库的“冷热分层”策略，但 Fluss 将湖仓作为“冷层”，确保冷数据对整个生态开放可读。

• Fluss = 实时数据层：存储短期、高时效性数据（亚秒级延迟）

• 湖仓 = 历史数据层：存储长期数据（分钟级延迟）

当流任务需要回溯历史数据时，湖仓提供快速“追赶”能力；当执行批分析时，Fluss 可将最近几分钟的最新数据补全至湖仓，确保批处理结果也是“实时的”。

Fluss 在生产环境的真实案例

Fluss 不是纸上谈兵。它已在阿里巴巴大规模落地，展现出强大的稳定性与性能。

目前，Fluss 已管理 超 3 PB 数据，单集群写入吞吐高达 40 GB/s。支持单表 50 万 QPS 的 KV 查询，最大单表行数超 5000 亿。

让我们深入看看阿里巴巴生产环境中的几个典型应用场景。

案例一：淘宝日志采集与实时分析

淘宝每天产生海量日志：点击流、用户行为、订单流等，是下游分析与 AI 模型的数据基础。

过去使用 Kafka 时，面临两大挑战：

1. 存储成本高：日志量年年增长，但 Kafka 难以长期保留，用户想查一周前的数据？做不到。

2. 读取成本高：日志常被“一写十读”，网络流量巨大。

切换至 Fluss 后，团队利用“流式湖仓”的共享能力：

• 长期数据归档至湖仓，Fluss 本地数据减少 30%

• 利用列裁剪与分区裁剪，读取流量降低 70%

• 整体成本下降 30%

真正实现了“低成本、高时效、可追溯”的日志分析。

案例二：Delta Join —— 超大规模流式 Join 的破局之道

流式 Join 是 Flink 的核心能力，由于 Kafka 无法同时提供流读和索引点查的能力，所以在 Kafka+Flink 的架构下需将所有上游数据缓存在 Flink 状态中。例如，阿里搜索推荐团队需关联“页面点击流”与“订单流”做归因分析。两个流数据量巨大，在 Kafka+Flink 的架构下状态高达 100 TB，这导致作业不稳定、checkpoint 超时、资源消耗巨大等问题。

通过引入 Delta Join（基于 Fluss），问题迎刃而解：

Delta Join 本质是一种双向 Lookup Join：

• 左流数据到来时，去 Fluss 中查右表；

• 右流数据到来时，去 Fluss 中查左表。

语义等价于传统 Join，但让 Flink 作业变得很轻量和灵活，同时在 Fluss 中的索引能被多个 Flink 作业复用。

实际效果：

• 减少 100TB 的状态大小

• 检查点时间从 90 秒降至 1 秒

• Flink 资源消耗减少 85%

• 作业更新不再依赖状态重放，迭代速度大幅提升

更棒的是，Delta Join 已开源并捐赠至 Apache Flink，已在 Flink 2.1 版本中发布，标志着 Fluss 与 Flink 生态的深度整合。

Fluss 未来路线图：面向多模态 AI 与开放数据

Fluss 的未来充满想象空间，聚焦三大方向：

1. 增强流式湖仓能力 支持更多开放格式：Iceberg、Delta Lake 拓展查询引擎生态：Spark、Trino、StarRocks 全面兼容

2. 多模态 AI 深度集成 支持文本、图像、音频、视频等多模态数据的实时摄入与存储 与 Lance（AI 开放格式）深度整合，构建“实时 AI 数据湖”

3. 推出 Python 客户端（PyArrow 集成） 支持 Pandas、Polars、DuckDB 等 Python 数据工具 让数据科学家也能轻松接入 Fluss

在 AI 时代，数据基础设施面临三大核心挑战：

首先是多模态数据的崛起——与传统分析主要依赖结构化数据不同，AI 应用越来越多地处理文本、图像、音频、视频等非结构化数据，这对存储和处理系统提出了更高的灵活性要求。其次是流式数据的需求激增——AI 智能体（Agent）不再满足于基于历史数据的离线推理，而是需要实时感知、即时决策，要求数据管道具备低延迟、持续更新的能力。最后是开放数据的重要性日益凸显——为了实现跨系统、跨工具的协同，数据格式必须开放、标准、可互操作，就像分析领域依赖 Parquet、Iceberg 一样，AI 也需要属于自己的“通用语言”。Fluss 正是基于这样的洞察，致力于构建一个支持多模态、原生流式、拥抱开放生态的下一代数据底座。

未来的 Fluss 将不仅是分析引擎的底座，更是多模态 AI 实时流水线的核心：

• 实时摄入多模态数据 → 存储为流式格式 → 转换为 Lance → 接入 Ray、PyTorch 等 AI 框架

结合即将推出的 Python 客户端，Fluss 将解锁：

• 实时多模态智能体（Agent）

• 实时 AI 数据湖

• 实时特征工程平台

Fluss 的开源之路

Fluss 的开源之旅始于 2024 年 Flink Forward Asia 上海大会，现场宣布开源。半年内：

• GitHub Stars 超 1,200

• 贡献者超 50 人，来自阿里巴巴、字节跳动、eBay、小米、腾讯等全球领先企业

• 已发布 3 个版本，迭代迅速

2025 年 6 月，阿里巴巴正式将 Fluss 捐赠至 Apache 软件基金会（ASF），项目更名为 Apache Fluss（Incubating）。新仓库地址：https://github.com/apache/fluss/

加入 Apache 是 Fluss 社区的重要里程碑，标志着它迈向更开放、更中立、更可持续的未来。

邀测开启：适用于 Apache Fluss 的阿里云托管服务上线

现在，适用于 Apache Fluss 的阿里云托管服务已启动邀测，现已在北京、杭州、新加坡等区域开服。

开发者可扫描二维码申请试用，率先体验下一代流式存储的强大能力：

结语：Fluss 的使命

Fluss 正在重新定义实时数据基础设施的边界。

它不是 Kafka 的替代品，也不是湖仓的竞争对手，而是一个融合者：将流、批、分析、AI 统一在同一个高效、开放、实时的数据底座之上。

随着其在 Apache 社区的持续演进，Fluss 有望成为未来数据架构的“实时神经中枢”，助力企业真正释放数据与 AI 的全部潜能。

实时数据，不再分裂。

统一存储，就在 Fluss。