Apache Doris+ Paimon 2.0：构建 Agentic AI 数据闭环

摘要：Apache Doris 5.0 多模湖仓预告（2）｜场景方案篇：Agentic AI 正推动企业 AI 从一次性问答走向持续的"感知---检索---分析---行动---反馈"。Paimon 2.0 统一管理持续演进的业务事实、多模态数据与索引，Doris 通过统一 SQL 打通向量检索、实时分析与结果写回，共同为 Agent 构建新鲜、可信、可验证的业务上下文。SelectDB 已提供相关商业预览版本。

作者｜李文强，Apache Doris PMC 成员、SelectDB 多模湖仓负责人

大模型决定 Agent 能理解什么，数据平台决定 Agent 在此时此刻能知道什么、能相信什么，以及行动之后能留下什么。Agentic AI 正在把企业 AI 从一次性的问答，推向持续的"感知---检索---分析---行动---反馈"。

Agent 不仅需要文档和知识，还需要最新的订单、库存、设备状态、图片、视频、向量、模型输出和历史结果；一次真实请求也不只是语义召回，而是向量与全文检索、结构化过滤、跨表关联、指标计算和权限判断的组合。这对数据平台提出了两个新的要求：底层数据必须能够以开放形式持续更新和演进，上层引擎则必须把多模态检索、实时分析与结果写回连接成一条执行链路。

Apache Paimon 2.0 与 Apache Doris 正是在这两个层面形成互补：Paimon 2.0 负责统一管理持续变化的业务事实、多模态内容、模型特征与索引；Doris 负责用统一 SQL 完成读取、写入、向量检索、关系计算和应用服务，为 Agent 构造新鲜、可信、可验证的业务上下文.

一、Agentic AI 的核心挑战

传统 BI 主要回答"过去发生了什么"，传统 RAG 主要回答"哪些文档与问题相关"。Agentic AI 还需要进一步判断：当前状态是否允许执行、不同证据是否相互印证、历史上类似行动产生了什么结果，以及这次行动如何进入下一轮上下文。例如，一个工业故障诊断 Agent 收到新的缺陷图片后，不能只返回几张视觉上相似的历史图片。

它还需要回答：这些缺陷是否来自同型号设备和同一工艺阶段？发生前后的传感器指标是否异常？相关设备是否正在维修？类似问题是否正在集中出现？哪种处理方式在历史上真正改善了后续批次良率？这类请求暴露出四个新的数据挑战。

1.1 上下文信息：持续生长的多模态数据

一条业务记录不再一次生成完成。订单、设备和用户状态先到达，图片、视频和日志随后产生，OCR、Caption、Embedding、模型评分和人工标签再由不同任务异步补全。模型升级后，同一份数据还会增加新版本的特征。因此，Agent 需要的不是一张静态宽表，而是一份能够持续增加字段、内容、特征和索引的数据资产。

1.2 检索只产生候选，业务分析才能产生答案

向量检索能够找到语义或视觉上相似的对象，但不能单独判断库存、权限、设备状态、时间范围和业务结果。真正可执行的 Agent 上下文，必须把向量或全文召回与结构化过滤、Join、聚合、窗口计算和业务排序结合起来。

1.3 Agent 需要新鲜且一致的上下文

业务事实和模型特征如果分散在湖表、对象存储、向量数据库和搜索系统中，就会拥有不同的更新时间、版本与删除状态。一件已经下架的商品、一台正在维修的设备或一份已撤回的文档，仍可能被过期索引召回并交给 Agent。

1.4 Agent 的行动必须回到数据闭环

Agent 会产生新的分类、摘要、风险评分、工具调用结果和处理状态，人工复核也会生成最终标签。如果这些结果只能停留在应用侧，下一次分析仍然无法利用最新反馈。数据平台必须同时支持读取和写回，并保证写入的事务一致性。因此，Agentic AI 所需的不只是一个向量数据库，而是一条完整的数据链路：多模态数据持续演进，索引持续覆盖，业务事实保持新鲜，检索结果能够分析，行动结果可以写回.

二、Paimon 2.0：让 Agent 所需的数据持续演进

Paimon 过去的能力重心，是通过 Flink 持续接收数据库 CDC 和消息流，在对象存储上维护支持更新、删除、快照和增量读取的实时湖表。Paimon 2.0 进一步把管理对象从"持续更新的结构化行"扩展为"持续生长的多模态数据资产"。

• BLOB 用独立文件承载图片、视频和音频等大对象；查询未选择该列时，不必读取对象内容。

• VECTOR<t, n> 为 Embedding 提供固定维度语义和专用存储布局。

• VARIANT 承载结构灵活的事件、模型输出和工具调用参数，并可将常用字段拆解为类型化子列。

• Data Evolution 允许模型只补充或更新变化的列，不必反复重写未变化的大对象和业务字段。

• Global Row ID 将数据文件、BLOB、向量、索引和删除状态对齐到同一条逻辑记录。

• Global Index 把标量、全文和向量索引纳入湖表的元数据与快照体系。

这些能力的关键价值，不是把所有数据强行放进同一种文件，而是让不同模态采用合适的物理布局，同时保持同一张表、同一个 Snapshot 和同一条记录的语义一致性。新写入数据与索引覆盖范围也可以被识别，并通过补建索引或不同查询模式处理新鲜度。

Paimon 2.0 解决的是 Agent 数据如何保存、更新、演进和建立索引。它并不单独完成跨表关联、全局 Top-K、实时指标计算、权限判断和高并发服务。要把这些开放数据变成 Agent 可以使用的上下文，还需要 Doris 的查询与执行能力.

三、Doris 深度集成 Paimon：把开放数据变成 Agent 上下文

Doris 面向 Paimon 2.0 的重点，不是把 Paimon 文件当作普通 Parquet 扫描，而是同时打通三条路径：快照一致的湖表读取、Vector Index 驱动的多模检索，以及标准 SQL 写入 Paimon。

3.1 读取最新业务事实：保持 Paimon 表语义

Doris 通过 Paimon Catalog 发现库表并缓存元数据，在一条 SQL 内绑定一致的 Snapshot 和 Schema。查询规划理解 Manifest、Primary Key 合并、Deletion Vector、增量范围、Time Travel、Branch 和 Tag，避免把 Paimon 主键表退化为普通文件读取。这让 Agent 可以在指定快照上获得一致的业务状态，也可以通过增量查询持续感知订单、库存、设备和用户状态的变化。

3.2 向量检索：让 Vector Index 进入 Doris 查询计划

Doris FE 负责规划并下发 Split，BE 通过 C ABI 调用 Paimon Rust Reader。向量查询先读取 Vector Index 并行检索索引分片并合并候选，再把候选范围继续下推到文件、Row Group 和 Parquet Page；确认命中后才读取向量、BLOB 元数据或其他宽列。Rust 侧结果通过 Arrow C Data Interface 进入 C++ 并转换为 Doris Block。

候选集合随后进入 Doris MPP 引擎，继续完成标量过滤、跨表 Join、聚合、权限判断、精排和全局 Top-K。这意味着向量检索不再是 Doris 旁边的另一套孤立系统，而是分布式 SQL 计划中的候选生成阶段：Paimon Vector Index 负责找到相关数据，Doris 负责判断这些数据在当前业务上下文中是否有效、是否重要、是否值得行动.

快手的社区共建与生产实践已经验证了这条路径：Paimon 外表通过 Rust Reader 接入 Doris，数据规模覆盖百万级到十亿级，Top-K 从 100 到 100 万，并通过候选下推和按需物化控制宽向量的读取成本。

3.3 实时写入：标准 SQL 写入 Paimon

Agentic AI 的数据链路不能止于读取。如果 Doris 查询产生的聚合结果、模型标签、风险评分和人工复核状态仍要依赖独立的 Spark 或 Flink 作业写回，系统就会再次出现事务边界分裂和额外运维链路。

面向 Doris 4.2，Paimon Catalog 从只读走向读写一体，覆盖：

• INSERT INTO ... SELECT 与 INSERT ... VALUES，将查询结果或应用数据追加到 Paimon。

• INSERT OVERWRITE，覆盖非分区表、静态分区或动态分区数据。

• UPDATE、DELETE 与 MERGE，更新 Primary Key Table 中的业务状态、模型标签和人工反馈。

• CREATE TABLE 及 Schema 演进，管理字段增加、删除、重命名和类型调整。

• Variant 读写，使结构持续变化的模型结果和工具调用参数能够直接进入开放湖表。Doris 根据 Paimon 的分区与 Bucket 规则在 BE 之间分发数据并并行生成文件，再由 FE 聚合多个 Writer 的 Commit Message，形成一个原子可见的 Paimon Snapshot。发生失败或重试时，提交协调器负责终止、清理、去重和幂等恢复，避免产生部分可见或重复提交的数据。这使 Agent 产生的结果可以回到同一份开放数据中，成为下一次查询和决策的上下文。

四、执行框架：一次 Agent 请求如何完成检索、分析与写回

Agent 请求中的向量检索执行路径：先用 Paimon Vector Index 收敛候选，再由 Doris 完成业务分析。一条向量查询进入 Doris 后，执行过程可以分为三个阶段：

1. 规划上下文。 Doris FE 解析 Vector SQL，绑定本次查询使用的 Paimon Snapshot 与 Schema，并生成并行 Split。

2. 检索与按需读取。 BE 通过 C ABI 调用 Paimon Rust；Vector Index 产生 Top-K 候选，读取器再按照候选范围裁剪文件、Row Group 和 Page，只物化命中列。

3. 生成业务答案。

   1. Arrow 数据转换为 Doris Block，进入 MPP 引擎完成 Join、Filter、聚合、精排与全局 Top-K，再通过 SQL、API 或工具调用返回给 Agent。

   2. 当 Agent 或人工确认产生新的标签、状态和处理结果时，Doris 启动另一条写入路径：Nereids 生成 DML 计划，数据路由到 BE 并行 Writer，Commit Message 返回 FE 聚合并原子提交为新的 Paimon Snapshot。新的结果由此进入下一轮增量读取、索引补建和 Agent 分析。

   3. 进一步原生化后，Doris 将直接消费 Paimon Global Index Result，根据 Global Row ID 读取命中行，并理解索引覆盖范围、fast / full / detail 新鲜度模式和当前快照的 Deletion Vector。Manifest、索引分片、向量页和命中数据页也将通过分层本地 Cache 分别管理。

五、客户实践：快手让向量检索回到 Paimon 湖表

在快手生产实践中，向量和业务数据保留在 Paimon，Doris 统一完成检索、回表与分析。快手面对的核心问题------如何在已有 Paimon 实时湖仓上提供大规模向量检索，同时继续保持业务数据、向量、权限字段和更新状态的一致性。

如果把向量及其过滤字段、返回字段复制到独立向量数据库，就需要长期维护第二份业务数据和同步链路。随着模型版本、业务状态和删除数据持续变化，检索系统很容易返回已经过期或无法与当前业务状态对齐的结果。

快手最终选择让向量和业务数据继续保存在 Paimon Primary Key Table 中，并将向量检索能力接入 Doris 外表查询：

1. Paimon 表以内联方式保存业务字段和 2048 维向量，使用 IVF-RQ Vector Index 召回候选，远端 Alluxio 为数据与索引读取提供缓存。

2. 用户继续使用 Doris SQL。Doris FE 规划并下发 Split，BE 通过 C ABI 调用 Paimon Rust Reader。

3. Paimon Rust 并行执行向量检索并合并候选；候选范围继续下推到文件、Row Group 和 Parquet Page，避免预先扫描和解码完整向量列。

4. 只需要业务标识时，查询可以跳过宽向量物化；需要返回向量时，再通过候选标识关联回表，只读取命中的页面和记录。

5. 读取结果通过 Arrow C Data Interface 转换为 Doris Block，继续参与过滤、Join、聚合和 Top-K 等 MPP 计算。

生产验证覆盖了千万级与亿级数据：公开测试使用 1600 万和 1.28 亿条 2048 维真实向量，Top-K 覆盖 100、1 万和 100 万。Paimon 外表链路的召回率为 96.0%～99.6%；在"远端 Alluxio 缓存的 Paimon 外表"与"本地缓存的 Doris 内表"的对比中，查询耗时为后者的 1.07～4.18 倍，其中 Top-K 为 100 万时差距收敛到 1.07～1.36 倍。

验证了一个更重要的架构结论：即使面对亿级高维向量和超大 Top-K，用户也可以保留 Paimon 中的开放数据，通过 Doris SQL 完成向量召回和业务分析，而不必先把整份数据复制到 Doris 内表或另一套向量数据库.

对 Agentic AI 而言，这意味着检索结果天然可以继续关联 Paimon 中最新的业务状态，并进入 Doris 的权限过滤、指标计算和关系分析。Agent 获得的不只是相似对象，而是与当前业务事实一致、可以继续验证和采取行动的上下文。

六、如何上手使用

对于已经使用 Flink + Paimon 的团队，第一步无需改变现有数据链路，只需在 Doris 中创建 Paimon Catalog：

CREATE CATALOG paimon_catalog PROPERTIES (
    'type' = 'paimon',
    'warehouse' = 's3://example-bucket/warehouse',
    's3.endpoint' = 'https://object-storage.example.com',
    's3.region' = 'region-id',
    's3.access_key' = 'YOUR_ACCESS_KEY',
    's3.secret_key' = 'YOUR_SECRET_KEY'
);

通过 Doris SQL 进行结构化分析：

SELECT device_model, defect_type, COUNT(*) AS defect_count
FROM paimon_catalog.quality.inspection_records
WHERE event_time >= NOW() - INTERVAL 30 DAY
GROUP BY device_model, defect_type
ORDER BY defect_count DESC;

在社区共建的向量检索链路中，通过 Doris SQL 表达 Top-K 查询：

SELECT id
FROM paimon_catalog.quality.vector_items
ORDER BY l2_distance_approximate(embedding, [...])
LIMIT 100;

分析完成后，把聚合结果直接写回 Paimon：

INSERT INTO paimon_catalog.quality.daily_defect_summary
SELECT DATE(event_time), device_model, defect_type, COUNT(*)
FROM paimon_catalog.quality.inspection_records
GROUP BY DATE(event_time), device_model, defect_type;

对于需要持续修正状态的 Primary Key Table，通过 MERGE 合并人工复核或模型新结果：

MERGE INTO paimon_catalog.quality.inspection_records AS target
USING review_results AS source
ON target.record_id = source.record_id
WHEN MATCHED THEN
    UPDATE SET review_status = source.review_status,
               defect_type = source.defect_type
WHEN NOT MATCHED THEN
    INSERT (record_id, review_status, defect_type)
    VALUES (source.record_id, source.review_status, source.defect_type);

七、结语：让 Agent 使用正在发生的业务事实

Agentic AI 的数据挑战，不是简单增加一个向量字段或向量数据库，而是让持续变化的业务事实、多模态内容、模型特征、检索索引和行动结果保持一致，并在需要时快速转化为可验证的上下文。

Paimon 2.0 为这些数据提供开放的存储、更新、演进与索引基础。Apache Doris 则把 Paimon 的快照读取、Vector Index、MPP OLAP 和标准 SQL 写入连接起来，让 Agent 能够完成"感知变化---检索证据---分析判断---执行行动---写回反馈"的持续闭环。

对 Doris 用户而言，这意味着不必为了 AI 再维护一套封闭的数据副本：数据继续留在 Paimon，检索与分析由 Doris 统一执行，查询结果和 Agent 反馈再通过 Doris 写回开放湖表。Paimon 让 Agent 所需的数据持续演进，Doris 让这些数据持续转化为可以信任和采取行动的业务上下文.

未来，我们还将围绕 Apache Doris 5.0 多模湖仓，针对 Iceberg、Paimon 等开放格式陆续推出系列文章，深入介绍相关能力的技术原理、性能测评与典型落地场景。欢迎阅读。

目前，Iceberg、Paimon、Lance 等多模湖仓能力已合入 Doris 4.2 发版分支，将随 4.2 版本于 9 月底正式发布。对于正在评估 Iceberg、Paimon、Lance 等开放数据格式，或有实时湖仓、多模数据分析等实际需求的用户，可以在官网进一步了解。