作者：范振，StarRocks TSC Member；阿里云开源 OLAP 负责人
在多模态业务中，找到相似的图片、视频或文档，往往只是分析的第一步。业务还需要结合时间、权限等条件筛选数据，关联订单、设备或实验记录，再进行统计分析。当检索与分析分散在不同系统中，这些操作就需要通过额外的数据传递与任务编排来衔接。
与此同时，同一批多模态数据还要服务特征加工、模型训练和在线检索。随着数据规模与模型版本持续增长，如何让不同计算引擎共享数据，减少重复存储与跨系统同步，成为多模态 Lakehouse 需要解决的重要问题。
Lance 从 AI 数据访问需求出发，将列式扫描、随机读取、数据演进与混合检索结合起来；StarRocks 则通过分布式 SQL 执行，将检索与过滤、多表关联及聚合分析组织在同一查询计划中，让搜索命中的内容直接参与后续业务分析。
StarRocks 于 2025 年启动 Lance 接入，并在多个行业客户的生产场景中持续打磨。本文将从数据访问、分布式检索与物化策略出发，介绍这一组合的接入设计，并结合一个 20 亿级向量的客户案例，说明如何通过单条 SQL 完成混合检索与后续 OLAP 分析。
01 多模态 Lakehouse：共享数据上的检索与分析
多模态 Lakehouse 以对象存储承载数据，通过开放格式，让特征加工、模型训练、检索与分析等计算引擎访问同一份数据。各引擎根据任务特点分工协作，减少重复存储与跨系统同步。
图 1 · 多模态 Lakehouse 的多引擎架构
在这一架构中，检索与分析需要紧密衔接。例如，找到相似影像后，业务还需要关联订单或设备记录，进一步排查问题、统计分布。SQL 可以将范围筛选、内容检索、多表关联与聚合统计组织在同一查询计划中，让检索结果直接进入后续分析。
以下三个典型场景，展示了这类需求：
| 典型行业 | 内容检索与样本组织 | 进一步的关系分析 |
|---|---|---|
| 智能驾驶 | 以雨夜行人漏检为例，限定采集批次和标注版本，检索相似驾驶帧或目标区域，通过 frame_id 定位所属视频与前后帧，整理待复核的样本集合 | 以 frame_id 将命中帧与标注、模型评测记录 Join，并按模型与评测版本筛选；再关联车辆配置，分析命中样本的漏检类型和版本差异，生成补标与回归评测清单 |
| 具身智能 | 以抓取后搬运途中物体滑落为例，限定机械臂型号、物体类别和策略版本，检索相似失败帧，定位 Episode（一次任务执行记录） | 关联失败前后的多视角视频、夹爪状态与动作轨迹，按 Episode 汇总命中任务的重试次数和耗时，并比较策略版本差异，整理补训与回归评测样本 |
| 电商物流 | 除包裹影像外，异常工单文本和分拣运输轨迹也逐步用于生成 embedding；结合仓库与时间条件，按外观、文本语义或轨迹模式检索相似案例，汇集多模态线索 | 以包裹 ID Join 影像、工单与轨迹记录，再关联订单、包装批次及承运商，排查异常是否集中于特定运输路线、作业环节或包装批次 |
02 从 AI 训练出发：Lance 的数据组织与访问能力
计算机视觉与模型训练既要批量扫描数据，也要随机抽取少量样本。使用 Parquet 等列式格式存储这类数据，便于扫描与特征加工，但零散取样可能连带读取、解码较大的页面。Lance 从这类训练需求出发，设计兼顾扫描和随机访问的列式格式，减少取样过程中的无关读取。
图 2 · Lance 的数据与索引组织
Lance 将索引与列数据文件分开组织。升级搜索结构或调整量化方式时，可以复用已有数据，重建相应索引。
使用索引的查询通常先定位候选记录，再按需读取所需列。因此，检索效率既取决于索引搜索，也受到后续数据读取的影响：列文件的页面组织与编码方式，会影响这一阶段需要读取和解码的数据量。
03 StarRocks 的接入架构：从规划到分布式执行
接入 Lance，需要分别组织索引搜索与数据读取：前者负责找到候选记录，后者负责读取这些记录所需的列。两类任务共享同一查询版本，但可以采用不同的并行度。
在查询规划阶段，FE 固定本次查询使用的数据版本与索引覆盖范围，并生成搜索任务。搜索产生候选记录后，读取任务再按 fragment、文件与所需列归组。
图 3 · 索引覆盖与搜索任务划分
对于需要覆盖完整可见数据范围的查询，已被索引覆盖的部分使用索引搜索，未被覆盖的 fragments 则通过补充扫描处理。任务按覆盖范围划分，避免遗漏或重复。调度器结合节点负载与缓存分布，将任务分配到相应 BE。
执行节点内的访问分工
图 4 · StarRocks 与 Lance 的执行分工
Lance SDK 以 Rust 编写。接入 C++ BE，需要把跨语言的数据访问纳入统一的执行与资源管理体系，重点包括以下四个方面。
- Rust 与 C++ 的列式执行衔接
Lance SDK 规划任务内的过滤、索引搜索与读列，DataFusion 提供列式与流式执行；C++ BE 负责 Pipeline、Exchange 与后续关系算子。接入层将 SDK 返回的列式批次转换为 Chunk，衔接 Join、聚合与排序。
- 统一内存管理
Rust 临时缓冲、Arrow 数据批次、在途读取与 Chunk 转换都会产生内存开销，需要纳入同一查询预算，并明确跨语言的数据所有权与释放时机。
数据布局兼容时，可以复用 Arrow 缓冲；需要转换时，则计入额外开销。跨查询复用的索引与元数据缓存，按 BE 级容量单独管理。
- 线程、协程与 I/O 协同调度
索引搜索的计算并行度、Rust 异步任务数与对象存储 I/O 并发需要协同设定，再通过批次缓冲和背压衔接 BE Pipeline 的消费速度。
同时，需要为在途请求与预取深度设置预算，减少线程过量、缓冲堆积，以及异步读取对查询内存的挤占
- 缓存亲和与负载校正
各 BE 独立维护索引与元数据缓存。不可变对象按对象身份复用，行定位与可见性信息则绑定本次读取的 snapshot。
调度器综合缓存分布、任务规模与节点负载选择执行位置，优先复用已有缓存，并通过负载校正分散热点。
04 两种物化策略与后续 OLAP 分析
在分布式 TopK 检索中，各 BE 先产生局部候选，再通过全局归并确定最终的 TopK 结果。轨迹明细、长文本等宽业务列，可以在来源 BE 读取，也可以等全局 TopK 确定后再读取。
如果提前为所有局部候选补齐这些列，最终未入选的记录也会消耗 I/O、解码与网络带宽；如果延后读取，则需要额外的行定位与回捞请求。两种路径的取舍，取决于能够减少多少无效读取，以及为此增加多少定位和调度开销。
StarRocks 将读列位置纳入执行规划，支持在来源端按需补列后，通过 Exchange 传递候选；也支持先完成全局筛选，再补齐所需列。后一种称为全局延迟物化（Global Late Materialization，GLM）。具体路径在计划阶段，根据查询结构、可延迟读取的列与 reader 能力选择。
本节基于 StarRocks 通用物化框架，展示 Lance 的适配设计；索引搜索与回捞的精细代价模型仍在完善。
图 5 · 非 GLM 与 GLM 物化路径
- 非 GLM：在来源端补齐所需列
来源 BE 按需补齐所需列，组成 Chunk 后，通过跨节点 Exchange 传递给下游。
如果 reader 支持分次读列，可以先通过局部过滤或 TopK 收窄候选，再读取输出列。这种方式能够复用来源端的读取与缓存，减少额外的回捞往返。当返回列较窄、全局归并淘汰的候选较少，或行定位与 RPC 成本较高时，更适合采用这条路径。
- GLM：全局筛选后再补列
各 BE 先通过 Exchange 传递行身份、分数与必要列。全局筛选或 TopK 收窄候选后，再在固定 snapshot 下解析行位置，按 fragment、文件归组，批量回捞所需列。返回列与命中记录对齐后，补入 Chunk，继续参与下游计算。
当延迟读取的列较宽、全局筛选淘汰的候选较多时，这条路径可以减少无效读取、解码与传输。同时，也需要计入行定位、RPC 与回捞调度的成本。
两种路径都受到 reader 能力与查询语义的约束。用于候选资格判断、排名和 refine 的列，必须在相应操作前读取；仅用于后续投影或分析的列，可以延后读取。两条路径均可衔接 Join、表达式计算与聚合，由执行计划统一组织读列位置与后续计算。
同一条 SQL 中的检索与后续 OLAP 分析
以包裹破损排查为例，检索选出 100 条相似影像后，还需要读取包裹 ID，关联订单与物流记录，再按包裹去重，统计承运商和包装批次分布。SQL 可以将检索范围、关联关系与统计口径放在同一计划中，让命中结果直接进入后续分析。
图 6 · 同一 SQL 计划中的检索与 OLAP 分析
在图示的 GLM 路径中，全局 TopK 确定后，StarRocks 按来源归组命中记录，批量请求所需列；Lance 在固定 snapshot 下完成定位与读取。StarRocks 再根据数据来源与行身份，将返回列与命中记录对齐，组成 Chunk（列式数据批次），确保分数、包裹 ID 与业务属性对应同一条记录。
补齐后的 Chunk 进入 StarRocks 的向量化执行链路，依次完成 Join、去重、聚合和排序。需要跨节点计算时，Exchange 按关联键或分组键重新分发数据。非 GLM 路径在来源端补列，同样以 Chunk 接入这些算子。
这里统计的是命中包裹的分布，不能据此推算总体破损率。订单与物流的关联，需要按本次分析口径选取有效记录；用于判断候选资格的过滤或 Join，仍应在相应的 TopK 截断前完成。
05 客户案例分析：20 亿级别混合检索分析
一个大型电商轨迹平台，需要结合属性条件检索相似轨迹，再关联业务记录开展分析，同时返回轨迹明细等宽业务列。这要求查询既能高效筛选候选，也能控制业务列的读取开销，并衔接后续关联与聚合。
平台管理 20 亿条、1024 维 Float32 向量，数据由 500 个 fragments 组成，索引组织为 100 个 index segments。
数据规模与索引组织
| 数据与组织 | 规模与容量 | 含义 |
|---|---|---|
| 原始向量 | 8.192 TB | 每行 1024 × 4 = 4096 B |
| 500 个 fragments | 平均 400 万行、16.384 GB / fragment | 仅计原始向量 |
| 100 个 index segments | 平均 2000 万行 / index segment | 索引与数据 fragment 分开组织 |
索引与 refine：根据检索目标配置
索引选型需要兼顾容量与召回；是否启用 refine，则取决于单次查询的延迟与精度目标。StarRocks 支持 query 级设置，同一索引可以采用不同的 refine 配置。
图 7 · 索引选型与 query 级 refine
- 高 QPS、低延迟
本案例实时检索采用 IVF_SQ，设置 TopK=1000 ，并关闭 refine，省去重排所需的原始向量读取与距离重算。
- 更高召回与排序质量
可以开启 refine，通常从 refine factor=4 开始，再根据实际召回率与耗时调整。需要注意，refine 只对已经找到的候选进行重排，召回率仍受索引搜索范围影响。
图中三种配置的容量均包含每条记录 8 B 的 row ID。其中，SQ 每维使用 8 bit；PQ 每条向量使用 128 个 8 bit code。SQ 向量表示与 row ID 的 payload 共 2.064 TB，加上原始向量后为 10.256 TB。IVF 中心、量化参数与文件元数据另计。
宽列返回：选择在全局 TopK 之后物化
本案例按每行 8 KiB 的统一口径，对比两条物化路径中业务列的 payload。100 个独立搜索任务分别返回局部 Top1000，共产生 10 万条候选，再从中选出全局 Top1000。参与过滤与排名的列，不计入这部分可延迟读取的 payload。
图 8 · 宽列返回的物化策略选择
如果在来源端为全部 10 万条候选补齐业务列，payload 为 819.2 MB；如果等全局 TopK 确定后，只为 1000 条入选记录补列，payload 为 8.192 MB，减少 99%。
因此，本案例选择 GLM 路径：先通过 Exchange 传递行定位信息与分数，确定全局 TopK 后，再回捞入选记录的宽业务列，组成 Chunk，参与后续分析。
这里的 99% 指可延迟业务列的 payload 降幅。实际 I/O 还受到编码、缓存与批量请求等因素影响，不能直接等同于端到端性能提升。
业务效果：利用单条 SQL，从偏离线批处理到实时 Ad-hoc 分析
原方案先通过 Ray + Lance 找到 TopK 数据集，再交给 StarRocks 完成关联与聚合，检索和分析之间依赖批次交接。
接入后，StarRocks 将混合检索、TopK、按需读列与后续 OLAP 分析组织在同一条 SQL 中，业务可以直接发起 Ad-hoc 分析，减少中间的数据传递与等待。
图 9 · 单 SQL 分析链路与客户效果
根据阿里云团队在该客户负载下的测试，StarRocks 将端到端数据可用于分析的等待时间缩短至原来的 1/40，从分钟级进入秒级；混合检索性能达到 Ray + Lance 的 16 倍。
06 多模态 Lakehouse 是系统工程：产品协同与持续优化
前面的案例展示了查询执行与物化策略的选择。但要在长期运行中兼顾性能、成本与数据新鲜度，还需要统筹写入、特征回填、索引构建与查询服务。
写入批次影响文件数量与对象存储请求，索引更新节奏决定新数据何时能够被高效检索，资源分配则影响查询延迟与运行成本。因此，对象存储、加工框架、管理服务与 StarRocks 需要围绕这些目标协同运行。
| 产品组合 | 主要职责 |
|---|---|
| OSS / S3 + Lance | 承载原始内容，组织列数据、snapshot 与索引 |
| Ray / Spark | 清洗数据、计算特征并按列回填 |
| 阿里云 DLF | 统一表目录，按配置自动构建并持续维护 Lance 索引 |
| StarRocks | 执行 SQL，统一组织分析、检索与资源调度 |
特征回填后，索引需要及时覆盖新特征，查询则使用对应版本下有效的数据与索引。文件整理、索引维护和资源配置，也需要结合实际检索和分析负载持续调整。
StarRocks 面向混合负载的持续优化
- 联合管理 fragment、index segment 与增量覆盖
避免小文件和过多增量 segments 持续累积，同时兼顾搜索并行度、维护任务大小与负载分布。
Compaction 与索引重建后，需要按新版本更新覆盖范围与行定位信息，并保留可复用对象的缓存。新数据何时可见、何时能够通过索引检索，应分别管理。
- 分开观察搜索、refine、Exchange 与延迟列读取
在 StarRocks 查询指标中区分各类成本，记录候选规模、搜索耗时、原始向量读取量、Exchange 字节和 Fetch / Lookup 延迟。
索引与数据读取的缓存命中情况也需要分别记录，再结合完整查询耗时，判断各项优化的实际收益。
- 让优化器获得更可靠的选择依据
积累过滤选择性、局部与全局收缩比例、列宽和批量读取开销，逐步完善物化策略的成本评估。
对比非 GLM 与 GLM 时，需要固定模型、距离度量、召回目标与候选预算，并覆盖不同 K 值、返回列宽度、冷暖缓存与并发水平，使结果具有可比性。
- 通过计算组与后台调度管理混合负载
交互检索、批量分析、索引维护与特征加工，对资源和响应时间有不同要求。StarRocks 可以通过计算组隔离检索与分析负载，分别配置并发与资源预算。
后台任务还需要协调共享对象存储的带宽与请求压力，控制尾延迟波动。
社区共建与后续推进
StarRocks 在湖上分析中积累的查询优化、分布式执行、数据缓存与资源管理能力，为大规模内容检索提供了计算基础。与 Lance 结合后，训练、检索与分析可以共享湖中数据，检索命中的内容也能直接参与关联、聚合与统计。
作为 StarRocks 社区在多模态 Lakehouse 方向的重要贡献者，阿里云计划将 Lance 接入的核心代码贡献到 StarRocks 社区，让更多用户能够在自己的环境中使用和验证这些能力。
多模态 Lakehouse 是 StarRocks 社区持续投入的方向。欢迎更多开发者和用户带着真实场景与负载参与，通过测试、反馈与代码贡献，共同完善多模态分析与检索能力。