作者范振StarRocks TSC Member阿里云开源 OLAP 负责人StarRocks 对 Lakehouse 的投入已经持续多年。自 2023 年提出“From OLAP to Lakehouse”技术路线以来社区持续完善对 Delta Lake、Iceberg、Paimon 等开放湖表的支持。数据无需搬离数据湖也可以直接用于交互式查询、多表关联和业务分析。围绕这一目标StarRocks 不断优化查询执行、数据缓存与存算分离架构推动开放湖仓从技术理念走向大规模生产应用。今天Lakehouse 中的数据类型与使用方式都在发生变化。除订单、日志、标签等结构化数据外视频、图像、音频、文档和传感器记录也开始成为分析与计算的直接对象。模型可以从这些内容中提取标签、文本描述和向量等语义信息企业也因此能够以新的方式使用数据根据内容检索样本结合业务记录分析结果再将筛选出的数据用于模型训练与评测。这意味着Lakehouse 不仅需要管理更多类型的数据还要同时支撑扫描、检索、关联分析和训练数据准备等不同任务。Paimon 2.0 在实时湖表能力的基础上进一步连接原始数据管理、特征加工与索引检索为多模态数据的持续加工和使用提供统一的数据基础。Paimon 与 StarRocks 已经在阿里巴巴集团及阿里云客户的生产环境中积累了大规模实践。从淘天的大规模数据分析、高德的轨迹服务到 AI Data 平台的多模态混合检索与训练数据准备这一组合已经覆盖多类核心业务。来自这些场景的持续验证也为双方进一步面向多模态数据协同演进奠定了基础。从结构化分析延伸到多模态检索查询引擎面对的执行任务也随之改变。除了大范围列扫描系统还需要搜索索引、组合候选并根据稀疏的 row IDs 回捞数据。围绕这些新的查询模式StarRocks 全面支持Paimon 2.0让湖上的列式分析与索引检索可以进入同一套 SQL 执行架构。01 Paimon 2.0多模态数据湖的场景与技术基础过去湖仓分析主要围绕结构化的业务记录展开。数据经过采集、清洗和建模形成可以过滤、关联与聚合的表。进入多模态场景后这些分析需求依然存在但视频、图像、音频和传感器数据也成为需要直接处理的对象。以智能驾驶为例一次驾驶异常不仅对应事件表中的一条记录还可能与视频中的特定画面、周围的点云数据以及当时的车辆状态有关。仅分析事件记录可以知道异常发生了却很难进一步解释模型为何在这一刻作出错误判断。要还原完整过程系统需要将原始内容、时序信息和业务记录放在一起检索与分析。公开数据集已经体现出这类数据的规模与复杂性。根据 2025 年10月的官方说明Waymo Open Motion Dataset 包含 103,354 个时长20秒的场景片段将目标轨迹、地图和图像特征等信息关联起来。Google DeepMind 于2023年发布的 Open X-Embodiment则汇集了来自22类机器人的100多万个任务片段。在这些数据集中一次观测不能脱离前后时序、周围环境和任务目标单独理解样本管理也不再只是保存文件还要维护内容之间的关联及其版本变化。类似的需求已经出现在多个行业智能驾驶难例检索与问题复盘。从一次雨夜驾驶异常出发检索具有相似画面的场景进一步限定车型和软件版本再关联道路条件、点云和车辆状态排查是否存在共性问题。命中结果可以整理成可复核、可补标的样本集用于模型评测和训练补样。具身智能任务检索与策略评估。从一次机器人插接失败出发检索相似的视觉状态和动作轨迹结合任务类型、策略版本、接触力与执行结果分析失败原因。相关记录可以形成可回放、可比较的任务样本用于策略评估与数据补采。广告素材检索与效果分析。从一组高转化广告出发检索构图、商品或风格相近的素材再结合投放地区、活动周期以及曝光、点击和转化数据分析不同内容特征的实际表现为创意迭代和投放测试提供依据。游戏资产检索与版本治理。根据参考图或文本描述检索相近的角色与场景资产再结合所属项目、资产版本、授权信息和上线记录判断其是否可以复用形成可追溯的资产清单。这些场景虽然来自不同的行业背后面对的却是相似的数据问题一方面视频、图像和传感器数据体量大、保留周期长需要兼顾存储成本与数据一致性另一方面原始内容还要与持续产生的标签、特征、向量和业务指标保持关联。Lakehouse 为此提供了适合的数据基础。数据可以保留在对象存储中由计算引擎直接访问开放湖表无需针对不同任务重复搬迁和存储完整副本。通过统一的表版本管理分析、检索与训练任务还可以基于同一 Snapshot 读取数据减少跨系统同步带来的成本和版本偏差。但仅仅将多模态数据存入湖中还不够。同一批数据还需要支撑多种计算任务批量扫描与特征提取、基于条件和相似度的样本检索、结合业务记录的关联分析以及面向模型训练的数据集组织。这要求湖表不仅能够管理原始内容还要统一组织持续产生的派生特征与索引让同一份数据能够在加工、检索、分析和训练之间顺畅流转。Paimon 2.0 的核心能力与实现本文重点讨论开启 Row Tracking 与 Data Evolution 的多模态 Append 表其关键能力与实现如下驾驶帧示例从原始媒体到可检索的特征以一条驾驶帧记录为例其特征可以随着模型计算逐步补充。首次写入时采集时间、车型等属性保存为普通列原始媒体通过 BLOB 独立存储Row Tracking 则为这条记录分配 row ID。模型完成计算后可以携带同一 row ID通过 Data Evolution 回填标签、评测结果和向量。其中标签与评分写入普通列本例中的向量使用单独组织的 VECTOR 文件未发生变化的业务属性与媒体文件则继续复用。通过同一 row ID首次写入的数据与后续回填的特征始终对应同一条逻辑记录。标签和向量还可以分别构建标量与向量 Global Index。索引异步构建并提交后只有对当前查询 Snapshot 有效的索引才能参与查询。查询选定 Snapshot 后Paimon 使用该版本下可见的数据文件与有效索引并根据 row ID 按需组合各列数据。原始内容与后续回填的特征仍然属于同一张表StarRocks 可以通过 SQL 对其进行过滤、检索、关联与聚合分析。02 StarRocks 与 Paimon 2.0在同一套 SQL 架构中连接分析与检索从 Delta Lake、Iceberg 到 PaimonStarRocks 已经积累了跨湖表格式的元数据管理、SQL 规划、分布式执行与数据缓存能力。这些基础同样适用于多模态 Lakehouse业务数据仍然需要参与 Join、聚合和排序访问对象存储仍然需要控制 I/O并发查询也离不开资源管理。Paimon 2.0 的 Global Index则在传统列扫描之外为查询引入了新的索引访问路径。通过与 Paimon 2.0 的协同StarRocks 可以在一条 SQL 查询中组合标量过滤、向量与全文检索、BLOB 读取及后续关系计算。例如查询可以先根据时间、车型和标签等条件缩小候选范围再执行相似度或关键词检索命中的记录还可以继续关联车辆、版本和业务指标完成聚合与统计分析。整个过程中数据仍然保留在 Paimon 表中检索与分析基于一致的表版本并由同一套查询执行框架完成。具体来看Global Index 可以根据标量条件返回 row ID 集合并按照 AND、OR 等逻辑关系组合向量索引与全文索引还可以返回候选分数用于后续的归并和排序。标量索引产生的候选集合也可以作为向量检索的前置过滤条件。StarRocks 根据查询条件与执行成本在列扫描和索引访问之间选择合适的路径并统一组织候选归并、数据回捞及后续关系计算。如图所示列式扫描与索引访问是面向不同查询模式的两条数据访问路径但最终都会进入 StarRocks 的关系计算框架继续完成 Filter、Join、聚合、排序和 TopK 等操作。Paimon 负责管理表版本、行身份、列文件与索引StarRocks 则负责访问路径规划、分布式执行、缓存调度和资源管理。在一条查询中扫描与索引访问也可以组合使用谓词与 TopK 如何下推、数据何时物化以及不同算子的执行顺序均由查询计划统一组织。03 从 OLAP 到 Search数据访问路径如何变化OLAP通过 data skipping 缩小列扫描范围元数据裁剪 → 并行列扫描与过滤 → Join、聚合与排序传统的湖上 OLAP 查询主要以列式扫描为入口。查询首先利用分区信息以及文件元数据中的 min/max 等统计信息跳过确定不满足条件的数据文件读取候选文件时Paimon 读取器还可以根据 row group、page 等更细粒度的统计信息继续裁剪数据。这类数据裁剪Data Skipping依据数据范围的摘要信息减少扫描量但无法直接确定最终命中的记录。经过裁剪后保留下来的数据仍然需要被读取、解码并执行行级过滤。在执行阶段StarRocks 以文件或文件内的数据范围组织并行读取任务按查询需要读取相应列批量完成解码与过滤再将结果送入 Join、聚合和排序等算子。这条路径适用于报表查询、场景统计及较大范围的关联分析优化重点是减少实际扫描的数据量提高批量读取与计算吞吐并尽可能让不同执行节点之间的负载保持均衡。Search先搜索索引再按稀疏 row IDs 回捞索引搜索 → 候选组合或排名 → row ID 定位 → 按需回捞与后续计算与列式扫描不同Search 以索引作为数据访问入口根据标量条件、关键词或向量相似度直接找到候选记录。标量索引通常返回 row ID 集合向量和全文索引还可以同时返回距离或相关性分数。StarRocks 对不同条件产生的候选结果进行组合、归并与排名再根据入选的 row IDs 读取查询所需的列继续参与过滤、Join、聚合等关系计算。数据回捞时Paimon 根据查询 Snapshot 中的 row ID 元数据定位对应的数据文件再由读取器按需读取相应列。对于使用 Data Evolution 的表同一条记录的不同列可能存储在多个文件中还需要依据行身份和数据版本重新组合。当候选记录较少时这条路径可以显著缩小数据读取范围。但索引命中多少条记录并不能完全代表回捞成本如果少量 row IDs 分散在大量文件中仍然可能产生较多对象存储请求。因此实际开销还取决于候选数量、命中文件分布、查询投影列以及缓存状态。StarRocks 面向 Search 的执行适配从列式扫描扩展到索引检索不只是增加一种数据读取方式。索引搜索、候选归并与数据回捞具有不同的并行边界和资源特征也需要查询引擎在调度、物化时机与访问路径选择上作出相应适配。协同调度索引搜索与数据回捞。StarRocks 已有的分布式执行与数据缓存能力为 Paimon 查询提供了并行调度基础。向量和全文索引可以按照 index shard 拆分搜索任务返回的 row IDs 再用于定位需要读取的文件与列。由于索引搜索与数据回捞的任务边界不同两者需要分别设置并行度并结合缓存位置和节点负载进行调度。回捞阶段还可以按照目标文件合并批量请求复用元数据与数据缓存减少对象存储请求和跨节点传输。候选归并与延迟物化基于 StarRocks 的分布式归并和全局延迟物化能力查询可以先交换体量较小的 row IDs 与分数完成全局候选归并和排名。媒体地址、场景描述等仅用于最终输出的列可以在 TopK 结果确定后再依据入选的 row IDs 批量回捞从而减少无效的数据读取、解码和跨节点传输。但并非所有列都能延后读取。如果某些字段需要参与过滤或 Join并会影响候选记录能否进入最终排名就必须在确定 TopK 之前完成相应计算精排所需的原始向量也可能需要提前读取。数据回捞后仍可进入 StarRocks 既有的向量化执行链路继续完成关联与聚合。例如选出相似度最高的100个驾驶帧后可以进一步关联车辆信息并按软件版本聚合分析命中样本的版本分布。按整体成本选择访问路径StarRocks 的 CBO 已经可以利用统计信息评估执行代价并结合谓词下推和 Join 顺序组织查询计划。引入 Paimon 索引访问后成本评估还需要进一步覆盖索引搜索规模、候选数量、命中文件分布以及 Data Evolution 带来的列合并成本并将这些因素与后续关系计算统一考虑。索引访问并不一定在所有情况下都更快。当候选记录过多或分布在大量文件中时直接进行列式扫描可能更加经济对于使用 ANN 的向量查询还需要在既定召回目标下比较查询延迟与资源开销。最终目标是让优化器基于端到端成本在扫描与索引访问之间选择更合适的执行路径。04 Paimon 2.0 最佳实践从写入到查询的数据管理结合实际落地经验Paimon 多模态表的数据管理可以归纳为三件事优化文件数量与布局、有序回填并整理特征以及及时构建和刷新索引。它们分别影响 StarRocks 的数据裁剪与列扫描、按需读取与列数据组合以及索引搜索、候选归并和数据回捞成本。因此查询性能不能只从 SQL 执行阶段观察还需要结合文件布局、特征文件和索引覆盖等后台状态综合判断区分问题来自查询访问路径还是底层数据组织与维护。下图展示了 Paimon 不同管理动作如何改变数据与索引状态并进一步影响 StarRocks 的查询成本。写入与 Compaction让文件布局服务查询根据常用查询条件设计分区按写入规模控制文件数量时间、业务域等常用过滤条件可以作为分区设计的参考帮助查询缩小读取范围。但分区粒度过细或者单次写入的数据量过小都会产生大量小文件。以1 TiB数据为例如果平均文件大小为1 MiB理论上将产生约105万个数据对象当平均文件大小提高到256 MiB时对象数量约为4096个。文件数量大幅减少后元数据处理和对象存储访问的压力也会相应降低。但文件并非越大越好仍需结合数据写入时效、任务并行度、查询裁剪效果和读取吞吐综合评估。让 Compaction 能力与数据增长速度相匹配小文件持续累积会增加 manifest 处理、文件打开和对象存储请求等开销。需要持续观察文件数量、大小分布和 Compaction 任务积压并结合 StarRocks 查询侧的扫描量、对象请求数与缓存命中情况判断文件整理是否真正改善了查询性能。本文讨论的 Row Tracking 表采用 unaware Append 模式其文件组织方式与主键表不同因此不能直接套用主键表的 bucket 规划策略。实际配置时需要结合数据写入速度、文件增长情况和查询访问特征为 Compaction 分配合适的资源与执行频率。Data Evolution让特征回填可追踪、可维护按列回填并记录特征的来源与版本模型升级后可以只写入新增或发生变化的特征列继续复用未变化的业务属性与原始媒体减少重复写入大体积数据的成本。回填时还需要同步记录模型版本、计算时间和处理状态确保特征的生成过程可追踪。不同模型或不同版本生成的向量可能不属于同一特征空间查询时需要明确可比较的范围。Row Tracking 负责维护派生特征与原始记录之间的行对应关系特征本身的业务含义、生成方式和版本关系仍需由业务侧管理。把列文件合并与索引更新纳入回填计划多次局部更新可以减少对未变化数据的重复写入却也可能增加查询时组合多个列文件的成本。因此需要观察常用查询投影涉及的文件数量并协调安排特征回填、Compaction 和索引刷新避免写入成本降低后读取成本持续上升。当被索引的特征列发生变化时还需要验证索引覆盖范围与当前数据版本是否一致。对于可能重新分配 row IDs 的维护操作则应同步评估其对现有索引及外部引用的影响。Global Index按条件、规模与召回目标配置不同索引解决的问题不同不能仅根据字段类型直接选择。实际配置时还需要结合查询条件的选择性、数据规模、索引覆盖范围以及对检索精度和延迟的要求综合判断。用 index shard 平衡并行度与任务开销向量索引与全文索引可以通过 index shard 控制单次构建和搜索的规模。shard 数量过多会增加并行任务调度与候选结果归并的开销单个 shard 过大则会提高单个搜索任务的计算量与资源需求。BTree、Bitmap 等索引还有各自的数据排序和范围组织方式不能使用同一种 shard 策略概括所有索引。index shard 也不等同于表分区或 bucket前者服务于索引的构建与搜索后两者主要决定表数据的组织与分布三者需要分别规划。评估完整查询并核对索引覆盖索引搜索只是查询链路的一部分。评估性能时需要固定模型版本、距离度量与召回目标分别观察冷热缓存状态下的索引搜索、候选归并和数据回捞耗时并结合候选数量、命中文件分布及查询投影列判断实际成本和配置效果。DLF 托管维护把维护状态与查询表现对齐阿里云数据湖构建 DLF 可统一管理 Global Index 的异步构建、自动 Compaction、Snapshot 清理、分区生命周期及废弃文件清理。团队可以将索引覆盖范围、维护任务积压和资源消耗与 StarRocks 的查询延迟、扫描量及缓存表现结合起来评估据此调整维护资源与执行频率。数据写入成功与索引可供查询是两个需要分别观察的状态。DLF 负责湖表与索引的持续维护StarRocks 根据查询版本规划扫描或索引访问并完成后续关系计算。两部分能力共同影响数据从写入完成到可被高效检索的时间因此维护策略需要同时兼顾可检索时效、查询性能与资源成本。05 后续工作StarRocks 在混合负载下的系统优化随着 Paimon 多模态表承载更多业务StarRocks 不仅需要同时处理低延迟检索与复杂 OLAP 查询还要应对特征回填、索引构建和 Compaction 带来的数据变化与 I/O 竞争。后续优化将围绕负载隔离、索引感知的查询规划以及查询执行与湖表维护的协同展开让同一套执行架构更好地适应不同类型的负载。1. 通过 StarRocks 计算组与调度机制隔离混合负载交互式检索关注稳定的尾延迟批量分析则更关注整体吞吐。StarRocks 可以使用不同计算组分别承载这两类查询并独立设置并发限制、资源预算和扩缩容策略。后续还需要结合查询特征优化任务调度、缓存复用与热点数据处理减少高吞吐任务对在线检索的干扰。除了计算资源StarRocks 的数据读取与后台维护任务仍会共享对象存储带宽。因此还需要将前台查询的读取压力与 Compaction、索引构建等后台任务的 I/O 消耗统一评估合理分配共享存储资源。2. 让 StarRocks 查询规划明确感知索引覆盖数据写入完成与索引就绪之间通常存在时间差。StarRocks 需要根据查询 Snapshot 中可用索引及其覆盖范围规划数据访问在查询语义和读取器能力允许的情况下对尚未被索引覆盖的数据安排补充读取如果业务选择只检索已经建立索引的数据则需要明确当前可检索的数据范围。后续还需要在查询计划和性能指标中体现这些差异评估补充读取带来的实际开销让业务能够在结果完整性、数据时效和查询延迟之间作出明确选择。3. 将 StarRocks 查询指标用于湖表维护决策持续写入和特征回填会不断产生新的数据文件与列更新文件。Compaction 不及时会增加元数据处理和查询时的列合并成本执行过于频繁则会占用存储带宽与计算资源并扰动已有缓存。因此需要结合 StarRocks 的查询延迟、数据读取量和缓存命中率等指标协调调度 Compaction、特征回填与索引构建并根据任务积压和在线查询压力调整优先级。对于可能重新分配 row IDs或涉及被索引列变化的维护操作还需要同步安排索引更新与查询服务切换确保维护过程不会影响查询结果的完整性与一致性。StarRocks 已经在结构化 Lakehouse 查询中积累了查询优化、分布式执行、数据缓存和资源管理等能力。面向多模态数据这些能力正在从传统的列式分析进一步延伸到索引检索、候选归并与按需回捞让不同的数据访问路径能够进入同一套 SQL 计算框架。Paimon 2.0 则进一步连接原始内容、派生特征与索引使多模态数据能够在湖中持续加工和演进。StarRocks 与 Paimon 的协同不是简单地为湖表增加一种检索能力而是尝试让数据管理、内容检索和关系分析基于同一份湖上数据完成。随着分析与检索继续融合多模态 Lakehouse 正在成为 StarRocks 社区值得长期投入的方向。StarRocks × Paimon 也有机会成为 AI Data Infra 中连接数据管理与查询计算的重要组成部分。欢迎更多开发者和用户带着真实场景参与讨论、验证与贡献共同推动这一方向逐步落地。
