StarRocks Fluss Paimon湖流一体方案实现秒级响应实时数据引擎_AI热点日报

StarRocks联合Fluss与Paimon构建湖流一体实时数据引擎，实现秒级新鲜度与十倍成本降低。通过TieringService自动将Fluss短周期数据沉淀至Paimon，流批存储统一；StarRocks统一查询入口提供UnionRead，一次查询合并实时与历史数据，保证Exactly-Once语义。方案在阿里云EMRServerlessStarRo

1. 方案概述

StarRocks、Fluss 与 Paimon 联合构建的湖流一体解决方案，本质上是将 Apache Fluss（专为分析场景设计的实时流存储系统）与 Apache Paimon（高性能湖格式存储表）进行深度融合，并以 StarRocks 作为统一的数据查询入口。其最终目标在于打造一套全新的实时数据引擎：实现秒级的数据新鲜度，将存储成本降低十倍，并确保仅需一份数据、一次查询即可获取完整结果。本文将深入解析该方案的核心架构、技术优势、多样化的查询模式，以及其在阿里云 EMR Serverless StarRocks 上的产品化落地实践。

2. 背景与挑战

2.1 Lambda 架构面临的痛点

谈及传统的 Lambda 架构，大家并不陌生：实时数据链路通常采用 Kafka 搭配 Flink，离线数据链路则使用 Hive 配合 Spark，两套系统独立运行。尽管该架构在行业内应用多年，但始终存在三个难以逾越的核心障碍：

存储成本倍增： 对于同一份业务数据，需在 Kafka 中保留 7 天用于实时处理，同时在 Hive 中另存一份用于离线分析，这导致存储成本成倍增加。
人力成本攀升： 流计算与批处理各自维护一套 Pipeline，开发与运维工作需重复进行。更棘手的是，两套系统的数据口径常难以对齐，排查问题时，大量时间耗费在核对实时与离线数据的差异上。
数据新鲜度瓶颈： 离线链路通常只能达到 T+1 或小时级的数据刷新频率，实现真正的实时分析难度极高。

图 1：Lambda 架构与湖流一体架构对比——流存储成本降低 10 倍

2.2 纯湖仓架构的局限性

湖仓架构（例如使用 Flink 配合 Paimon 进行级联数据处理）虽然解决了流批统一的问题，但数据新鲜度依然是难以突破的障碍。其核心原因在于，Paimon 表的数据新鲜度与 Flink 的 Checkpoint 机制紧密绑定。举例来说，若将 Checkpoint 设置为 5 分钟，则第一层湖表的新鲜度为 5 分钟；经过第二层加工后，延迟变为 10 分钟；到第三层时，新鲜度可能已接近 15 分钟。数据加工层级越多，延迟呈线性增长。对于需要多层处理的业务场景而言，这显然不够友好。

图 2：纯 Paimon 湖仓架构 vs Fluss + Paimon 湖流一体架构的新鲜度对比

3. Fluss / Paimon / Kafka 数据模型对比

下表详细对比了三者在数据模型层面的关键差异。理解这些区别，才能真正明白为何 Fluss 比 Kafka 更适合作为实时数仓的基础底座。

图 3：Fluss/Paimon/Kafka 数据概念对比

Fluss 的数据模型与湖仓体系完全对齐，因此能够实现无缝融合。相比之下，Kafka 与湖仓系统存在本质上的割裂——缺乏 Schema 概念、采用行式存储、不支持库表分区等。在实时数仓应用场景中，这恰恰是 Kafka 最明显的短板。

4. 湖流一体方案核心优势

4.1 流存储成本降低 10 倍

在 Lambda 架构下，为确保数据回溯能力，Kafka 通常需要保留 7 天的数据，导致存储成本居高不下。湖流一体架构则采用不同思路：Fluss 仅保留超短周期的实时数据（例如 6 小时），超出 TTL 的数据由 Tiering Service 自动沉淀至 Paimon 湖表中。如此一来，流存储时间从 7 天骤降至 6 小时，成本直接下降一个数量级。同时，流与批的存储统一为一份视图，无需再维护两套独立的数据链路。

4.2 湖仓分层新鲜度不受层级影响

在 Fluss 加 Paimon 的湖流一体架构中，Flink 流式作业直接读写 Fluss，实时数据流始终能保持秒级延迟。长周期数据入湖的过程与 Checkpoint 解耦，无论数据加工多少层，每层湖表的新鲜度都能稳定在约 3 分钟左右，延迟不会累加。总结来说：实时数据可达秒级，湖仓数据约 3 分钟，且新鲜度稳定，不因层次增加而劣化。

4.3 批查秒级新鲜度（Union Read）

Union Read 是这套湖流一体架构的核心查询能力。当用户发起查询时，StarRocks 会同时从两个数据源拉取数据：Paimon 中的历史快照（Snapshot）和 Fluss 中的实时增量数据（从 Snapshot 对应的 log_offset 开始）。拉取到数据后，在内部进行一次 Sort Merge 操作，合并成一份完整的结果集。这意味着，一个普通的 SELECT 查询即可获得秒级新鲜度的全量数据视图，并且语义上保证 Exactly-Once——数据不重复也不遗漏。

图4：Union Read 工作原理——实时数据与历史数据一次查询合并

5. 湖流一体架构总览

湖流一体架构的核心设计理念可概括为“三个同一份”：

数据同一份： 并非通过双写实现，而是借助 Tiering Service 自动将 Fluss 中超过 TTL 的数据沉淀至 Paimon。一份数据自动流转，省时省力。
元数据同一份： 使用 DLF Omni Catalog 统一管理 Fluss 和 Paimon 的元数据，通过一套 Catalog 即可掌控全部数据资产。
查询入口同一份： 全部采用 StarRocks 作为统一查询引擎，一条 SQL 语句即可获取实时加历史的完整数据。

图5：湖流一体架构总览——一份数据、一份元数据、一次查询拿全

Tiering Service —— 数据自动分层下沉： 在该架构中，Tiering Service 是实现“数据同一份”的关键枢纽。它本质上是一个常驻的 Flink 作业，会自动将 Fluss 中超过 TTL（例如 6 小时）的数据导入 Paimon 湖表，随后清理过期数据。用户无需编写复杂的 ETL 作业，仅需打开配置开关即可。最终，Fluss 与 Paimon 共同构成完整的数据视图：Fluss 提供秒级新鲜的实时数据，Paimon 则承载长周期的历史数据。

6. StarRocks 统一查询入口

在此架构中，StarRocks 扮演着统一查询入口的角色，通过一个 Fluss Catalog 即可接入全部数据，并提供三种查询模式以应对不同场景。

6.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"
);

6.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，三种查询姿势

7. 技术架构详解

StarRocks 在读取 Fluss 数据时，会根据表名后缀自动将查询路由到不同的扫描通道：

7.1 Paimon Scan（历史数据段）

历史数据查询采用 Native C++ 直读链路，完全避免了 JVM 开销。该通道支持列式存储的高吞吐量读取和向量化执行，并能利用 DataCache 加速。数据直接从 OSS 上的 Paimon 文件中读取，充分发挥了 StarRocks 在湖查询方面的性能优势。

7.2 Fluss Scan（实时数据段）

实时数据查询通过 JNI Bridge 调用 Fluss Java Client，复用了官方 Fluss 协议，并通过 Arrow 格式跨边界传递数据。虽然当前仍存在 JVM 开销，但 Arrow 的列式传输已显著减少了行列转换带来的性能损耗。

7.3 Union Read Merge

当用户执行默认查询时，StarRocks 会同时读取 Paimon 的快照 N 以及 Fluss 中偏移量大于 N.commit 的增量数据，并依据主键进行合并，确保 Exactly-Once 语义。这套机制真正实现了“一次查询，同时获取实时与历史全部数据”，这正是其核心价值所在。

图7：StarRocks 读取 Fluss 数据技术架构——Paimon 走 Native，Fluss 走 JNI，Union Merge 合并

8. 未来规划

StarRocks 与 Fluss 的演进方向非常明确，始终围绕着“读取最快、读取最稳”这两个核心目标展开：

8.1 Union Read 2.0：跳过 Sort Merge

当前的 Union Read 在处理主键大表时仍需进行 Sort Merge 合并。未来计划支持 Fluss 的 Delete Vector，通过 Bitmap 标记删除行并直接跳过，从而省去 Sort Merge 过程，显著提升端到端查询性能。

8.2 优化器理解 Fluss

计划接入行数、NDV、Min/Max 等统计信息，支持元数据短路优化，例如 COUNT 查询、Limit 下推、Time Travel 等能力，使优化器能够精准地选择最优执行计划。

8.3 Native 全链路

计划将实时数据段也优化为 C++ 直读，通过 Fluss Arrow 实现零拷贝传输，并集成 DataCache、将谓词下推至 Fluss Server 等功能。最终目标是使 Snapshot 和 Log Split 统一为单个 Native Scanner，彻底消除 JVM 占用。

图8：StarRocks x Fluss 未来规划——Union Read 2.0、优化器增强、Native 全链路

9. 阿里云 EMR Serverless StarRocks 对 Fluss 的适配与增强

阿里云的 EMR Serverless StarRocks 对 Fluss 提供了全面的原生适配，涵盖 Catalog 注册、数据读取、分区裁剪及 Union Read 等一整套能力，并且在每个环节都叠加了商业版独有的性能增强。下表列出了商业版在湖流一体查询场景下的关键能力和增强点：

能力	说明	商业版增强
Fluss Catalog	通过 `CREATE EXTERNAL CATALOG` 注册 Fluss 数据源，支持 SQL 直接查询	提供预置 Catalog 模板，实现一键配置
Native 读取 Paimon 数据	对 Fluss 湖侧（Paimon 格式）数据实现原生 C++ 读取，规避 JNI 开销	采用 Stella 自研算子，性能领先开源版本
分区裁剪	根据分区条件过滤 Fluss 表，避免全表扫描	与内表一致的裁剪优化效果
Union Read	一条 SQL 自动合并 Fluss 实时数据与 Paimon 历史数据	全托管服务，无需用户运维 Tiering Service
Native SDK 接入	StarRocks 通过 Fluss Native SDK 直连，取代 JNI 调用链路	进一步降低读取开销，提升数据吞吐量
读取性能持续优化	持续缩小与内表查询性能的差距，目标控制在 1.5x 以内	在湖流一体场景下，查询性能可对标内表

典型使用方式

-- 1. 创建 Fluss Catalog
CREATE EXTERNAL CATALOG fluss_catalog
PROPERTIES (
    "type" = "fluss",
    "fluss.bootstrap.servers" = ""
);

-- 2. 直接查询：Union Read 自动合并实时 + 历史数据
SELECT region, COUNT(*) as event_count, A VG(speed) as a vg_speed
FROM fluss_catalog.fluss_db.enriched_vehicle_events
WHERE event_time >= NOW() - INTERVAL 1 HOUR
GROUP BY region;

无需借助 Flink 或 Spark 的 ETL 作业，也无需手动 UNION 两张表，一条 SQL 即可查询到秒级新鲜度的完整数据，极大地简化了数据处理流程。

9.1 Stella 引擎独有优化

EMR Serverless StarRocks 采用自研的 Stella 引擎，在 Fluss 湖流一体查询场景中，提供多项开源版本不具备的优化：

Native Reader 性能优化： 对 Fluss Lake Split 实现原生 C++ 读取，消除 JNI 调用的开销；通过向量化批处理与列式裁剪，大幅降低反序列化开销；相比开源的 JNI 方式，查询性能获得显著提升。
DataCache 统一管理： Fluss 外表查询与 StarRocks 内表共享统一的 DataCache 层；热数据自动缓存至本地 SSD，重复查询可直接命中缓存；避免了内表与外表缓存空间冲突的问题（开源版本需手动配置）。
查询优化器增强： Fluss 表与 StarRocks 内表进行 Join 操作时，自动选择最优的 Join 策略；支持跨 Catalog 的全局查询优化（Fluss、Paimon、内表混合查询）。

9.2 场景示例：车联网实时安全大屏

以车联网实时安全大屏场景为例，展示 Fluss 搭配阿里云 EMR Serverless StarRocks 在端到端实时分析中的实际落地效果。

业务需求：

车辆实时事件数据（包括 GPS、速度、报警信息）需要秒级入湖
实时大屏展示车队安全态势（如超速告警、区域分布、趋势变化）
历史数据需支持回溯分析（例如过去 7 天或 30 天的趋势对比）

架构方案：

Flink 实时消费车辆事件流，关联车辆档案维表后，写入 Fluss 宽表
Fluss 配置 table.datalake.freshness = 1min，自动通过 Tiering 将数据同步至 Paimon
StarRocks 通过 Fluss Catalog 的 Union Read 功能，一条 SQL 查询全量数据
QuickBI 连接 StarRocks，实现秒级刷新实时大屏

商业版优势体现：

Flink、Fluss、StarRocks 全链路 Serverless 化，无需管理任何底层基础设施
DataCache 加速高频查询，大屏刷新延迟低于 1 秒
通过 RAM 实现统一权限管理，确保数据安全与合规

9.3 与传统实时数仓方案对比

对于正在评估实时数仓方案（例如 Kafka + Flink ETL + 数据湖 + StarRocks）的用户，我们从架构复杂度、数据存储、ETL 链路、查询实时性、数据一致性、运维成本、存储成本七个维度进行直接对比：

维度	Kafka + Flink ETL + 数据湖 + StarRocks	Fluss + EMR Serverless StarRocks
架构复杂度	4 套独立系统，各自运维	2 套系统（Fluss + StarRocks），全托管
数据存储	Kafka 一份 + 数据湖一份，需双写	Fluss 一份数据，流和湖作为两种视图
ETL 链路	需要 Flink 作业将 Kafka 数据导入数据湖	Fluss 内置 Tiering Service，自动同步
查询实时性	分钟级（取决于 ETL 批次间隔）	秒级（Union Read 直接查询 Fluss 实时层）
数据一致性	需对齐 Kafka 与数据湖的数据口径	原生一致，基于同一份数据
运维成本	高（多系统协调、故障定位困难）	低（全托管 + AI Agent 智能运维）
存储成本	高（需双写数据）	低（单写数据，Tiering 实现文件级转换）

9.4 商业版核心价值总结

最后，总结 EMR Serverless StarRocks 商业版在 Fluss 湖流一体场景下的核心差异化价值：

全托管免运维： Fluss 加 StarRocks 全链路 Serverless 化，一键开通即可使用。
Stella 引擎独有优化： Native Reader、DataCache 统一管理、跨 Catalog 查询优化，使湖流一体查询性能可媲美内表。
端到端一站式方案： 从数据接入到可视化（Flink 到 Fluss 到 Paimon 到 StarRocks 再到 BI），全链路由阿里云一站式交付，RAM 统一权限能够满足企业合规要求。
TCO 总拥有成本更优： 数据单写、Serverless 弹性扩展（按需付费，空闲零成本）、DataCache 缓存加速，其 TCO 显著低于 Kafka 加 Flink ETL 加数据湖再加 StarRocks 的自建方案。

对于正在评估实时数仓建设方案、寻找 Kafka 替代方案，或希望将传统 Lambda 架构迁移至湖流一体 Lakehouse 架构的企业而言，阿里云 EMR Serverless StarRocks 结合 Fluss 与 Paimon 的湖流一体方案，提供了一条开箱即用、成本可控且性能领先的落地路径。全链路 Serverless 免运维、Stella 引擎性能加持，以及 Fluss 原生的流湖融合能力，使其成为替代传统 Kafka 加 Flink 加数据湖系统的最优解决方案之一。