过去十多年大数据系统的主线相对清晰以结构化表为主要数据模型以 SQL 为核心交互方式以稳定的集群和业务负载支撑数据分析。Hadoop、Spark、Flink 以及各类 OLAP 系统基本都建立在这一假设之上。进入 AI 时代后这些基础假设正在发生系统性变化。企业不再只处理结构化数据也需要处理图像、视频、文本、Embedding、JSON、Blob 等多种数据形态数据系统的使用者也不再只有人Agent 和模型会以更高频、更低延迟的方式访问数据同时AI 工作负载对弹性、隔离、成本和可观测性提出了更高要求。本文围绕一个核心问题展开当数据模态、查询范式和基础设施负载同时变化时湖仓系统应如何从传统的结构化分析平台演进为面向 AI 的统一多模态分析检索平台。一、AI-Ready 数据基建面临三类重塑数据模态、查询范式与云原生基建的三重重塑数据模态的重塑从结构化表到多模态一体建模传统湖仓主要围绕结构化表组织数据而 AI 场景需要同时建模结构化数据、半结构化数据、文本、对象以及向量。视频、图像等非结构化对象经过模型处理后会产生 Embedding日志、埋点和异构 Schema 则常以 JSON 或 Variant 的形式存在文档和文本数据还需要全文索引和关键词匹配能力。这意味着数据系统不能只优化单一的列式表扫描而需要同时支撑标量、向量和全文的混合检索。查询范式的重塑从人写 SQL 到自然语言 Agent 调用过去的数据分析以人编写 SQL、查看报表为主系统的核心目标是稳定、准确和高吞吐。现在越来越多的访问来自自然语言接口、Data Agent 或 AI Agent。用户可能通过自然语言描述问题由系统生成 SQL也可能直接表达一个语义检索意图例如找到雨夜机动车加塞的训练样本。这种查询既包含结构化过滤条件也包含向量相似度检索和全文匹配要求系统在一条查询链路中完成联合优化。云原生基础设施的重塑从固定负载到弹性隔离 模型能力结合AI 工作负载具有明显的弹性和突发性既要支持低延迟交互也要隔离业务查询、索引构建、Compaction、ETL 和模型调用等不同任务。因此AI-Ready 的数据基建需要在 Lakehouse 统一数据面之上进一步强化弹性隔离、可观测性、智能运维以及模型能力集成。这三类变化共同指向同一个方向未来的湖仓系统需要从结构化分析引擎演进为能够统一管理多模态数据、统一表达混合检索、统一调度多类工作负载的全模态分析引擎。二、Lakehouse 已经进入多模态时代Paimon 2.0 多模态存储与 Global Row ID 关联模型Lakehouse 的价值已经被广泛验证。它的第一项核心价值是一份数据数据不需要在不同系统之间反复复制从而降低一致性风险。对于数据工程而言一致性是底线相比于延迟或局部性能波动结果不一致往往更难接受。第二项价值是低成本湖仓架构将大规模数据放在对象存储等低成本介质中通过计算引擎按需访问和优化查询路径避免为每一种场景都维护一套昂贵的数据副本。第三项价值是开放性数据以 Parquet、ORC 等开放格式保存避免被单一厂商或单一系统绑定使不同计算引擎能够在统一数据面上协同工作。在 Paimon 1.0 阶段实时更新、LSM Compaction、湖表一致性以及与计算引擎的协同已经形成了较为完整的能力。随着 AI 与 BI 一体化从概念走向生产实践Paimon 2.0 需要进一步承载多模态数据结构化数据仍然可以保存在 Parquet 或 ORC 中图像、视频等对象数据可以保存在 Blob 文件中向量数据和向量索引则可以使用更适合检索的存储形式。关键问题在于——这些不同物理形态的数据必须在逻辑上保持统一。Paimon 2.0 的解法是全局 Row ID每一行数据拥有稳定的 Row ID向量索引、对象文件、标量列和全文索引都可以围绕 Row ID 建立映射。检索时向量索引首先返回 TopK Row ID随后系统再通过 Paimon 的元数据和 Manifest 找到对应的物理文件并回捞相关列。这样索引与物理文件被解耦Compaction 改变的是文件布局而不是数据行的逻辑身份。这是多模态湖仓能够保持稳定性和可维护性的基础。三、为什么需要多模态混合检索传统多系统拼接检索的成本、延迟与一致性瓶颈多模态混合检索解决的是企业 AI 数据准备中的一个典型痛点。当前很多系统会将标量数据放在 OLAP 引擎中将文本放在 Elasticsearch 等全文检索系统中将向量放在专用向量数据库或单机检索库中。一次业务查询往往需要先在 OLAP 中过滤标签再在向量库中做相似度检索再在全文系统中做关键词匹配最后由应用层将三路结果拼接、Join 或重排。这种架构带来三个问题成本高同一份数据要为不同检索系统维护多个副本延迟高多个系统之间缺少统一优化只能由应用层串联执行一致性弱数据在不同系统间同步存在延迟和失败风险同一查询条件下可能得到不一致的结果。在 AI Data 场景中这类查询非常常见。例如训练数据准备可能需要从海量视频片段中筛选雨夜“急刹”加塞等标签同时要求画面语义与某段典型场景相似。它不是单纯的 SQL 分析也不是单纯的向量检索而是标量过滤、向量 ANN、全文匹配和融合重排共同参与的混合检索。统一引擎的目标就是让这些能力在同一份数据、同一套优化器和同一条 SQL 链路中完成。四、StarRocks从 OLAP 走向 Search OLAP 混合引擎StarRocks 面向 AI 时代的能力全景StarRocks 过去在极速 OLAP、实时分析和 Lakehouse 查询方面积累了较多能力。面向 AI 时代StarRocks 的演进方向不是放弃 OLAP而是在 OLAP 之上补齐 Search 能力形成 Search OLAP 混合引擎。从应用层看传统即席查询、BI 报表和实时湖仓仍然是重要场景新增的 AI Data 准备、AI Agent、AI Memory 等场景则需要系统提供向量检索、全文检索、混合检索和 AI Function。数据可以来自业务数据库、日志埋点、IoT、非结构化对象和外部知识源通过 Kafka、Flink CDC、DataX、文档解析和 Embedding 等链路进入统一存储。从存储层看StarRocks 既支持自身内表也支持 Lakehouse 湖表包括 Paimon、Lance、Iceberg 等开放格式。其中Paimon 与 StarRocks 在多模态湖表上的协同最为直接。整体目标可以概括为三条主线Search 场景能力补强全文、向量、混合检索Lakehouse OLAP 持续演进湖表查询性能与开放性AI Agentic 场景拓展AI Function、Memory、Agent 数据面。StarRocks 多模态分析的能力组成全文、向量、混合三类检索能力矩阵StarRocks 的多模态分析检索能力包括全文检索、向量检索和混合检索三类全文检索主要面向日志存储、智能分析、文本匹配和半结构化数据过滤等场景支持 BM25 排序、倒排索引和智能分词。向量检索主要面向 RAG、语义相似度搜索、图像与文本多模态检索等场景支持 HNSW、IVFPQ、DiskANN 等主流 ANN 算法并在系统层面对带标签过滤的 Filtered ANN 做优化。混合检索将标量过滤、向量召回和全文召回统一在同一条查询链路中不仅支持多路召回还需要支持权重配置、RRF 等融合算法以及自定义 Reranker。对于智能驾驶训练数据准备、电商商品精准搜索、RAG 知识问答增强等场景混合检索比单一检索方式更接近真实业务需求。这一能力组合的关键不在于简单叠加多个检索模块而在于让 OLAP 查询、全文检索、向量检索和融合重排共享统一的 SQL 表达、执行框架、缓存体系和数据一致性语义。多模检索整体架构FE、计算层、存储层三层协同的多模检索架构从整体架构看StarRocks 的多模检索需要在 FE、计算层和存储层同时进行增强。FE 层Search 短路径与 Pre/Post-Filter 策略选择FE 需要完成 SQL 解析、CBO 优化、Search 短路径设计以及 Pre-Filter/Post-Filter 策略选择。对于纯向量检索如果仍然经过过重的通用优化流程FE 本身可能成为延迟瓶颈因此需要为 Search 查询提供更短的执行路径。对于带标量过滤的向量查询则需要根据过滤选择率、TopK 大小和索引成本在 Pre-Filter 与 Post-Filter 之间选择合适策略Pre-Filter先用标量条件缩小候选集再在候选集上做向量检索适合过滤选择率高的场景Post-Filter先扩大向量召回再从召回结果中筛选满足标签条件的数据适合向量召回成本更低或过滤条件较宽的场景。系统级优化的价值在于它可以根据统计信息和执行代价自动选择策略而不是把选择固定在应用层。计算层与存储层Cache 统一调度在计算层StarRocks 需要扩展 ANN、全文、Hybrid Search 和 Rerank 等算子并与传统 OLAP 执行引擎协同。在存储层系统同时支持内表专用索引和湖表开放格式索引。引入多模态检索后本地 Cache 的管理也更复杂Page Cache、元数据 Cache、湖表文件 Cache、向量索引 Cache 需要被统一调度才能在有限内存中获得稳定性能。五、Paimon Global Index湖表索引模型Data File × Index Shard × Row ID Range 的湖表索引模型湖表和内表在索引模型上存在本质差异。内表通常围绕 Segment 建索引索引与物理数据文件关系紧密当 Segment 过小、持续写入或发生 Compaction 时索引构建和重建会影响实时性与成本。湖表则更适合通过 Global Index 将索引与物理文件解耦。以 Paimon 为例多个 Data File 可以共同对应一个 Index Shard。每个 Shard 记录一个 Row ID 范围例如[0, 199999] 或 [200000, 399999]。向量索引、全文索引、BTree 索引或 Bitmap 索引都可以围绕 Row ID 范围构建。查询时索引返回的是 Row ID而不是某个瞬时物理文件位置。这种设计有两个重要收益第一Row ID 是每一行数据的稳定逻辑标识因此不同模态的数据可以通过同一个 Row ID 关联第二Compaction 只改变文件的物理组织不改变 Row ID 范围本身因此多数情况下不需要因为物理文件合并而重建索引。在场景选择上湖表更适合数据量极大、时效性要求中等、希望以低成本对象存储承载大规模多模态数据的场景内表更适合数据量中等、时效性要求更高、需要在新写入数据和索引数据之间做混合访问的场景。二者并不是互相替代而是在不同数据规模和新鲜度要求下形成互补。六、湖表 Vector / FTS Search 的两阶段框架检索阶段与回捞阶段的职责分工StarRocks 对湖表的 Vector Search 与 Full Text Search 采用严格的两阶段设计。第一阶段检索阶段Row ID Retrieval系统接收到向量检索、全文检索或混合检索查询后FE 会生成包含 Search 算子的执行计划并将任务分发到计算节点。计算节点扫描已经构建好的索引 Shard每个 Shard 先局部返回 TopK 候选结果。随后系统在全局范围内对各个 Shard 的候选集进行 Merge得到最终候选 Row ID。第二阶段回捞阶段Row Materialization第一阶段输出的是 Row ID而用户最终查询的通常是图像路径、文本、标签、分数、业务主键等列。因此系统需要根据 Row ID 到 Paimon 文件和元数据中回捞对应行并返回完整结果。两阶段设计的优势在于职责清晰第一阶段可以针对索引扫描、TopK Merge 和多路召回做优化第二阶段可以针对 Row ID 到列数据的回捞、行存索引、列裁剪和延迟物化做优化。后续优化方向包括将部分 Merge 工作从 FE 下沉到计算层降低 FE 的 CPU 与内存压力以及根据文件格式和列布局决定是否在打开索引或数据文件时顺带回捞部分标量列。七、内表 Vector / FTS Search 的执行框架内表 Segment 组织下的检索 回捞流程内表的 Search 框架与湖表在整体流程上相似也可以分为检索和回捞两个阶段但它的物理组织不同。内表中向量、标量和其他列通常位于同一套 Segment 体系内因此索引构建、数据新鲜度和回捞策略需要围绕 Segment 管理。在写入较实时的场景下系统不适合为非常小的 Segment 立即构建完整向量索引。更合理的做法是让数据先积累到一定规模或经过 Compaction 形成更稳定的 Segment 后再异步或同步构建 Enhanced Vector Index。对于尚未建索引的新数据系统可以采用索引搜索与暴力搜索混合的方式保证可见性。内表也会借鉴湖表的延迟物化思想先在索引中得到候选 Row ID 或行号完成全局 Merge 后再回到 Segment 中读取真正需要的标量列。反过来湖表也可以借鉴内表在同一文件布局中减少二次回捞的能力。两种表模型的优化方向本质上是在索引效率、数据新鲜度、回捞成本和存储开放性之间寻找平衡。八、StarRocks 多路召回的实现框架全文、向量、标量三路召回在引擎内部的融合执行多路召回是混合检索的核心。它解决的不是是否支持向量检索这样单点能力问题而是如何把全文、向量、标量过滤和业务排序统一到一个系统中执行。如果没有统一引擎应用层通常需要分别访问全文系统、向量系统和 OLAP 系统再自行合并结果。这不仅增加数据搬迁和一致性风险也使优化空间被割裂。StarRocks 的做法是将多路召回放入引擎内部全文召回、向量召回和标量过滤可以并行执行候选集在计算层进行融合和重排最终以 SQL 结果形式返回。这一框架适用于多类场景。例如智能驾驶需要从视频和图像中挖掘特定驾驶场景人群画像不再只依赖结构化标签也会结合文本与语义向量广告素材投放需要同时考虑关键词、视觉语义、商品标签和业务指标。统一执行框架使这些场景能够在同一份数据上完成端到端检索。九、案例演示雨夜机动车加塞的 Fusion 示例标签召回与向量召回在 clip_id 上的 Full Join 融合以雨夜机动车加塞为例可以同时构造两路召回标签/关键词召回在结构化标签、全文字段中检索雨夜加塞等条件向量召回输入一段典型雨夜加塞场景的向量表示寻找视觉语义上相近的视频片段。这个例子要说明的重点是同一个业务意图在不同模态中会形成不同证据融合检索需要把这些证据统一到同一个候选集合中进行排序。单独依赖标签并不充分。标签可能来自模型打标虽然整体准确但仍会受到识别误差、标签粒度和上下文理解不足的影响。例如某些片段确实是加塞场景但打标模型没有准确识别加塞也可能有些片段被标成加塞但实际画面中的行为并不典型。单独依赖向量也不充分因为向量相似度更擅长表达画面语义接近却不一定严格满足业务标签。多路召回的价值在于它让不同证据来源互相补充。具体到实现可以把两路结果理解为两个有序候选表一张表来自标签或全文召回另一张表来自向量召回。系统以 clip_id 作为关联键对所有出现过的候选做 Full Join如果某个片段只被一路召回另一侧的分数就是空值。这样做的意义是不提前丢弃任何一路发现的潜在样本而是在融合阶段统一打分。融合打分可以采用 RRF、加权融合或自定义 Reranker。如果认为向量语义更可靠可以提高向量分数的权重如果认为标签与向量同等重要也可以将两路权重都设为 0.5。经过融合后Demo 中排名最靠前的是 C27、C03 和 C08——这三个片段的共同特点是既被标签或全文侧召回也被向量侧召回说明它们同时满足标签判断正确和视觉语义相似两个条件因此可以作为 Top3 高置信结果。排名后面的 C11 和 C42 则体现了融合检索对召回率的保留能力。它们可能只在一路召回中表现较好或者两路证据没有 C27、C03、C08 那么一致因此置信度低于 Top3但从业务角度看它们仍然可能是足够接近雨夜机动车加塞的有效候选。对于训练数据准备而言这类样本不一定应该被直接丢弃而是可以进入 Top5 或更大的候选集由后续人工校验、自动评估或 Reranker 进一步处理。因此多路召回不是简单求交集也不是简单求并集而是在召回率和精确率之间进行可解释、可调节的排序优化。对于训练数据准备这一点尤其重要因为数据集质量会直接影响后续模型训练或评估效果。十、阿里云 EMR Serverless StarRocks 对多模态检索的增强阿里云 EMR Serverless StarRocks 在开源 StarRocks 的基础上围绕多模态检索场景进行了全面的商业版增强。这些增强覆盖 AI Function 集成、Stella 自研引擎性能优化、Paimon 湖表原生适配、DataCache 统一管理以及全托管免运维等方面使其成为面向 AI Data 场景开箱即用的企业级选择。AI Function让 SQL 直接调用大模型AI Function 将模型调用纳入 SQL 数据处理链路除检索能力外阿里云 EMR Serverless StarRocks 还与大模型能力集成形成完整的多模态数据处理链路。AI Function 让用户在 SQL 中调用外部模型能力对原始对象进行解析、打标、Embedding、结构化抽取或文本生成。在很多企业里多模态数据处理往往由 Python 脚本、离线任务与多个服务拼接完成工程复杂度高。AI Function 提供另一种路径将模型调用纳入数据引擎让用户用 SQL 表达从 Blob 中解析文本“对图片生成标签”对文本生成 Embedding等操作。它与混合检索是互补关系——AI Function 把原始多模态对象转化为可索引、可分析的数据形态混合检索则在这些数据形态之上完成高质量召回。Stella 引擎商业版独有的性能优化阿里云 EMR Serverless StarRocks 使用自研 Stella 引擎在多模态检索与湖表查询场景下有多项开源版本不具备的优化Native Reader 性能优化对 Paimon 湖表数据实现原生 C 读取绕过 JNI 调用开销向量化批处理 列式裁剪大幅减少反序列化成本。在向量索引扫描和全文检索回捞阶段相比开源 JNI 方式查询性能提升显著。查询优化器增强当 Paimon 湖表与 StarRocks 内表 Join 时自动选择最优 Join 策略支持跨 Catalog 的全局查询优化——例如一条 SQL 中同时涉及 Paimon 多模态湖表的向量检索和内表的标量聚合优化器可以统一编排执行计划。Search 短路径进一步压缩商业版在 FE 层针对纯向量检索和混合检索场景做了更激进的短路径设计跳过不必要的 CBO 阶段将向量查询的 FE 延迟压缩到亚毫秒级。Paimon 湖表原生适配与增强阿里云 EMR Serverless StarRocks 对 DLF Paimon 进行了全面的原生适配提供从 Catalog 注册、数据读取、分区裁剪到多模态索引访问的完整能力支持Paimon Catalog 一键注册通过 CREATE EXTERNAL CATALOG 注册 DLF Paimon 数据源SQL 直查商业版提供预置 Catalog 模板一键配置。Native 读取 Paimon 数据对 Paimon 格式数据实现原生 C 读取绕过 JNI 开销。在两阶段检索框架中回捞阶段直接以 Native 方式读取 Paimon 文件性能领先开源版本。分区裁剪按分区条件过滤 Paimon 表避免全表扫描。对于按时间分区的多模态数据如训练样本按日/按批次分区可以显著减少无效 I/O。Global Row ID 索引直通商业版与 Paimon 2.0 Global Row ID 深度打通向量索引返回 Row ID 后系统直接通过 Paimon Manifest 回捞对应列无需中间数据搬迁。DataCache 统一管理引入多模态检索后系统需要同时管理 Page Cache、元数据 Cache、湖表文件 Cache 和向量索引 Cache。阿里云 EMR Serverless StarRocks 商业版在这一层做了统一调度内外表统一缓存Paimon 湖表查询与 StarRocks 内表共享统一 DataCache 层热数据自动缓存到本地 SSD重复查询直接命中缓存避免内表与外表缓存空间冲突开源版需手动配置。向量索引 Cache 智能管理高频访问的 HNSW / DiskANN 索引分片被自动缓存减少湖上索引的远程读取开销使向量检索延迟逼近内表水平。缓存自适应淘汰根据不同 Cache 类型的访问频率和数据体积自动调整淘汰策略在有限内存下获得全局最优的缓存命中率。商业版核心价值总结阿里云 EMR Serverless StarRocks 商业版在多模态检索场景下的核心差异化价值可以概括为四点全托管免运维Serverless 架构一键开通即用无需管理集群基础设施空闲时零成本。Stella 引擎独有优化Native Reader DataCache 统一管理 跨 Catalog 查询优化湖表多模态检索性能对标内表。端到端一站式方案从数据接入实时计算 Flink 版到湖仓存储DLF Paimon到分析检索EMR Serverless StarRocks到可视化QuickBI全链路阿里云一站式交付RAM 统一权限满足企业合规要求。TCO 总拥有成本更优数据统一沉淀在 Paimon 湖上避免多系统数据副本 Serverless 弹性按需付费 DataCache 缓存加速TCO 显著低于向量库 全文引擎 OLAP三系统拼接的自建方案。十一、案例阿里集团 AI Data 场景AI Data 平台端到端链路 —— 从多模态入湖到 Agent 消费阿里集团内部的 AI Data 场景可以体现阿里云 EMR Serverless StarRocks 与 DLF Paimon 结合后的业务价值。该平台主要面向大模型训练数据准备和 AI 应用高质量数据供给要求在低成本、一份数据、开放性和准实时之间取得平衡。端到端数据链路从数据链路看原始文件、Blob、文本、Variant、结构化标签和向量数据进入 Paimon 多模态湖格式AI Function 负责解析文本、Chunking、Embedding 和结构化抽取标量与全文通道使用谓词过滤、倒排索引和 BM25向量通道使用 ANN 索引进行语义召回最终通过 RRF、加权融合或 Rerank 完成多路结果融合。上层可以服务 BI 分析、混合检索 SQL、AI 应用和 Data Agent。两类核心产品能力交互式数据筛选用户输入一个或多个标签、全文条件以及语义描述系统返回 TopK 样本供预览和校验数据集生成系统根据索引召回或半径条件抽取符合要求的数据集合用于训练、评测或后续标注。业务价值这一案例的业务价值在于一套引擎和一套存储格式替代了多套割裂系统降低了数据复制和同步成本标量与向量双路召回结合融合重排提高了数据集召回质量阿里云 EMR Serverless StarRocks AI Function 将向量化和结构化抽取纳入 SQL 体系降低了多模态数据处理门槛。十二、总结与展望总体来看AI 时代正在推动 Lakehouse 从结构化数据底座升级为多模态数据底座。Paimon 2.0 的关键演进通过多模态存储格式和稳定 Row ID将结构化数据、半结构化数据、对象数据、文本数据和向量数据统一到同一张湖表语义之下StarRocks 的关键演进从纯 OLAP 引擎扩展为 Search OLAP 混合引擎使全文检索、向量检索、标量过滤、混合召回和 AI Function 能够在统一执行框架中协同工作。阿里云 EMR Serverless StarRocks 这一方向的核心目标不是简单增加一个向量索引也不是将多个系统拼接在一起而是在统一数据、一致语义和系统级优化之上构建面向 AI Data、AI Agent 和多模态应用的下一代湖仓架构。后续StarRocks 社区也会持续将这些经过生产验证的能力逐步贡献到开源版本并通过云上产品形态服务更多企业的 AI 数据场景。本文整理自 Flink Forward Asia 2026 · 深圳 主题演讲。作者范振StarRocks 社区 TSC、阿里云开源 OLAP 负责人)
