Paimon与Milvus构建从向量存储到Agentic数据基础设施的AI原生多模态数据湖

演讲者：李钰（Yu Li）｜阿里云 EMR & Milvus 负责人，Apache Paimon PMC Member

摘要

本文基于李钰在 Apache Flink Forward Asia 2026 的演讲内容整理而成，聚焦于 AI 与 Agent 进入生产环境后，数据湖与向量数据库“双系统”架构所暴露的深层结构性问题，并探讨了 Apache Paimon 与 Milvus 基于同一份湖数据进行协同的技术方案。核心议题包括：

• 为何 Agent 与多模态工作负载亟需全新的数据底座
• Paimon × Milvus 统一向量湖架构及其三层就绪度评估
• Serving Index、Open Index 与检索层的分阶段演进策略
• 自动驾驶数据闭环及企业级产品化落地路径

近年来，AI 应用的焦点不断迁移：从模型能力的提升，到 RAG 技术的普及，再到如今能够持续运行、调用工具并与环境交互的 Agent。然而，当 Agent 真正迈入生产环境时，一个曾被低估的挑战变得日益突出：我们现有的数据基础设施，是否能够支撑这种持续运行的 AI 系统？

当下需要讨论的，并非某个单一的技术特性，也不仅仅是提升单次向量检索的速度，而是面向 AI 时代，数据基础设施应当如何重新进行层次划分。

更直白地说：随着 Agent 和多模态应用进入生产阶段，我们是否有可能将数据的存储与治理、在线检索与服务，重新整合到同一份数据之上？

一个核心判断是：未来 AI 数据基础设施的竞争，将不仅仅局限于检索性能。更关键的是，谁能率先将存储、治理、发现与服务融为一体。围绕这一目标，Apache Paimon 与 Milvus 的协同提供了一条值得关注的开源路径：由 Paimon 承担统一湖存储、版本控制和数据治理，由 Milvus 提供高性能、可扩展的向量检索与在线服务能力。

如果只带着一个问题往下读，建议记住这个：既然已有成熟的数据湖和专用向量数据库，为何 AI 工程实践反而愈发复杂？

为何需要 AI 原生多模态数据湖

“两份真相”正成为 AI 数据架构的结构性负担

如今，几乎所有开始落地生产级 RAG、Agent 或多模态检索的团队，都会逐渐遇到一种相似的架构困境：一边是数据湖，用于保存原始数据、特征、训练集和批处理结果；另一边是向量数据库，用于存储 embedding 和索引，承担在线检索任务；两者之间，则是一系列不断增长的 ETL、同步、重刷和 Schema 映射管线。

这种架构在早期阶段看似合理。数据湖擅长存储和批处理，向量数据库则精于 ANN 检索，各司其职。但随着数据规模、更新频率和治理要求的持续提升，系统不得不维护“两份真相”：一份在湖中，另一份在向量数据库中。

数据一旦变更，索引就需要重新构建；Schema 一旦调整，字段映射也要随之修改；线上服务与离线分析可能看到不同时间点的数据；大量冷数据很少被访问，但服务集群仍需常驻。此时，复杂性已不再是“ETL 编写不够好”，也不是增加一个同步组件就能解决的，而是源于架构本身。

这正是我们希望改变的局面：数据不应为了被不同引擎使用，而在“两份真相”之间被反复搬运。

从 RAG 到 Agent，变化的不只是检索频率

为何这个问题如今变得尤为突出？因为 AI 系统访问数据的方式已经发生了根本性变化。过去两年，许多团队经历了一个典型的三阶段演进过程。

第一阶段是静态 RAG。系统将文档切片，生成 embedding，建立索引，并完成一次检索。数据会变化，但速度相对缓慢，整个系统更像是在查询一个知识库。

第二阶段是工具使用（Tool Use）。模型开始连接数据库、API 和工作流，能够在一次会话中执行一系列操作，但整体上仍是一种会话级的增强能力。

第三阶段是生产级 Agent。Agent 持续运行，反复读写，长期持有上下文，线上服务与线下分析开始交织。此时，数据不再是一批静态资产，而是成为 Agent 持续消费、持续生产、持续修正的运行材料。

因此，问题已不再是“向量检索是否足够快”，而是数据底座能否支撑持续的读写、反复的检索、版本演进以及在线与离线的协同工作。

与此同时，数据形态本身也在发生变化。真实的 AI 应用处理的远不止文本 embedding，还包括图片、视频、音频、日志、传感器信号和大量结构化属性。一条向量关联着数十、数百甚至上千个 metadata 字段，这已不再罕见。

传统向量数据库以向量检索为中心，标量通常仅用于过滤，大对象往往需要外置，数据治理能力也相对有限；传统数据湖擅长保存海量结构化和非结构化数据，却长期缺乏原生向量类型和 ANN 查询语义。

真正缺少的并非更多系统，而是一个能将向量、标量、非结构化对象和索引都视为一等公民的数据底座。

双系统架构的四个核心问题

如果将当前双系统架构的代价进行归纳，可以发现四个结构性问题。

第一是重复存储。Embedding 在湖中存储一份，在向量数据库中又存储一份。随着规模扩大，这不仅是存储成本问题，还会演变为数据所有权、治理与血缘问题。

第二是索引冗余与重建。索引通常在向量数据库内独立构建，游离于数据湖的版本、事务和血缘体系之外。当源数据或 embedding 模型发生变化时，索引就需要重新构建，而这一过程很难融入统一的数据治理闭环。

第三是一致性窗口。源数据更新到在线检索生效之间存在延迟，导致难以回答一个基础问题：线上查询所看到的数据，与离线训练和分析所看到的，是否真的是同一份数据视图？

第四是弹性不足。许多向量服务需要常驻在线集群。即使大量历史数据访问频率很低，团队仍需持续为计算和内存付费。

根本原因在于，现有架构并非围绕“同一份数据同时支持服务与发现”这一目标来设计的。

我们需要什么样的 AI 原生多模态数据湖

面向下一阶段，我们希望得到的并非一个更大的封闭系统，而是一套围绕同一份数据构建的能力组合。

它至少应具备四个特征。

其一，统一存储。向量、标量、Blob 和索引应共存于一个可治理、可版本化的底座中。

其二，流批一体。流式写入、批量回填和离线加工应能作用于同一份数据，无需为在线服务与离线分析维护两套组织方式。

其三，一份数据、多种引擎。同一份湖数据应能被在线检索引擎以低延迟方式服务，也能被 Spark、Flink 等计算引擎进行大规模扫描和再加工，且不绑定于某个特定引擎。

其四，弹性计算。常驻服务、按需计算和离线批处理应能根据访问频率和工作负载自由组合，使资源成本与业务需求相匹配。

这并非某一家厂商独有的叙事。Databricks 正从 Lakehouse 一侧向外延伸，Zilliz 正从向量数据库一侧向外延伸，而 Paimon × Milvus 则代表了一条“开源数据湖 + 开源检索引擎”的协同路径。

这些路线都看到了同一个趋势，但一个关键问题仍值得追问：那份数据最终归谁？如果统一存储和治理由独立、开放的湖格式承载，上层的检索与服务引擎就可以独立演进和替换，数据所有权也会更加清晰。

Paimon × Milvus：如何围绕同一份数据协同

为何是 Paimon 与 Milvus

Paimon 与 Milvus 的角色边界相对清晰。

Paimon 是湖底座，负责“存、管、治”。它正在将 Vector、Blob、Data Evolution 和 Global Index 等能力纳入湖内原生语义，使多模态数据能在同一张表中实现持续写入、版本管理和统一治理。

Milvus 是检索与服务引擎，负责“检、服、扩”。它在 ANN、混合检索、标量过滤、分布式扩展和生产级低延迟服务方面拥有深厚积累。

两者协同的重点，并非简单地将两个系统重新拼接，而是通过标准接口和共享数据契约，让它们围绕同一份湖数据工作。

在这套架构中，Flink Streaming、CDC、批量回填和离线计算构成统一写入层；Paimon Table 保存向量、标量、Blob 和索引，并提供版本、治理与 Snapshot；Milvus External Collection 则在服务层提供 ANN、Hybrid Search 与 Filter 能力。

它要解决三个核心问题：消除湖与向量数据库之间的主数据搬运；让计算围绕同一份数据发生；通过快照和 Refresh 机制维持服务侧的数据新鲜度。

一句话概括，就是 One Data First，先建立共享数据平面。

判断“一份数据”是否成立，需看三层就绪度

两个系统能否共用一份数据，不能仅看“接口是否连通”。我们可以用三层就绪度来进行判断。

第一层是语义层：双方是否对 Schema、类型和列语义达成一致。例如，Paimon 中的 VECTOR 与 Milvus 中的 FLOAT_VECTOR 能否建立明确的映射关系。

第二层是物理层：数据是否采用开放格式，另一方能否原地读取，而无需复制主数据。这里需要特别澄清，物理层就绪并不意味着“两套存储引擎内部格式完全相同”，也不要求两边采用同一套寻址布局。真正的关键在于开放格式与可原地访问能力。

第三层是检索层：索引由谁构建和维护，ANN 参数与查询语义如何对齐，标量过滤如何与向量召回协同，以及命中结果如何关联回真实的行数据。

整体来看，Paimon × Milvus 已在语义层和物理层形成了较好的协同基础：双方能够对齐数据类型和列语义，Milvus 也可以围绕湖上开放数据提供服务。下一步需要继续完善的，是索引复用、查询语义和结果关联等检索层契约。下面分别来看 Paimon 与 Milvus 在这些层面的具体能力。

Paimon：将 AI 数据对象纳入湖内

Paimon 的变化，不只是“数据湖也能存向量”。更重要的是，它正在将 AI 数据对象从湖外约定转变为湖内原生概念。

在语义层，原生 VECTOR 类型通过类型系统显式表达维度和元素类型，不再依赖应用层自行约定。

在物理层，Paimon 为向量列提供专用的 Vortex 存储路径，并结合 Data Evolution，使向量列与标量列能够协同演进。图片、视频和音频等大对象，也可通过 Blob 能力纳入同一张表。

在检索层，Global Index 开始成为表级能力，覆盖 BTree、Bitmap、Vector、Full-Text 和 Hybrid 等索引类型。标量过滤、向量检索与真实行数据也被纳入同一个查询模型：先由标量索引裁剪候选 Row-ID，再在候选集合内执行 ANN，最后回读真实行数据。

这意味着，Paimon 正在从“保存 AI 数据”走向“用统一语义组织、索引和治理 AI 数据”。

Milvus：从“复制后服务”走向“围绕湖数据服务”

Milvus 的关键增量，则是 External Collection。

传统路径通常要求先将主数据导入向量数据库，然后才开始构建索引和提供服务。External Collection 希望改变这一点：在 Milvus 已公开支持的外部数据路径上，系统可以扫描外部文件元数据，生成 Manifest 和服务侧查询视图，然后执行 ANN、Hybrid Search 与标量过滤；对于支持 Snapshot 的外部表格式，还可以绑定特定的数据快照。

其中 Manifest、Segment Mapping 或结果回表属于服务执行机制。物理层能够成立的真正原因，仍然是开放数据格式与原地访问能力，而非两个系统内部存储引擎变得完全一致。

因此，这条路线的重要意义并非“把湖数据换一个地方再保存一次”，而是让生产级检索能力能够围绕同一份湖上开放数据展开。

检索层如何演进：先共享数据，再走向开放索引

检索层是这套架构中最需要分阶段推进的部分。

第一阶段，Milvus 通过 External Collection 围绕 Paimon 数据提供服务，但 Serving Index 仍由 Milvus 构建和管理。这条路径在工程上更为直接，也更容易首先满足高 QPS、低延迟的在线服务要求。它解决的是最迫切的问题：先消除主数据副本，让湖与服务层共享同一份数据。

第二阶段，再逐步走向 Paimon Global Index 等开放索引，使索引能够一次构建、多次使用，支持多引擎共享以及在线与离线协同。目前，这条路线仍在持续演进中。

这两条路径都可以建立在同一份开放数据之上，核心差异在于索引由谁持有、是否能被多个引擎复用。

高性能 Serving Index 更适合高 QPS 在线工作负载；开放索引则更强调数据与索引的开放复用、离在线协同和多引擎共享。进一步的检索互操作，还涉及统一 Row-ID、结果回表、标量与向量联合裁剪等机制。

总体来看，Milvus 与 Paimon 的开源集成已具备共享数据平面的基础。其中，Serving Index 路线相对成熟，可以优先满足高 QPS、低延迟的在线服务需求；面向多引擎复用的开放索引，以及标量与向量联合优化等更深层的检索能力，仍将是下一阶段持续演进的重点。

自动驾驶：双系统问题被放大的典型场景

为了理解这套架构的实际价值，可以看一个自动驾驶数据闭环场景。

自动驾驶数据往往达到 PB 级规模，包含图像、视频、时间序列、传感器信号、向量和大量结构化属性。它同时需要两种能力：一方面要做实时相似场景召回和线上分析，另一方面要进行 Corner Case 挖掘、Embedding 去重、训练集构建和模型重算。

如果继续采用传统双系统架构，前面提到的四个问题都会被进一步放大：Embedding 的重复存储会显著推高整体成本；十亿乃至百亿级向量的索引重建会带来漫长的处理窗口；训练与在线检索依赖不同的数据视图；大量低频历史数据仍会长期占用在线服务资源。

统一向量湖则让整个链路围绕同一份数据组织起来。

Flink 持续将传感器数据、元数据、向量和 Blob 写入同一张 Paimon 多模态表；Milvus 围绕 Paimon Snapshot 提供外表查询和向量服务；Spark、Flink 的批处理任务仍在同一张表上执行挖掘、去重和训练集构建。

这样一来，Paimon 专注于持续写入、高效更新和统一治理，Milvus 专注于低延迟检索、高并发服务和弹性伸缩。离线发现与在线服务不再是“概念上同源、工程上分裂”的两套视图，而是真正围绕同一份事实数据展开。

统一数据层，是 Agentic Data Loop 的基础

当在线检索、离线挖掘和持续回写都锚定于同一份数据时，Agentic Data Loop 才能真正实现闭环。

这条链路可以分为四步。

第一，感知与发现。系统从湖中检索相似历史场景，识别分布偏移或 Corner Case。

第二，触发智能处理。下游的自动标注、去重或数据集编排 Agent 被激活，对数据进行修正和重组。

第三，回写与迭代。新的 Embedding、修正后的元数据或训练结果，直接回写到同一张表。

第四，进入下一轮服务。通过快照刷新或增量同步，Milvus 将最新数据纳入服务，结果再次进入后续的发现与处理过程。

这里的统一数据层不再只是存储容器。它既是被查询的数据源，也是持续被加工的数据资产，是 Agent 与模型迭代共享的可持续演进数据基座。

讨论 Agent 基础设施时，我们经常将注意力放在模型和工具调用上，却忽略了底层数据是否一致、可追溯、可持续读写。如果数据副本割裂、更新滞后，上层再复杂的 Agent 编排也会被数据层拖住。

从开源架构走向企业产品化

从开源架构走进生产环境，企业关注的不仅是技术能否跑通，更关心它能否长期、稳定、可治理地运行。除了数据格式和检索能力，生产系统还需要统一的 Catalog、权限、血缘、运维、弹性与 SLA，最终形成完整的数据与服务体系。

在阿里云的产品化方案中，DLF 负责 One Data Catalog、湖存储管理、权限治理和血缘追踪；阿里云 Milvus 则提供托管的 Serving 层，并针对不同工作负载提供两类索引路径。

第一类是面向高 QPS、低延迟在线服务的 Serving Index，由服务层负责索引构建、管理和弹性伸缩；第二类是面向多引擎共享与离在线协同的开放索引，使多个引擎能够复用同一份湖上索引。目前，两条路径均已完成产品侧实现，并在云上智能驾驶场景中完成内部测试验证，即将在 7 月底随正式产品版本对外提供。

对企业而言，这套方案并非若干功能的简单组合，而是一套可以长期运行的能力交付体系：数据纳入统一治理，服务层提供托管运维、弹性伸缩与 SLA 保障，企业还可以根据工作负载，在性能优先和开放复用优先两类路径之间灵活选择。

一条更务实的落地路线

如果组织已经遇到“两份真相”、冷数据常驻成本或线上线下双视图问题，建议分三步推进，不必一开始就改造整个系统。

第一步，先建立 One Data 底座。用 Paimon 多模态表统一承载向量、标量和 Blob 等数据，并接入 DLF 的 Catalog 与治理能力，让数据从进入湖的第一天起就能持续写入、统一管理和完整追踪。

第二步，再接入服务层。引入 Milvus，并根据工作负载选择索引路径：高 QPS、低延迟的在线服务，可以优先采用由服务层持有索引的方式；强调多引擎共享和离在线协同的场景，则可以逐步采用开放索引。

第三步，形成完整的数据闭环。逐步接入 Flink 流式更新、批量重算、数据质量任务和 Agent 工作流，让数据发现、处理、回写与服务连续运转；随着业务需求变化，再扩展另一条检索路径。

这个顺序背后的逻辑很简单：先统一数据所有权和治理方式，再接入 Serving，最后让在线服务与离线处理围绕同一份数据形成闭环。

结语：终局不是更大的封闭库

最后，用五点总结今天分享的核心内容。

第一，数据湖与向量数据库组成的双系统架构，在 Agent 和多模态场景下正逐渐逼近其结构性上限。

第二，Paimon 正在通过 Vector 类型、Vortex、Global Index 和 Data Evolution 等能力，将向量和其他 AI 数据对象拉回湖内原生语义。

第三，Milvus 正在通过 External Collection，从“复制一份数据再服务”走向“围绕湖上数据直接服务”。

第四，当前更扎实的路径是 One Data First：先让服务和计算共享同一份主数据，再逐步走向可复用的开放索引与更深层检索互操作。

第五，这条开源路线仍处于演进阶段，但它带来了更清晰的数据所有权、更开放的架构边界，以及更少的单一引擎锁定。

未来 AI 数据基础设施的终局，并非让某一个向量数据库变得无所不包，也不是再造一个更大的封闭系统，而是让同一份开放湖数据能够被治理、被发现、被检索、被持续加工，并被多个引擎自由复用。

归根结底，决定架构边界的，不只是“谁的检索更快”，而是数据究竟躺在哪里、由谁拥有，以及它能否在不被单一引擎锁定的前提下持续演进。

相关资料

• Apache Paimon Global Index：https://paimon.apache.org/docs/master/append-table/global-index/
• Apache Paimon Vector Index：https://paimon.apache.org/docs/master/multimodal-table/global-index/vector
• Milvus External Collection：https://milvus.io/docs/create-an-external-collection.md
• Milvus Issue #50632：Paimon External Collection — https://github.com/milvus-io/milvus/issues/50632
• Apache Paimon PR #8000：Global Index 外部引擎样板 — https://github.com/apache/paimon/pull/8000

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Paimon与Milvus构建从向量存储到Agentic数据基础设施的AI原生多模态数据湖要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题