EMR Serverless StarRocks × Lance：多模态分析与检索的云上实践

作者：范振，StarRocks TSC Member；阿里云开源 OLAP 负责人

在 Lance 的客户实践中，我们发现，业务对检索的要求正在向后延伸。找到相似轨迹、驾驶帧或机器人任务片段之后，还需要关联订单、模型版本和执行记录，解释这些样本为什么相似、异常集中在哪里，以及哪些数据值得进一步分析。检索命中的记录，也由此成为下一步业务计算的输入。

当检索和分析分成多个任务执行，结果集的交接、数据读取和批次等待，会拉长整个探索过程。业务希望能够直接提出问题，在同一条 SQL 中完成条件过滤、相似度检索、多表关联与统计分析，并随着问题变化继续追查。这也是阿里云 EMR Serverless StarRocks 接入 Lance 时重点解决的问题。

围绕这一需求，EMR Serverless StarRocks 的企业级云原生内核 Stella，将 Lance 的数据访问与索引能力接入分布式 SQL 执行体系，并针对混合检索、候选归并、物化策略和缓存调度进行优化。自 2025 年启动接入以来，相关能力已通过多个行业标杆客户的实际负载持续打磨。

本文将结合接入架构与大型电商轨迹平台的实践，介绍这些设计如何支撑多模态数据上的交互式检索与分析。

随着 AI 应用深入业务，视频、图像等内容不断被加工为样本、标签与向量，同一批数据也需要同时服务特征加工、模型训练和在线检索。当这些任务分散在多套系统中，各自保存数据副本，存储开销、同步延迟与版本不一致的问题就会逐渐显现。围绕开放格式共享数据、让不同计算引擎直接访问同一份内容，正成为业界建设多模态 Lakehouse 的共同选择：以对象存储承载数据，由加工、训练和分析检索引擎按各自的 workload 分工协作。

图 1 · 多模态 Lakehouse 的多引擎架构

对业务而言，找到相似内容以后，还要关联订单、设备或实验记录。SQL 可以将范围筛选、内容检索与后续统计放在同一关系计划中。以下是三个典型场景：

计算机视觉与模型训练既要批量扫描数据，也要随机抽取少量样本。使用 Parquet 等列式格式存储这类数据，便于扫描与特征加工，但零散取样可能连带读取、解码较大的页面。Lance 从这类训练需求出发，设计兼顾扫描和随机访问的列式格式，减少取样过程中的无关读取。

图 2 · Lance 的数据与索引组织

Lance 将索引与列文件分开组织，升级搜索结构或量化方式时，可以重建索引并复用已有数据。使用索引时，查询先定位候选记录，再按需读取列数据；列文件的页面组织与编码，会直接影响这一步的 I/O 与解码量。

以下介绍的 Lance 接入与执行优化，已在 EMR Serverless StarRocks 的 Stella 内核中落地。接入 Lance 需要分别组织索引搜索与数据读取。FE 固定数据版本和索引覆盖范围，生成搜索任务；命中结果产生后，读取任务再按 fragment、文件与所需列归组。两类任务共享查询版本，可以采用不同的并行度。

图 3 · 索引覆盖与搜索任务划分

对于需要覆盖完整可见数据范围的查询，已索引范围使用索引搜索，未覆盖的 fragments 安排补充扫描。任务按覆盖范围划分，避免遗漏或重复；任务到 BE 的映射由调度器决定，随节点负载与缓存分布调整。

执行节点内的访问分工

图 4 · StarRocks 与 Lance 的执行分工

Lance SDK 以 Rust 编写。接入 C++ BE，需要把跨语言的数据访问纳入统一的执行与资源管理体系，重点包括以下四个方面。

Lance SDK 规划任务内的过滤、索引搜索与读列，DataFusion 提供列式与流式执行；C++ BE 负责 Pipeline、Exchange 与后续关系算子。接入层将 SDK 返回的列式批次转换为 Chunk，衔接 Join、聚合与排序。

接入层需要将 Rust 临时缓冲、Arrow 批次、在途读取与 Chunk 转换开销纳入同一查询预算，明确跨语言的数据所有权和释放时机。兼容布局可复用 Arrow 缓冲，发生转换时计入额外开销；跨查询复用的索引与 metadata 缓存按 BE 级容量单独管理。

索引搜索的计算并行度、Rust 异步任务数与对象存储 I/O 并发需要协同设定，再通过批次缓冲和背压衔接 BE Pipeline 的消费速度。对在途请求与预取深度设置预算，减少线程过量、缓冲堆积以及异步读取对查询内存的挤占。

索引与 metadata 缓存由各 BE 独立维护，不可变对象按身份复用，行定位与可见性绑定读取 snapshot。调度综合已有缓存、任务规模与节点负载选择执行位置，优先复用热数据，并通过负载校正分散热点。

在分布式 TopK 检索中，各 BE 会先产生局部候选，再通过全局归并确定全局 TopK 命中集合。若在全局归并前就为所有局部候选补齐轨迹明细、长文本等宽业务列，未入选记录也会消耗 I/O、解码和网络带宽；延后读取这些列，则需要额外的行定位与回捞请求。

StarRocks 将读列位置纳入执行规划，支持在来源端按需补列后通过 Exchange 传递候选，也支持先完成全局筛选，再补齐所需列。后一种称为全局延迟物化（Global Late Materialization，GLM）。具体路径在计划期依据查询结构、可延迟列与 reader 能力选择。

本节基于 StarRocks 通用物化框架展示 Lance 适配设计；索引搜索与回捞的精细代价模型仍在完善。

图 5 · 非 GLM 与 GLM 物化路径

在来源 BE 按需补齐列，组成 Chunk 后通过跨节点 Exchange 传递给下游。reader 支持分次读列时，可先通过局部过滤或 TopK 收窄候选，再读取输出列，复用本地读取与缓存，减少额外回捞往返。返回列较窄、局部到全局的候选淘汰较少，或定位与 RPC 成本较高时，更适合这条路径。

先通过 Exchange 传递行身份、分数与必要列，在全局筛选或 TopK 收窄候选后，再在固定 snapshot 下解析行位置，按 fragment、文件归组批量回捞。返回列与命中记录对齐后补入 Chunk，继续参与下游计算。延迟列较宽、候选淘汰较多时，可减少无效读取、解码与传输；同时需要计入行定位、RPC 和回捞调度成本。

两种路径都受 reader 能力与查询语义约束。候选资格判断、排名和 refine 所需的列，要在相应操作前读取；只在后续投影或分析中使用的列，可以延后读取。两条路径均可衔接 Join、表达式计算与聚合，物化位置由计划统一组织。

同一条 SQL 中的检索与后续 OLAP 分析

以包裹破损排查为例，检索选出 100 条相似影像后，还需要读取包裹 ID，关联订单与物流记录，再按包裹去重，统计承运商和包装批次分布。SQL 将检索范围、关联关系与统计口径放在同一计划中，命中集合可以直接进入后续分析。

图 6 · 同一 SQL 计划中的检索与 OLAP 分析

在图示 GLM 路径中，全局 TopK 确定后，StarRocks 按来源归组命中记录，批量请求所需列；Lance 在固定 snapshot 下完成定位与读取。StarRocks 再根据数据来源和行身份，将返回列与命中记录对齐，补齐为 Chunk（列式数据批次）。一个 Chunk 按列保存一批记录，同一行位置上的距离、包裹 ID 和业务属性对应同一条命中记录。

补齐后的 Chunk 进入 StarRocks 的向量化执行链路，依次完成 Join、去重、聚合和排序。需要跨节点计算时，Exchange 按关联键或分组键重新分发数据。非 GLM 路径在来源端补列，同样以 Chunk 接入这些算子。

图中只统计命中包裹的分布，不代表总体破损率。订单与物流关联需按本次分析口径选取有效记录；参与候选资格判断的过滤或 Join，仍应在相应 TopK 截断前完成。

我们支持的一个大型电商轨迹平台，需要结合属性条件检索相似轨迹，再关联业务记录开展分析，同时返回轨迹明细等宽业务列。平台管理 20 亿条、1024 维 Float32 向量，数据由 500 个 fragments 组成，索引组织为 100 个 index segments。

数据规模与索引组织

索引与 refine：按检索目标配置

索引选型需要兼顾容量与召回；是否启用 refine，则由单次检索的延迟和精度目标决定。StarRocks 支持 query 级设置，同一索引可以采用不同的 refine 配置。

图 7 · 索引选型与 query 级 refine

本案例实时检索采用 IVF\_SQ，设置 TopK=1000 并关闭 refine，省去重排所需的原始向量读取与距离重算。

开启 refine，可将 refine factor=5 作为调参起点，再根据实际召回率、延迟与原始向量读取量调整。refine 重排已找到的候选，召回还受索引搜索范围影响。

三种配置的容量均包含每条记录 8 B 的 row ID；SQ 每维使用 8 bit，PQ 每条向量使用 128 个 8 bit code。SQ 向量与 row ID 的 payload 合计 2.064 TB，连同原始向量为 10.256 TB。IVF 中心、量化参数与文件 metadata 另计。

宽列返回：选择在全局 TopK 之后物化

每行可延后读取的业务列 payload 为 8 KiB；100 个独立搜索任务各返回局部 Top1000。参与过滤与排名的列不计入本次对比。

图 8 · 宽列返回的物化策略选择

来源端为 10 万条候选补列，对应 819.2 MB；全局 TopK 后只为 1000 条入选记录补列，对应 8.192 MB，业务列 payload 减少 99%。因此，本案例选择 GLM：先通过 Exchange 传递行定位与分数，再回捞入选记录的宽列，组成 Chunk 参与后续分析。payload 按记录数和编码后的向量大小或业务列宽统计，实际 I/O 与传输量还受压缩、读取粒度和缓存影响，payload 的减少比例不等同于端到端提速。

业务效果：利用单条 SQL，从偏离线批处理到实时 Ad-hoc 分析

原方案先由 Ray + Lance 找到 TopK 数据集，再交给 StarRocks 做关联与聚合，检索和分析依赖批次交接。现在，StarRocks 将混合检索、TopK、按需读列与后续 OLAP 组织在同一条 SQL 中，业务可以直接发起 Ad-hoc 分析。

图 9 · 单 SQL 分析链路与客户效果

在该客户负载下，阿里云 EMR Serverless StarRocks 将端到端数据可用于分析的等待时间缩短至原来的 1/40，从分钟级进入秒级；混合检索性能达到 Ray + Lance 的 16 倍。

要让业务长期保持性能、成本与数据新鲜度的综合最优，需要从写入、特征回填、索引构建到查询服务进行统一的系统设计。写入批次影响文件数量与对象存储请求，索引更新节奏影响新数据何时能被高效检索，资源分配则同时影响服务延迟与运行成本。对象存储、加工框架、管理服务与 StarRocks 必须围绕这些指标协同运行。

特征回填后，索引需要及时覆盖新特征，查询则使用对应版本下有效的数据与索引。文件整理、索引维护和资源配置，也应结合 StarRocks 的分析与检索性能调整。

StarRocks 面向混合负载的持续优化

避免小文件和过多增量 segments 持续累积，同时观察搜索并行度、维护任务大小和负载分布。Compaction 与索引重建后，按新版本更新覆盖和定位信息，保留可复用对象的缓存。新数据可见时间与索引可服务时间需要分别管理。

在 StarRocks 查询指标中区分各类成本，记录候选规模、搜索耗时、原始向量读取量、Exchange 字节和 Fetch / Lookup 延迟。索引与数据读取需要分别记录缓存命中，并结合完整查询耗时评估优化收益。

积累过滤选择性、局部与全局收缩比例、列宽和批量读取开销，逐步完善物化策略的成本评估。验证非 GLM 与 GLM 时，固定模型、距离度量、召回目标与候选预算，覆盖不同 K、投影宽度、冷暖缓存和并发水平。

交互检索、批量分析、索引维护和特征加工具有不同的资源目标。StarRocks 可以通过计算组隔离检索与分析负载，分别配置并发与资源预算；后台任务还需要协调共享对象存储的带宽与请求压力，控制尾延迟波动。

本文案例中，业务从分步检索与批量分析，转向了单条 SQL 驱动的实时 Ad-hoc 分析。支撑这一变化，需要同时处理索引搜索、分布式执行、按需读列与后续关系计算，也需要管理不同负载之间的资源竞争。Stella 将这些工作落实到执行内核，EMR Serverless StarRocks 则通过全托管服务、弹性资源和多计算组隔离，让企业能够根据业务的响应、吞吐与成本要求组织分析和检索服务。

后续，阿里云将继续以客户的真实负载打磨 Stella，完善混合检索、物化选路和资源调度，并与 Lance 的数据及索引能力持续协同。

我们也会推动 Lance 接入核心代码向 StarRocks 社区贡献，让云上生产实践与开放生态的建设相互促进。