StarRocks x Fluss x Paimon 湖流一体方案通过将 Apache Fluss（面向分析场景的实时流存储）与 Apache Paimon（高性能湖格式表）深度融合，以 StarRocks 作为统一查询入口，构建了一套具备秒级新鲜度、十倍成本降低、一份数据一次查询的全新实时数据引擎。本文将介绍该方案的核心架构、技术优势、查询模式以及实现原理。
1. 背景与挑战
1.1 Lambda 架构的痛点
在传统 Lambda 架构中，实时链路采用 Kafka + Flink，离线链路采用 Hive + Spark，两套系统各自运行。这套架构虽然已服务行业多年，但始终存在三个核心痛点：
-
存储翻倍： 同一份业务数据在 Kafka 保留 7 天，在 Hive 再存一份，存储成本成倍增长。
-
代码翻倍： 流批开发、运维两套 Pipeline，数据口径经常不一致，排查问题时大量时间消耗在核对实时与离线数据上。
-
新鲜度上不去： 离线链路通常 T+1 或小时级刷新，无法满足业务对实时性的要求。
1.2 纯湖仓架构的局限
湖仓架构（如 Flink + Paimon 级联加工）虽然解决了流批统一的问题，但新鲜度仍然受限。其核心原因在于 Paimon 的新鲜度绑定在 Flink Checkpoint 之上——假如 Checkpoint 设为 5 分钟，第一层湖表新鲜度为 5 分钟，第二层累加为 10 分钟，第三层达到 15 分钟。层级越多，延迟线性增长，对于需要多层加工的业务场景极不友好。
图 2：纯 Paimon 湖仓架构 vs Fluss + Paimon 湖流一体架构的新鲜度对比
2. Fluss / Paimon / Kafka 数据概念对比
下表详细对比了三者在数据模型层面的差异，这是理解 Fluss 为何比 Kafka 更适合做实时数仓的关键：
图 3： Fluss/Paimon/Kafka 数据概念对比
Fluss 的数据概念与湖仓完全对齐，可无缝融合；而 Kafka 与湖仓系统存在本质性割裂——无 Schema、行存、无库表分区概念，这正是实时数仓场景中 Kafka 的核心短板。
3. 湖流一体方案核心优势
3.1 流存储成本降低 10 倍
在 Lambda 架构中，Kafka 通常需要保留 7 天数据以保证回溯能力，存储成本居高不下。而在湖流一体架构中，Fluss 只需保留超短周期的实时数据（如 6 小时），超过 TTL 的数据由 Tiering Service 自动沉淀到 Paimon 湖表中。流存储从 7 天缩减到 6 小时，成本直接降低一个数量级。同时流批存储统一为一份视图，不再维护两套独立的数据链路。
3.2 湖仓分层新鲜度不受层级影响
在 Fluss + Paimon 湖流一体架构中，Flink 流式作业直接读写 Fluss，实时数据流始终保持秒级延迟。长周期数据入湖过程与 Checkpoint 解耦，每层湖表新鲜度稳定在约 3 分钟，无论分层多少层都不累加。简而言之：实时段秒级、湖仓段约 3 分钟，且新鲜度稳定不随层级增加而累加。
3.3 批查秒级新鲜度（Union Read）
Union Read 是湖流一体架构的核心查询能力。当用户发起查询时，StarRocks 同时拉取 Paimon 上的历史数据（Snapshot）和 Fluss 上的实时增量数据（从 Snapshot 对应的 log_offset 开始），在内部执行 Sort Merge 操作，合并为一份完整的结果集。这意味着一次普通的 SELECT 查询就能获得秒级新鲜度的全量数据视图，且语义为 Exactly-Once——不重不漏。
图 4：Union Read 工作原理——实时数据与历史数据一次查询合并
4. 湖流一体架构总览
湖流一体架构的核心设计理念是“三个同一份”：
-
数据同一份： 不是双写，而是通过 Tiering Service 自动将 Fluss 中超过 TTL 的数据沉淀到 Paimon，一份数据自动流转。
-
元数据同一份： 使用 DLF Omni Catalog 统一管理 Fluss 和 Paimon 的元数据，一套 Catalog 管理全部数据资产。
-
查询入口同一份： 全部使用 StarRocks 作为统一查询引擎，一条 SQL 即可获取实时+历史全量数据。
图 5：湖流一体架构总览——一份数据、一份元数据、一次查询拿全
Tiering Service —— 数据自动分层下沉： 在上述架构中，Tiering Service 是实现“数据同一份”的关键枢纽。Tiering Service 是湖流一体架构中的关键组件，本质上是一个常驻的 Flink 作业。它自动将 Fluss 中超过 TTL（如 6 小时）的数据导入 Paimon 湖表，并删除过期数据。用户无需编写 ETL 作业，只需开启配置开关即可。Fluss + Paimon 共同组成完整的数据视图：Fluss 持有秒级新鲜的实时数据，Paimon 持有长周期历史数据。
5. StarRocks 统一查询入口
StarRocks 作为湖流一体架构的统一查询入口，通过一个 Fluss Catalog 即可接入全部数据，提供三种查询姿势满足不同场景需求。
5.1 接入方式
只需一行 SQL 即可将 Fluss 接入 StarRocks：
CREATE EXTERNAL CATALOG `fluss_catalog`
PROPERTIES ("type" = "fluss",
"fluss.option.client.security.sasl.mechanism" = "PLAIN",
"bootstrap.servers" = "fluss-cn-2rn4ffq4o01:9123",
"fluss.option.client.security.sasl.password" = "xxx",
"fluss.option.client.security.protocol" = "SASL",
"fluss.option.client.security.sasl.username" = "xxx"
);
5.2 三种查询姿势
姿势一：默认 Union Read
直接查询表名，StarRocks 自动合并 Fluss 实时数据与 Paimon 历史数据，适用于实时大盘、实时报表等场景。
SELECT user_id, COUNT(*) FROM ods.ordersWHERE dt = '20260528' GROUP BY user_id;
姿势二：$lake 后缀（仅读历史数据）
在表名后加 $lake 后缀，只查询 Paimon 湖上历史数据，跳过实时段。适用于 T+1 报表、跨天回算，性能最优。
姿势三：$rt 后缀（仅读实时数据）
在表名后加 $rt 后缀，只读取 Fluss Server 端的实时数据。适用于线上排查、数据回追、实时监控场景。
图 6：StarRocks 查询 Fluss——一个 Catalog，三种查询姿势
6. 技术架构详解
StarRocks 读取 Fluss 数据时，根据表名后缀自动路由到不同的 Scan 通道：
6.1 Paimon Scan（历史段）
历史数据查询走 Native C++ 直读链路，零 JVM 开销，支持列存高吞吐、向量化执行，并可利用 DataCache 加速。数据直接从 OSS 上的 Paimon 文件读取，充分发挥 StarRocks 在湖查询上的性能优势。
6.2 Fluss Scan（实时段）
实时数据查询通过 JNI Bridge 调用 Fluss Java Client，复用官方 Fluss 协议，通过 Arrow 格式跨边界传递数据。虽然当前仍有 JVM 开销，但 Arrow 列式传输已显著减少行列转换损耗。
6.3 Union Read Merge
当用户执行默认查询时，StarRocks 同时读取 Paimon Snapshot N 和 Fluss 中 offset > N.commit 的增量数据，按主键合并，保证 Exactly-Once 语义。这套机制实现了真正的“一次查询，实时+历史全拿到”。
图 7：StarRocks 读取 Fluss 数据技术架构——Paimon 走 Native，Fluss 走 JNI，Union Merge 合并
7. 未来规划
StarRocks x Fluss 的未来演进方向围绕“读得最快、读得最稳”两个目标展开：
7.1 Union Read 2.0：跳过 Sort Merge
当前 Union Read 在处理主键大表时需要 Sort Merge 合并，未来计划支持 Fluss 的 Delete Vector，通过 Bitmap 标记删除行并跳过，避免 Sort Merge 过程，显著提升端到端性能。
7.2 优化器看懂 Fluss
接入行数、NDV、Min/Max 等统计信息，支持元数据短路优化 COUNT 查询、Limit 下推、Time Travel 等能力，让优化器精准选择最优执行策略。
7.3 Native 全链路
将实时段也优化为 C++ 直读，通过 Fluss Arrow 做零拷贝传输，并接入 DataCache、谓词下推到 Fluss Server 等能力。最终实现 Snapshot 和 Log Split 统一一个 Native Scanner，消除 JVM 占用。
图 8：StarRocks x Fluss 未来规划——Union Read 2.0、优化器增强、Native 全链路