摘要：本文整理自阿里云高级技术专家、Apache Flink PMC 成员、Apache Fluss PPMC 成员 伍翀老师，在 Flink Forward Asia 2025 城市巡回深圳站中的分享。
Tips：关注「Apache Flink公众号」回复 FFA 2025 查看会后资料～
一、问题起点：分析型流处理系统的缺失
在大数据处理领域，我们通常将系统划分为四个象限：
纵轴：批处理 vs 流处理
横轴：业务型 vs 分析型
会得到四个象限：
MySQL、PostgreSQL：业务型 + 批处理
Kafka、Pulsar：业务型 + 流处理
Snowflake、Iceberg：分析型 + 批处理
但你会发现——分析型 + 流处理 这一块，几乎是空白的。
因此，Fluss 的定位非常明确：填补这个空白，做一个面向分析型场景的实时流存储系统。
二、Fluss 是什么？
Fluss核心架构
Fluss 的整体架构和传统的 Kafka 比较类似，本质上是一个带服务的存储系统。数据会在 Fluss 的 Server 之间进行三副本、高可用、持久化存储。同时，系统会结合远程的 HDFS 或对象存储实现数据分层，将数据按冷热与生命周期进行合理划分。
在数据分层方面，Fluss 会将长周期的历史数据持续下沉到数据湖格式中，用于更长周期的数据存储与各类分析型场景。同时，这几层不同形态、不同介质上的分层数据，可以进行联合查询，我们称之为 Union Read。用户无需关注底层的存储细节，依然通过同一套 SQL API，即可对最底层的多层数据进行数据合并，并保证数据的一致性，在上层看到的仍是一张表的统一视图。
此外，Fluss 还提供了流式读取、流式写入、实时更新、实时写入、点查以及维表查询等能力。
核心应用场景
Fluss 在阿里内部、阿里云以及部分业界的核心业务场景中已经有了较多应用。当前主要有两个新的核心应用方向：
一方面是 Fluss + Flink，用来替代传统的 Kafka，构建实时数仓，形成一种新的实时数仓范式；
另一方面是 Fluss + Paimon，用来构建流批一体、秒级响应的湖仓架构，我们将这一架构称为湖流一体。
本次议题的重点主要在于介绍湖流一体的架构及其应用场景。不过在进入该部分之前，会先快速介绍 Fluss + Flink 替代 Kafka 构建实时数仓时，所提供的一些核心能力及其解决的问题。
三、 Fluss + Flink 实时数仓场景
整体梳理下来，Fluss 与 Flink 配合用于实时数仓建设，主要具备四个核心特性。
Fluss 的第一个核心能力是「流式查询下推」。与 Kafka 提供行式数据流（如 JSON、Avro）不同，Fluss 基于 Apache Arrow 构建列式流式日志系统，在磁盘侧即以列存格式组织数据。当下游仅需部分列时，可直接读取并传输所需列，端到端采用 Zero Copy，避免中间序列化/反序列化，显著降低网络、CPU 与解析开销。列裁剪之外，Fluss 还支持分区裁剪与条件下推：查询条件（如“双11当天”或特定业务分区）可下推至服务端，跳过无关数据。
第二个能力是「实时数仓的分层化」。借助毫秒级读写、实时更新及完整 Changelog 能力，Fluss 可贯通 ODS、DWD、DWS 等层级，构建分层清晰的端到端实时数据管道，弥补传统 Kafka 架构在数仓分层建设上的不足。
第三个能力是「实时宽表构建」。基于 Fluss + Flink，通过 Delta Join 等新范式替代传统双流 Join，简化状态管理，提升链路可维护性与版本升级体验，并支持 Partial Update 等多表实时拼接方式。同时，Fluss 提供面向大数据场景优化的「异步维表」能力，作为高吞吐外部维表被 Flink 查询，通过异步化、批量化、流水线化等优化，显著提升维表查询吞吐性能。
第四个能力是「MergeEngine 合并机制」。Fluss 在服务端提供或规划了类似 Paimon 的合并语义，包括 去重合并引擎 FistRow/LastRow/Versioned MergeEngine，也正在支持聚合合并引擎 Aggregate Merge Engine，已支撑实时长周期聚合指标和用户画像等场景。
四、“湖流一体”：Fluss 与 Paimon 的协同架构
这是一个 Fluss + Paimon 的湖流一体 High Level 架构图。整个体系中，Fluss 能够与 Paimon 或者类似的湖仓框架（如 Iceberg）做无缝集成，对用户来说几乎就像在使用一个「统一的数据库」，只是底层会根据不同的数据特性和时效性需求做冷热分层：
热数据存放在高性能介质上；
冷数据以更高压缩率存放在更低成本的介质上。
这一整套冷热分层和数据移动的过程，都由系统自动完成，无需用户干预。用户在读取「这张表」时，不需要关心数据具体位于哪一层存储，系统会自动将多层数据进行拼接，对外呈现为一份完整结果。这个跨分层拼接并统一查询的能力，在 Fluss 中称为 Union Read。
Fluss 将数据自动落到 Paimon 等湖仓时，严格遵循 Paimon / Iceberg 等系统原生的开放协议。因此，现有的湖仓生态和查询引擎可以无缝对接与访问 Paimon 中的数据，不会破坏或影响已有的离线链路与计算体系。
在展开介绍这个湖流一体架构之前，先简单聊一下业界在湖流融合方向上的一些趋势。这条路并不是只有我们在走，业界很多流存储厂商其实都在向这个方向演进。
在 2023 年，我们启动了 Fluss 项目，并首次提出「湖流一体」的概念。随后在 2024 年，Kafka 背后的商业公司 Confluent 推出了 Tableflow 产品。Tableflow 的核心目标，就是把 Kafka 中的数据无缝同步到 Iceberg 上。此后一两年内，市面上流存储相关的厂商也陆续推出了类似产品，比如 Redpanda、StreamNative、Upstash 等，都开始提供类似的「流到湖」的数据打通方案。
从这些公司的产品设计上，可以看到两个共同点：
都是从 Kafka 到 Iceberg
也就是做「流到湖」的数据通道，解决的是：Kafka 里的数据如何高效落到 Iceberg。
但反向的问题——Iceberg 里的数据如何真正被流系统复用、为流计算所用——他们还没有去做，或者至少没有给出清晰的产品化方案。都是围绕 Kafka 生态的公司
这些公司本质上都是做 Kafka 或 Kafka 兼容服务的厂商，提供的是 Kafka API 兼容的消息队列 / 流存储服务。所以它们的设计天然是「以 Kafka 为中心」，在 Kafka 外挂一个往湖仓（如 Iceberg）同步数据的组件或服务，所以也会受到 Kafka API 在与湖仓集成时的各种限制。
那这种「流到湖」的单向模式和 Fluss 的「湖流一体」之间，在架构理念和能力边界上有什么差异呢？
业界此类产品可分为两类：一类是以 Confluent Tableflow 为代表的「流式入湖」服务，另一类是以 Fluss 为代表的「湖流一体」架构。
「流式入湖」本质上是单向的数据同步通道，仅解决“如何将流数据从 Kafka 等源搬入数据湖”的问题；而「湖流一体」则聚焦于流与湖的双向数据共享——既让流端数据为湖端所用，也让湖端数据反哺流端，这是设计理念的根本差异。
在数仓分层上，流式入湖主要服务于 ODS 层的数据接入，后续 DWD、DWS 等层级仍需依赖独立批流作业构建，无法形成闭环；而湖流一体面向全链路实时数仓，旨在弥补 Iceberg、Paimon 等湖仓在秒级数据新鲜度上的不足，覆盖从 ODS 到 DWS 的端到端时效性需求。
理念层面，流式入湖属于 ETL 接入层能力，关注 Kafka 数据如何写入湖；湖流一体则是「流批一体」战略下的具体落地，以统一存储承载流与批的双重语义。
成本方面，流式入湖因 Kafka 与湖中同时保留数据副本，导致双份存储开销及潜在一致性风险；湖流一体则通过单一数据拷贝实现流湖共享，仅需一份存储成本。
开发成本上，流式入湖需为每个 Topic 单独配置复杂参数，接入成本高；而 Fluss 作为与湖仓在数据模型层原生对齐的流存储，开启湖流一体能力仅需一个配置开关，显著降低开发与运维负担。
在探讨为何不基于 Kafka 或其 API 来实现湖流一体时，核心原因在于：Kafka 是为消息系统设计的，而非为分析场景设计。这导致在尝试构建湖流一体架构时，会遇到四个基础且难以绕过的问题。
- Kafka 内部没有 Schema
由于 Kafka 本身是「无 Schema」的，在将其与「有 Schema」的数据湖 / 湖仓体系对接时，会产生大量额外工作，例如：
需要手动配置每个 Topic 对应的表；
每张表的 Schema 定义、字段类型和映射关系等都需要手工填写；
并且这些配置对于每一个 Topic 或表都要单独进行。
相反，Fluss 作为「有 Schema 的流存储」，只需在目标表上打开一个配置开关，后续的映射和元数据同步工作即可自动完成，大幅降低了使用成本和接入复杂度。
- 数据模型不匹配
Kafka 的数据模型主要是为微服务和消息队列场景设计的，在对接大数据 / 数仓体系时会出现明显割裂，例如：
在数据湖 / 数仓中，普遍存在数据库、数据表、分区、分桶等高层数据抽象；
Kafka 仅提供 Topic 概念，缺乏与上述模型一一对应的元数据体系。
相比之下，Fluss 从一开始就按「面向数据湖 / 数仓」的方式进行对齐，支持数据库、表、分区、桶，以及变更日志、主键、更新语义等，使得在实施湖流一体时能够无缝融合，无需大量额外的适配逻辑。
不支持更新语义
数据湖 / 湖仓（如 Iceberg、Paimon）通常支持更新与删除操作，并具备完整的 Changelog / Merge 语义。而 Kafka 的核心模型是追加写日志，不具备真正的记录级更新能力。
将一个「不支持更新」的系统与「支持更新」的系统深度融合，势必需要处理状态重建、补写、回刷等复杂逻辑，增加系统复杂性与维护难度。Fluss 则原生支持更新及 Changelog 语义，可以生成完整的变更日志供下游订阅，从而与湖仓的更新语义自然对齐。
业务场景与 API 语义的矛盾
Kafka 提供的 API 主要围绕消息语义展开，例如按 Topic + Offset 顺序消费。若要实现真正的湖流一体，不仅需要让流数据写入湖仓，还需要让湖仓中的数据能够反向为流所用，这就要求：
流系统能够原生地访问湖仓中的数据，且没有额外的转换开销；
支持按表、分区甚至按条件的灵活读取方式。
在 Kafka 现有 API 框架下，要实现这种反向能力，意味着需要在服务端执行一系列复杂转换：
从远程数据湖中读取 Parquet / ORC 等列存文件；
将其转换回 Kafka 的行式消息格式；
再通过消息 API 以流的形式回放给消费者。
这种做法与 Kafka 当前的业务模型存在明显冲突，会使存储与计算路径异常复杂，并引入大量并非消息队列范畴的工作负载。因此，在 Kafka 现有架构和 API 语义下，很难自然地将湖仓数据转变为流的一部分，供流计算直接复用。
五、为什么我们选择基于 Fluss 重新构建湖流一体架构？
在设计 Fluss 之初，我们就明确了一个核心理念：不能在 Kafka 的基础上修修补补，而必须从分析型场景的原生需求出发，重新定义流存储。这背后有三个关键设计：
从 Topic 到 Table 的范式转变
Kafka 是面向消息系统的，其核心抽象是无 Schema 的 Topic；而 Fluss 以“表（Table）”为第一公民，天然携带 Schema。这使得 Fluss 能与 Paimon、Iceberg 等 Lakehouse 表的 Schema 类型无缝对齐，避免了传统方案中手动维护 Schema 映射的复杂性和出错风险。支持完整的数据更新语义
湖仓系统普遍支持行级更新（如主键 Upsert），但 Kafka 仅支持追加写入。Fluss 原生支持实时更新，并能生成完整的 Changelog，为下游提供一致的变更数据流，这是实现湖流双向融合的基础。列式存储格式的深度优化
Fluss 基于 Apache Arrow 构建流式列存日志，不仅支持高效的列裁剪和条件下推，还能与 Lakehouse 的列式文件格式（如 Parquet、ORC）高效对接，极大降低 I/O 和计算开销。
内置 Tiering Service：实现湖流自动同步
Fluss 内置一个名为 Tiering Service 的后台服务（当前基于 Flink 实现，未来可扩展至其他运行时），它会自动将开启了“湖流一体”特性的表数据，持续地从 Fluss 转换为 Paimon 等 Lakehouse 格式，并精确记录 Lakehouse 快照与 Fluss Log Offset 之间的对应关系。
这个 Offset 位点是实现 Union Read（统一读取）的关键——它确保了从 Lakehouse 读取的历史数据与从 Fluss 读取的实时数据之间严格的一致性边界，从而实现“不多一条、不少一条”的端到端 Exactly-Once 语义。
更重要的是，一旦数据被成功分层到 Lakehouse，Fluss 便可安全清理旧数据，仅保留短周期（如 6 小时）的热数据。这显著降低了实时存储层的成本，同时不影响全量历史回溯能力。
六、 Fluss + Paimon：湖流一体架构的六大核心优势
流存储成本降低 10 倍以上
在传统 Lambda 架构中，实时链路（Kafka + Flink）和离线链路（Hive + Spark）各自独立，数据需双份存储。Kafka 通常只能保留 7 天数据，但业务往往需要数月甚至数年的回溯能力——这导致要么牺牲回溯能力，要么承担高昂的 Kafka 存储成本。
而在 Fluss + Paimon 的湖流一体架构中：
Lakehouse 存储长期历史数据（月级、年级）
Fluss 仅保留超短期热数据（如 6 小时）
用户仍可从几个月前开始完整回溯，且实时消费延迟保持在毫秒级。存储成本可从“7天”降至“6小时”，节省高达 20 倍的存储开销。更重要的是，流批在存储层真正统一，开发者只需面对“一张表”，无需在流/批之间切换逻辑。
高效、一致的数据回溯（Backfill）
当业务逻辑变更需要重跑过去 30 天的数据时，传统方案需手动拼接离线表与 Kafka 流，一致性难以保障。
Fluss 的 Union Read 机制自动完成这一过程：
获取 Paimon 最新快照及其对应的 Fluss Log Offset；
从 Paimon 并行读取历史数据（支持列裁剪、谓词下推，性能接近批处理）；
在精确的 Offset 位点无缝切换至 Fluss 流读。
整个过程自动、高效、强一致，大幅简化数据回填作业。
批查询获得秒级新鲜度
传统 Lakehouse 表的新鲜度受限于 Checkpoint 或 Commit 频率（通常为分钟级）。但在 Fluss + Paimon 架构下，批查询可通过 Union Read 同时读取：
Paimon 中的分钟级历史数据
Fluss 中的秒级实时数据
最终结果具备秒级端到端新鲜度，满足实时报表、运营看板等高时效性场景需求。目前 StarRocks、Flink 等引擎均已支持此类 Union 查询。
分层数仓的新鲜度不受层级影响
在传统流数仓中，每经过一层（ODS → DWD → DWS），数据可见性都依赖一次 Flink Checkpoint，导致端到端延迟累积（如 5 分钟 × 3 层 = 15 分钟）。
而 Fluss + Paimon 的湖流一体架构中，层间数据流动与 Checkpoint 解耦：
数据在 Fluss 表之间以毫秒级延迟流动；
每层 Fluss 表按固定频率（如 3 分钟）同步到 Paimon；
用户看到的 Paimon 表始终具有稳定、可预测的新鲜度。
这确保了数仓各层级的时效性可控，有效消除了业务开发中“每增加一层就带来额外延迟”的心智负担。
更高效的 CDC 与 Changelog 生成
Paimon 原生支持两种 Changelog 生成方式：
Lookup 模式：资源消耗大；
Full Compaction 模式：延迟高。
而 Fluss 本身已维护热数据的索引状态，可在写入时直接生成高质量的 Changelog。该 Changelog 一方面用于驱动 Paimon 主表的 Upsert，另一方面可直接 Append 到 Paimon 的 Changelog 表中，避免重复计算，实现低延迟、低成本的变更数据捕获。
湖仓的轻量级实时接入层
Lakehouse 客户端通常较重，对写入端要求高。Fluss 作为带服务的存储系统，将复杂写入逻辑下沉至服务端，提供轻量 SDK（Java、Python、Rust 等），支持多种写入场景：
大数据引擎（Flink、Spark）
IoT 设备
AI 训练/推理系统（如向量 Embedding 写入）
尤其在 AI 场景中，Fluss 可作为高速缓冲层：
避免 GPU 计算被对象存储写入阻塞；
平滑应对数据写入的波峰波谷（削峰填谷）；
后台持续将数据分层至 Lakehouse。
七、总结
无缝集成，平滑演进
Fluss 的设计理念是不颠覆现有湖仓架构，而是增强其实时能力。用户只需在现有 Paimon 表上开启“湖流一体”开关，并配置 Fluss endpoint，即可将一张普通表升级为支持毫秒级流读的实时表，原有链路完全不受影响。
目前，阿里云上的 Fluss 已与 DLF、Paimon 深度集成，提供开箱即用的湖流一体、Union Read 等能力，并可申请免费试用。更多详情可访问：https://www.aliyun.com/product/flink/fluss
未来规划
更广泛的查询引擎支持：StarRocks、Trino、Spark 等已内部对接或社区推进中；
元数据统一：支持 Paimon 表一键升级为湖流一体表（PIP-39）；
高性能 Union Read：对接 Paimon Deletion Vector，提升主键表的批查性能；
Fluss 不是另一个 Kafka，也不是简单的“Kafka + Lakehouse 同步工具”。它是面向分析型场景、为湖流一体而生的新一代流存储。通过重新思考流与湖的关系，Fluss 正在推动实时数仓进入“一份存储、统一视图、秒级新鲜、低成本回溯”的新时代。
Fluss 团队正在杭州、上海招聘！
如果你对实时计算、湖仓一体、AI 数据基础设施充满热情，欢迎加入我们，一起改变世界！
Bring better analytics to data streams, and better data freshness to data lakehouses.
阿里云流存储 Fluss 于 2026 年 1 月 13 日 正式开启免费公测
基于 Apache Fluss 打造的高性能列式流存储系统，具备毫秒级读写响应、实时数据更新及部分字段更新能力，可替换Kafka构建面向分析的流式存储，结合DLF（Paimon）等数据湖产品构建湖流一体架构。
公测活动： 公测期间单用户可免费使用2个集群，单个集群上限80 Core，如果您在使用过程中向我们提出改进建议或评测报告，我们将依据反馈内容的深度与质量，向优质测评者赠送定制Fluss周边礼品。
https://help.aliyun.com/zh/flink/realtime-fluss/product-overview/join-the-public-preview-of-fluss
更多内容
活动推荐
复制下方链接或者扫描左边二维码
即可免费试用阿里云 Serverless Flink，体验新一代实时计算平台的强大能力！
了解试用详情：https://free.aliyun.com/?productCode=sc
