从数据湖到多模态湖仓-基于阿里云EMR Serverless StarRocks与DLF Paimon构建AI时代的统一分析检索架构
英文标题：从数据湖到多模态湖仓-基于阿里云EMR Serverless StarRocks与DLF Paimon构建AI时代的统一分析检索架构
本文围绕一个核心问题展开：当数据模态、查询范式和基础设施负载同时变化时，湖仓系统应如何从传统的结构化分析平台，演进为面向 AI 的统一多模态分析检索平台。
3.2 KB
589 B
106.0 KB
62.3 KB
76.9 KB
65.0 KB
78.5 KB
68.0 KB
70.3 KB
79.1 KB
75.5 KB
72.5 KB
68.3 KB
74.6 KB
91.5 KB
16.9 KB
中文
过去十多年，大数据系统的主线相对清晰：以结构化表为主要数据模型，以 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 之间选择合适策略：
系统级优化的价值在于，它可以根据统计信息和执行代价自动选择策略，而不是把选择固定在应用层。
计算层与存储层：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，而不是某个瞬时物理文件位置。
这种设计有两个重要收益：
在场景选择上，湖表更适合数据量极大、时效性要求中等、希望以低成本对象存储承载大规模多模态数据的场景；内表更适合数据量中等、时效性要求更高、需要在新写入数据和索引数据之间做混合访问的场景。二者并不是互相替代，而是在不同数据规模和新鲜度要求下形成互补。
六、湖表 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。
两类核心产品能力
业务价值
这一案例的业务价值在于：一套引擎和一套存储格式替代了多套割裂系统，降低了数据复制和同步成本；标量与向量双路召回结合融合重排，提高了数据集召回质量；阿里云 EMR Serverless StarRocks AI Function 将向量化和结构化抽取纳入 SQL 体系，降低了多模态数据处理门槛。
十二、总结与展望
总体来看，AI 时代正在推动 Lakehouse 从结构化数据底座升级为多模态数据底座。
阿里云 EMR Serverless StarRocks 这一方向的核心目标不是简单增加一个向量索引，也不是将多个系统拼接在一起，而是在统一数据、一致语义和系统级优化之上，构建面向 AI Data、AI Agent 和多模态应用的下一代湖仓架构。后续，StarRocks 社区也会持续将这些经过生产验证的能力逐步贡献到开源版本，并通过云上产品形态服务更多企业的 AI 数据场景。
本文整理自 Flink Forward Asia 2026 · 深圳 主题演讲。
作者：范振（StarRocks 社区 TSC、阿里云开源 OLAP 负责人)
English / 原文
过去十多年，大数据系统的主线相对清晰：以结构化表为主要数据模型，以 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 之间选择合适策略：
系统级优化的价值在于，它可以根据统计信息和执行代价自动选择策略，而不是把选择固定在应用层。
计算层与存储层：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，而不是某个瞬时物理文件位置。
这种设计有两个重要收益：
在场景选择上，湖表更适合数据量极大、时效性要求中等、希望以低成本对象存储承载大规模多模态数据的场景；内表更适合数据量中等、时效性要求更高、需要在新写入数据和索引数据之间做混合访问的场景。二者并不是互相替代，而是在不同数据规模和新鲜度要求下形成互补。
六、湖表 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。
两类核心产品能力
业务价值
这一案例的业务价值在于：一套引擎和一套存储格式替代了多套割裂系统，降低了数据复制和同步成本；标量与向量双路召回结合融合重排，提高了数据集召回质量；阿里云 EMR Serverless StarRocks AI Function 将向量化和结构化抽取纳入 SQL 体系，降低了多模态数据处理门槛。
十二、总结与展望
总体来看，AI 时代正在推动 Lakehouse 从结构化数据底座升级为多模态数据底座。
阿里云 EMR Serverless StarRocks 这一方向的核心目标不是简单增加一个向量索引，也不是将多个系统拼接在一起，而是在统一数据、一致语义和系统级优化之上，构建面向 AI Data、AI Agent 和多模态应用的下一代湖仓架构。后续，StarRocks 社区也会持续将这些经过生产验证的能力逐步贡献到开源版本，并通过云上产品形态服务更多企业的 AI 数据场景。
本文整理自 Flink Forward Asia 2026 · 深圳 主题演讲。
作者：范振（StarRocks 社区 TSC、阿里云开源 OLAP 负责人)