川海智库

报告概述

本白皮书系统介绍 Apache Fluss 这一流式优先、湖仓原生的列式存储引擎。报告首先从企业实时基础设施的演进路径切入，分析多系统税的形成原因；随后深入剖析 Fluss 的集群拓扑、存储引擎、日志表与主键表双表模型、三级存储架构与复合裁剪机制；最后重点阐述状态外置设计，包括 Delta Join、聚合合并引擎、部分更新、虚拟表以及作为 AI 上下文存储的实践。读者可通过本报告评估 Fluss 是否契合自身业务场景，并据此规划基于统一存储底座的实时数据架构。

报告的核心结论

多系统税是碎片化数据架构的隐性代价

报告指出，企业构建实时智能系统往往需要拼接消息队列、KV服务、OLAP引擎、特征存储与向量库等独立系统，每一条系统边界都是数据一致性的薄弱点。工程团队大量精力被用于维护系统间同步与数据口径，而非业务创新。系统越多，数据偏差和运维成本越高，这是促使架构收敛的根本原因。

一份数据、一个底座可统一承载多类工作负载

Apache Fluss 将事件传输、KV服务、列式分析与 AI 上下文收敛到同一存储底座，通过主键表同时暴露有序 Changelog 和最新行 KV 视图，实现流与表的统一。热层数据经由分层服务归档到开放湖仓格式，并通过联合读取供多种计算引擎透明访问，使实时分析、特征工程与 AI 上下文共享同一份数据。

状态应归属于存储层，而非流计算引擎

Fluss 将状态外置到主键表，Flink 作业退化为无状态计算进程，无需在算子内部保存状态，恢复时只需重连 Fluss 和读取已提交 Offset，恢复时间大幅缩短。基于这一设计，Delta Join、聚合合并引擎和部分更新等机制将状态管理统一下沉到存储层，解耦 RPO 与 RTO。

存储侧裁剪可显著降低网络传输代价

Fluss 默认以 Apache Arrow 列式格式存储日志，能在数据离开存储节点之前完成列裁剪、谓词下推与分区裁剪。传统架构需要先全量传输数据到 Flink 再丢弃，而 Fluss 只传输查询真正需要的字节，从而降低网络 I/O、反序列化开销与 TaskManager 资源压力。

统一存储可从结构上消除训练-服务偏差

传统特征存储中训练读离线存储、服务读在线存储，两套数据口径随时间必然漂移。Fluss 让训练和服务读取同一主键表的不同视图：服务通过 KV 点查读取最新状态，训练通过快照分片读取确定性时间点视图，从根本上避免了双存储架构带来的特征偏差。

报告回答的关键问题

什么是多系统税？对实时数据架构有何影响？

报告将多系统税定义为碎片化架构中为维持系统间数据一致性所付出的持续性工程成本。实时智能系统通常拼接消息队列、KV存储、OLAP引擎、特征存储与向量库，每个系统边界都是薄弱点，数据在搬运中容易产生偏差，团队精力被基础设施维护消耗，这正是 Apache Fluss 希望用统一存储底座解决的问题。

Apache Fluss 是如何统一消息队列、KV存储与OLAP分析的？

Fluss 通过主键表在同一份数据上同时提供三种访问模式：KV 点查服务在线特征与异步 Join，流式日志读取服务 CDC 消费，列式批量扫描服务分析查询。三种模式共享同一底层存储，无需协议转换和外部同步管道，因此一个系统就能承担原本需要 Kafka、Redis 和 OLAP 引擎协同承担的角色。

流式湖仓与传统 Kafka + Flink + 多套存储的架构有什么不同？

传统架构下，事件流经 Kafka，状态和特征存在 Redis，分析查询走 OLAP，历史归档到 Iceberg，各系统之间需要同步管道维护一致性。Fluss 作为流式湖仓底座，将热数据和冷数据统一在一套存储中，通过分层服务和联合读取让一条查询透明跨越冷热边界，所有计算引擎共享同一份数据，从而避免多系统带来的数据搬运和口径偏差。

如何消除机器学习训练和服务的特征偏差？

报告指出，训练-服务偏差的根源是训练和服务读取不同的存储。Fluss 让两者读取同一张主键表：服务通过毫秒级 KV 点查读取当前状态，训练通过快照分片读取确定性的时间点视图。两条路径在同一个底层存储上，特征不会因为两套管道而漂移，从结构上消除了偏差。

报告中的代表性数据

最高降低 85%

相比同等规模 Kafka 集群的成本降低比例

资料未明确，报告指出，基于 Apache Fluss 的流式湖仓采用存算分离架构，计算层精简且无状态，相比同等规模的 Kafka 集群，成本最高可降低 85%。该比例为报告给出的对比数值，具体场景和口径需以原文为准。

约 97%

典型负载中可被服务端裁剪的网络传输数据比例

资料未明确，报告以具备分区选择性、谓词选择性和列投影特征的典型分析查询为例，指出传统架构中约有 97% 的数据会通过网络传输到 Flink 后在进程内被丢弃，而 Fluss 可在存储节点完成裁剪，只传输所需字节。该比例因负载而异。

CPU 106 核对 14-16 核；算子状态 95TB 对 0.1TB；Checkpoint 约 90 秒对约 1 秒

Delta Join 与有状态 Flink 基准测试资源消耗对比

资料未明确，报告给出了同一双流 Join 在 Kafka+有状态 Flink 与 Fluss Delta Join 两种架构下的实测对比结果，后者的 CPU、内存、状态大小和 Checkpoint 延迟均下降约一到三个数量级。该数据来自报告引述的基准测试，非生产环境实测。

以上数据根据报告摘要整理，具体统计口径和数值请以完整报告原文为准。

完整报告包含什么

  • 基于 Apache Fluss 的 Streamhouse 实践：介绍统一流式湖仓平台的组件构成，包括 Fluss 流式存储层、开放湖仓层、统一流批处理引擎、物化表、自动调优服务和工作流调度器，并总结统一架构、湖流一体、存算分离、列式分析、特征上下文存储和生态开放六大核心价值。
  • 实时基础设施演进路径分析：从流式写入与 CDC、流式分析与运营大盘、实时数据处理与复杂事件处理，到实时机器学习与特征工程，再到实时 AI 系统与上下文工程，梳理五段演进路径及每阶段引入的专用系统，剖析多系统税的形成原因。
  • 集群架构与存储机制：说明 Fluss 集群的 CoordinatorServer、TabletServer 和元数据存储三层拓扑，讲解 Arrow 列式和 Compacted 行式两种日志格式、RocksDB KV 存储、写入路径的预写缓冲区与 ISR 复制，以及 KV 点查、流式日志读取和批量扫描三种读取路径。
  • 双表模型与 Changelog 语义：阐述日志表和主键表的设计，主键表的 first_row、versioned、aggregation 等合并引擎，以及 +A、+I、-U、+U、-D 五种变更类型如何支撑时间点正确的训练、CDC 消费和审计追溯。
  • 三级存储与联合读取：说明 Tier 1 热层、Tier 2 Fluss 原生远程层和 Tier 3 开放湖仓层的分层机制，热层数据经内部分层和分层服务两条路径归档，并介绍 Apache Iceberg、Apache Paimon、Lance 作为冷层目标的选择与 Union Read 透明读取。
  • 复合裁剪机制详解：深入讲解服务端列裁剪、谓词下推和分区裁剪如何在 Arrow 列式缓冲区上叠加生效，并通过典型查询说明其对网络传输、反序列化、Task Slot 内存和 Checkpoint 对齐时间的连带优化。
  • 状态外置与实时实体画像：包含 Delta Join、聚合合并引擎、流式 Lookup Join、部分更新、虚拟表、基于 Fluss 的上下文存储，以及自增列、Roaring Bitmap 和 rbm64 聚合器实现实时画像的完整方案。
  • 附录与运维参考：提供三级存储运维参考、写入流水线五个阶段、ISR 法定数、KV 快照节奏、合并引擎、Bucket 大小等配置建议，以及关键术语中英对照，便于读者在选型后落地评估。

本页内容由川海智库整理，用于帮助读者快速了解报告主题、核心观点和主要内容。由于报告量大、人工能力有限，部分观点、数据、统计口径或表述可能存在偏差，具体内容请以完整报告原文为准。

相关报告