Apache Fluss：把流式存储接到 Lakehouse 的河流，但渡口还没全通
Apache Fluss 是一种专为实时分析而构建的流存储。
秒懂
- 它是什么？
- Apache Fluss 定位为实时分析打造的流式存储，用表统一实时与历史数据，主打亚秒级数据新鲜度和列式流处理。本文基于仓库与文档，拆解它的机制、上手路径、局限与替代方案。
- 适合谁用？
- Apache Fluss 适合已经以 Flink 或 Spark 为核心、并且正在搭建 Lakehouse 的团队，尤其是那些对数据新鲜度要求低于一秒、又不想维护两套系统的场景。它不适合只有批处理需求、或者计算引擎尚未确定的小团队，因为它的价值建立在流与湖的衔接上，单独使用收益有限。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Java（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是流与湖之间的断层
实时分析通常要面对两套系统：流处理引擎负责实时数据，数据湖负责历史数据。两者之间的搬运和衔接，既费时又容易出错。Apache Fluss 想用一张表把这两层统一起来。它的定位是流式存储，专门为实时分析设计，同时作为 Lakehouse 架构的实时数据层。目标用户很明确：已经在用 Flink 或 Spark 做流处理、又想把这些数据平滑汇入数据湖的团队。它不替代流处理引擎，也不替代数据湖，而是填在中间的那段河床。文档里用河流来比喻，数据像水一样持续流入湖中，这个意象对应的是它的核心承诺，亚秒级数据新鲜度。
表抽象背后的三根支柱
Fluss 的核心机制是表，它把实时流和历史数据都装进同一个表结构里。这个抽象不是简单的封装，文档列出了几个具体能力。第一是列式流，基于 Apache Arrow，这意味着流数据也能做列裁剪和谓词下推，引擎只读需要的列，减少 I/O 和网络开销。第二是计算存储分离，流处理器只做计算，状态和存储由 Fluss 管理，它还内置了去重、部分更新、delta join 和聚合合并引擎。第三是 changelog 生成，系统自动维护一份追加式的变更历史，用于审计和可复现性。这三根支柱合起来，让表既能承载实时写入，又能支持历史查询，同时保留流式语义。
构建与启动：Maven Wrapper 是唯一入口
要从源码构建 Fluss，环境要求是 Unix 类系统、Git、Maven 3.8.6 以上、Java 11。仓库自带 Maven Wrapper，所以不需要手动安装 Maven。构建命令很简单：先克隆仓库，然后执行 ./mvnw clean package -DskipTests。构建产物会放在 build-target 目录。README 没有提供启动服务或连接集群的详细步骤，这部分需要去官方文档的 QuickStart 页面找。注意构建时跳过了测试，如果你要用于生产，建议去掉 -DskipTests 跑一遍完整测试，尤其是你改了源码的情况下。
计算引擎的集成现状：Flink 和 Spark 已就位，StarRocks 待定
Fluss 的价值很大程度取决于它和计算引擎的配合。README 明确说支持 Apache Flink 和 Apache Spark，StarRocks 即将支持。这个「即将」是一个需要留意的信号。如果你依赖 StarRocks 做查询，现在还不能直接对接 Fluss。Flink 的集成是 QuickStart 的默认入口，说明这是最成熟的路径。Spark 的支持没有给出细节，但至少说明官方在维护。集成深度也不一样，列式流和谓词下推这些特性需要引擎侧配合，不是所有引擎都能完整利用。选型前要确认你的引擎版本和 Fluss 的兼容性，README 没有列出版本矩阵，这需要去文档或 issue 里查。
真实局限：不是所有实时场景的万能钥匙
Fluss 的设计有明确边界。它面向实时分析，如果你的场景是严格的 OLTP 事务处理，那它不合适，它没有提到事务隔离或 ACID 保证。另一个局限是它依赖外部计算引擎，本身不提供查询能力，你无法直接对 Fluss 里的表跑 SQL，必须通过 Flink 或 Spark。这增加了架构的复杂度，你至少需要维护两套系统。还有，它强调列式流和谓词下推，但如果你的查询模式是频繁全表扫描，那这些优化带来的收益会打折扣。最后，changelog 功能虽然提供审计能力，但会占用额外存储，对于存储成本敏感的场景，需要权衡。
替代方案：用 Kafka 加 Iceberg 自己搭桥
如果不采用 Fluss，常见的替代是 Kafka 加 Iceberg 的组合。Kafka 负责流式数据的缓冲和分发，Iceberg 作为湖格式存储历史数据，中间通过 Flink 或 Spark 定期做批式写入。这个方案和 Fluss 的差别在于数据新鲜度，Kafka 加 Iceberg 的典型延迟是分钟级，因为需要周期性触发 compaction 或微批写入，而 Fluss 声称亚秒级。另一个差别是表语义，Fluss 把流和湖统一成一张表，而 Kafka 加 Iceberg 是两条独立的链路，你需要自己维护流表与湖表之间的映射和同步逻辑。代价是 Fluss 更封闭，它有自己的存储格式，而 Iceberg 是开放格式，生态工具支持更广。
维护与升级成本：孵化期的变数
Fluss 当前版本是 0.9.1-incubating，属于 Apache 孵化项目。这意味着 API 和配置可能还没有稳定。从版本号看，0.8.0 在 2025 年 11 月发布，0.9.0 在 2026 年 3 月，0.9.1 在 2026 年 5 月，迭代节奏大约每季度一个版本。升级时你需要关注 release notes，因为小版本之间也可能有行为变化。构建系统是 Maven，依赖管理相对传统，但 Java 11 的要求意味着如果你已经升级到 Java 17 或 21，可能需要额外适配。许可方面是 Apache-2.0，对商业使用没有限制，但孵化项目的商标和品牌使用要遵循 ASF 规定。
编辑结论
Apache Fluss 适合已经以 Flink 或 Spark 为核心、并且正在搭建 Lakehouse 的团队，尤其是那些对数据新鲜度要求低于一秒、又不想维护两套系统的场景。它不适合只有批处理需求、或者计算引擎尚未确定的小团队，因为它的价值建立在流与湖的衔接上，单独使用收益有限。在采用之前，先确认你需要的计算引擎是否已有正式连接器，当前文档明确支持 Flink 和 Spark，StarRocks 还在路上。还要验证你的数据形态是否匹配它的表抽象，特别是 changelog 和主键表语义是否与你的业务一致。最后，检查你所在环境的网络和存储条件，因为列式裁剪和谓词下推的效果直接决定 I/O 节省是否值得。它的 Apache-2.0 许可对商业使用友好，但孵化状态意味着 API 和配置可能随版本变动，0.9.1 与 0.8.0 之间就有功能调整，升级前必须读 release notes。
社区笔记