作者：王日宇（霁谦）StarRocks Committer；阿里云技术专家
随着实时看板、业务监控和异常排查等需求增加，数据分析需要更及时地反映业务变化。对使用者而言，查询执行得快只是其中一部分，更关键的是，刚刚产生的数据能否及时出现在分析结果中。
例如，大促期间，运营团队需要持续观察各渠道的成交变化；设备出现异常时，业务人员需要结合最新事件与历史记录定位问题。如果这些数据仍需经过多层同步和加工才能被查询，即使查询本身很快，分析结果也可能滞后于业务现场。
StarRocks 与 Apache Fluss 的组合，为缩短这段等待提供了一条更直接的路径。 Fluss 承接持续变化的数据，StarRocks 提供 SQL 查询与分析能力；对于需要长期留存和历史回溯的场景，还可以结合 Apache Paimon，通过同一张逻辑表查询实时与历史数据。
01 实时分析的难点不只在查询速度
在常见的实时数据链路中，事件可能已经进入 Kafka，但报表所依赖的分析表仍在等待下游同步。采用湖仓架构后，数据能够得到统一管理，但如果多层加工都需要等待上一层湖表提交后才能继续，等待就可能沿着链路逐层累积。
为了同时满足实时看板、历史分析和问题排查，团队往往需要维护多份数据副本和同步任务。链路越复杂，需要核对的数据进度、指标口径和运行状态也越多。
Fluss 为持续变化的数据提供了可访问、可复用的表存储。 上游任务可以持续写入，下游任务可以读取并继续加工，分析引擎也可以直接访问其中的数据。各层流式加工通过 Fluss 交换结果，数据入湖则由独立的 Tiering Service 持续推进，使实时消费不必逐层等待湖表提交。参见 Fluss 湖流一体架构。
在这套架构中，Flink 负责数据接入与流式加工，Fluss 存储并提供实时数据访问，Paimon 承接入湖数据的长期留存，StarRocks 提供 SQL 查询、关联与聚合能力。
图 1：实时段与湖上数据各司其职，StarRocks 提供统一查询入口。需要湖流一体时启用入湖与相应权限配置。
这套架构可以应用于以下三类场景：
-
实时经营分析。 把刚到达的交易、支付或访问事件纳入统计，并与历史趋势一起观察。
-
实时链路排查。 用 SQL 查看日志表或加工结果，验证某批数据是否到达、某个字段是否符合预期。
-
实时与历史联合分析。 设备监控、业务异常分析既关注新变化，也需要较长时间范围的上下文。
02 Fluss 相比 Kafka 和湖仓带来了什么
Fluss 的特点，可以从它与消息系统、湖存储的分工中理解。
Kafka 主要面向事件传递。 发布订阅、服务解耦、消费回放，以及丰富的客户端生态，使其成为消息传递场景中的成熟选择。
Fluss 则以表的形式组织流数据。 它提供日志表和主键表，支持列式读取；主键表还支持更新、删除和按主键访问。这些能力使持续变化的业务数据能够以表的形式被下游加工任务和分析引擎访问。参见 Fluss 与 Kafka 官方对比。
例如，查询一张宽表时，如果只需要渠道、时间和金额等少量字段，按需读取相关列可以减少无关数据的传输；对于状态持续变化的订单，主键表可以记录同一笔订单的更新，使下游能够获取其最新状态。
这些能力属于 Fluss 的存储与数据访问层，SQL 查询、关联和聚合等分析工作仍由 StarRocks 等计算引擎完成。参见 Fluss 存储与访问架构。
图 2：按业务需求选择能力，Kafka、Fluss 与湖仓也可以协同使用。
与湖存储结合时，Fluss 为最新数据提供直接访问能力。 Paimon 等开放湖格式承接数据的长期留存与历史查询，Fluss 则提供实时数据访问。启用湖流一体后，Tiering Service 持续将数据写入湖中，并维护流存储与湖存储之间的同步进度。参见 Fluss Tiering Service。
通过这一分工，实时访问与历史查询可以在同一套架构中衔接，减少为不同查询需求单独维护数据副本和同步链路的工作。实际资源成本则取决于数据保留周期、副本配置、存储用量和计算负载。
这里的“同一张表”指统一的逻辑视图。底层数据仍分布在流存储和湖存储中，由系统协调读取范围与数据衔接，用户无需在查询中手动拼接实时与历史数据。
03 StarRocks 如何把 Fluss 数据变成可用的分析
建立连接后直接用 SQL 查询
StarRocks 通过 Fluss Catalog 访问 Fluss 中的数据库和表，无需先将数据导入 StarRocks 内表，即可使用 SQL 进行查询与分析。
接入前，需要确认 StarRocks 与 Fluss 集群之间的网络连通，并准备连接地址、认证信息及相关库表和底层存储的读取权限。对于湖流一体查询，还需为目标表启用入湖功能，并确保已有可读取的湖快照。
以下示例使用 SASL 用户名和密码认证创建 Fluss Catalog，连接地址、用户名和密码需替换为实际配置：
CREATE EXTERNAL CATALOG fluss_catalog
PROPERTIES (
"type" = "fluss",
"bootstrap.servers" = "<Fluss连接地址>:9123",
"fluss.option.client.security.protocol" = "SASL",
"fluss.option.client.security.sasl.mechanism" = "PLAIN",
"fluss.option.client.security.sasl.username" = "<用户名>",
"fluss.option.client.security.sasl.password" = "<密码>"
);
认证配置需与 Fluss 集群保持一致。除连接地址外，还需确保 StarRocks 能够访问 Fluss 返回的数据服务节点。
假设已有一张追加写入的支付事件表 retail.payment_events ，按 dt 分区，包含渠道字段 channel 和金额字段 amount 。以下 SQL 按渠道统计指定日期的支付笔数与支付总额：
SELECT channel,
COUNT(*) AS payment_count,
SUM(amount) AS payment_amount
FROM fluss_catalog.retail.payment_events
WHERE dt = '2026-10-10'
GROUP BY channel
ORDER BY payment_amount DESC;
示例中的日期与字段仅用于演示。对于已启用 Paimon 入湖的表，默认查询会合并湖上数据与实时增量；对于未启用入湖的日志表，则直接读取 Fluss 中保留的数据。
通过 Fluss Catalog 接入后，可以使用 StarRocks 对数据进行筛选、聚合和排序，也可以与 StarRocks 内表或其他已接入的数据源进行关联分析。如需保存分析结果，还可以通过 INSERT INTO … SELECT … 将结果写入 StarRocks 内表，供后续查询使用。
一条 SQL 如何同时看到实时与历史
这一能力通过 Union Read（冷热数据合读） 实现：查询时，系统依据已记录的同步进度，读取湖中快照及 Fluss 中尚未被该快照覆盖的实时增量，将两部分数据衔接起来。
对于日志表，合读需要对齐两部分数据的读取边界；对于主键表，还需要合并同一条记录的更新与删除，确保结果符合主键表的更新语义。
例如，湖中快照记录的订单状态为“待支付”，而 Fluss 中的实时增量已将其更新为“已支付”，合读结果应反映更新后的“已支付”状态。
图 3：用户查询默认表名，由读取链路协调两层数据；主键表还需处理更新与删除。
通过合读，尚未入湖的最新数据也能参与查询，减少等待入湖带来的分析延迟。数据新鲜度与 SQL 执行耗时需要分别衡量：前者取决于数据接入、加工及查询可见的进度，后者则受扫描量、关联复杂度和资源配置等因素影响。
日常业务分析建议使用不带后缀的默认表名，由系统协调实时与历史数据的读取。对于已启用入湖的追加写入日志表，如需分别检查湖中快照与实时增量，可以使用以下查询入口：
-- 查看本次读取计划中的湖快照部分
SELECT * FROM fluss_catalog.retail.`payment_events$lake` LIMIT 20;
-- 查看湖快照之后、本次查询范围内的实时增量
SELECT * FROM fluss_catalog.retail.`payment_events$rt` LIMIT 20;
近期升级让接入更轻量也让查询更高效
围绕 Fluss 查询，StarRocks 进一步优化了接入方式、数据扫描和历史数据读取路径。
支持未启用入湖的日志表查询。 对于实时链路排查、短周期事件分析等场景，可以直接查询未启用 DataLake 的 Fluss 日志表，无需预先搭建完整的湖流一体链路。后续如需扩大历史查询范围，再配置入湖功能与数据保留策略。
通过列裁剪、分区裁剪和过滤下推减少扫描开销。 查询时，按需读取相关列，并根据分区条件缩小扫描范围；对于能够下推到湖侧的过滤条件，则在读取阶段提前过滤数据，减少后续传输与计算。例如，分析指定日期、指定渠道的数据时，可以结合分区条件与字段过滤，减少无关数据的读取。
优化 Paimon 历史数据的读取路径。 对于满足直接扫描条件的 Paimon 文件，StarRocks 采用原生读取路径，减少跨运行时的数据转换开销；对于仍需合并处理的数据，则通过相应的合并读取路径，保证查询结果符合表的更新语义。
此外，StarRocks 还持续完善连接与分区信息复用，以及计数查询、空扫描和复杂湖分片等场景的处理，减少重复初始化与元数据准备开销，提升不同查询场景下的稳定性。
实际使用时，可以先选择一张日志表，通过 Fluss Catalog 接入 StarRocks，验证日常查询；再根据历史数据保留与回溯需求启用湖流一体，并结合实际看板的查询负载评估性能。
04 后续演进
在现有接入与合读能力的基础上，后续演进将重点关注实时读取效率、计算下推和开放湖生态的扩展。
优化实时数据读取。 探索 Native 客户端与数据交换路径的优化，减少实时读取中的额外开销。目前的 Paimon 文件原生读取主要面向湖侧数据，实时侧的 Native 接入仍属于后续探索方向。
深化计算下推与索引利用。 Fluss 生态规划中的过滤、聚合下推及索引能力，为进一步减少数据扫描与传输提供了空间。StarRocks 可结合这些能力的演进，逐步探索相应的查询优化，具体支持仍需逐项实现。
扩展开放湖格式支持。 本文介绍的湖流一体查询以 Paimon 为基础。随着更多湖格式与统一访问能力的发展，后续可探索接入更多类型的湖上数据，扩大统一查询入口的覆盖范围。
StarRocks 与 Fluss 的组合，将持续变化的数据接入 SQL 分析，并通过与 Paimon 的协同，衔接实时查询与历史回溯。对于已经使用 StarRocks 的团队，这意味着可以沿用熟悉的分析方式，让最新业务变化更及时地进入看板、异常排查和关联分析。
缩短从数据产生到可被分析的等待，让分析更及时地反映业务变化。
相关代码已合入 StarRocks Main 分支，将随下一版本正式发布。后续文章也将结合版本进展，进一步介绍不同能力的使用方式与适用场景。