导读：
本文主要介绍 Apache Doris 5.0 针对多模湖仓的核心演进：
核心理念：统一检索走向开放湖仓，基于 Doris 构建统一的多模态数据分析平台。
开放格式深度集成：对 Iceberg、Paimon、Lance 等主流开放格式进行深度读写集成。
多模数据分析增强：对 Variant、Vector、GEO、Blob 等多模数据类型进行深度适配。
应用场景：统一实时多模数据分析平台，赋能 Agent 实时上下文、具身智能等更多 AI 场景。
过去十多年，数据平台主要围绕结构化表与 SQL 建设：把数据汇聚到数仓，通过稳定的批处理和 OLAP 查询支撑报表与经营分析。
如今，AI 正在改变这套系统的基本假设。
企业需要同时处理业务表、JSON、日志、文档、图片、音频、视频、Embedding 和模型输出；数据的使用者也从分析人员扩展到应用与 AI Agent。一次真实请求往往既包含结构化过滤，也包含全文与向量召回，还需要关联最新业务状态、权限和历史指标。
传统做法是把不同能力拆到不同系统：对象存储保存原始内容，湖仓保存表数据与元数据，搜索引擎负责全文检索，向量数据库负责语义召回，OLAP 系统负责指标分析，应用层再拼接结果。每套系统都解决了一个问题，却把数据一致性、版本对齐、权限治理和结果融合留给了用户。
与此同时，开放格式正在走向多模态。AI 工作负载让开放格式的边界从结构化表扩展到动态属性、Blob、Embedding 与模型结果，Iceberg、Paimon 和 Lance 分别面向长期分析事实、实时更新数据和 AI 数据集，企业可以继续按工作负载选择合适的格式。由这些开放格式共同承载结构化、半结构化与多模态数据，就是本文所说的多模湖仓。
Doris 5.0 面向多模湖仓的思路，是把统一的重点放在查询和执行，而不是要求所有数据进入同一种存储：数据留在各自最合适的开放格式中，由 Doris 提供统一的检索、分析与实时服务。
图 1：开放格式多模湖仓总体架构。Iceberg、Paimon、Lance 与 Fluss 承载不同类型的开放数据资产；Doris 位于统一查询与计算层，理解格式语义，将混合检索、跨源关联、MPP OLAP、实时服务与权限控制连接成一条执行链路。
从 4.x 到 5.0：统一检索走向开放湖仓
Apache Doris 4.x 已经在内表上构建起面向结构化、半结构化和向量数据的高性能统一检索与分析能力，用户可以在一套系统中组合 SQL 分析、全文检索、向量检索和实时更新；对 Iceberg、Paimon 等开放湖格式，则以结构化数据的查询分析为主。
Doris 5.0 将沿着统一检索这条主线继续演进，把内表上已经验证的能力延伸到开放湖仓：Iceberg 与 Paimon 中的 Variant 数据进入统一的读写链路，Paimon 和 Lance 获得原生全文与向量检索能力，新增的 Fluss Catalog 则可以联查 Fluss 中的实时数据与分层到 Paimon 的历史数据，进一步提升数据分析实时性。
图 2：从 4.x 到 5.0 的能力演进。4.x 在内表提供统一检索与 OLAP，并对 Iceberg 和 Paimon 提供结构化 SQL；5.0 将统一查询扩展到开放湖仓，增加 Variant 读写、原生向量检索，以及 Fluss 实时数据与 Paimon 历史数据的联查。
Doris 5.0 将在各开放格式与统一执行层上提供如下能力：
- Iceberg：在成熟的读写、时间旅行、行级更新和表生命周期能力之上，新增 Iceberg V3 Variant 的读取与写入，覆盖 plain 与 shredded 两种布局。
- Paimon：从只读 Catalog 走向完整读写，支持
INSERT、INSERT OVERWRITE、UPDATE、DELETE、MERGE、DDL，以及 Variant、全文与向量索引的读写，为实时湖仓与多模态数据演进建立统一入口。 - Lance：引入面向多模态 AI 的原生读取与检索能力，支持 Catalog、并行扫描、列裁剪、谓词下推、向量与全文检索，以及向量索引管理。
- Fluss：新增 Fluss Catalog，支持读取日志表与主键表，并通过 Union Read 联合查询 Fluss 中的实时增量数据与分层到 Paimon 的历史数据。
- Doris 统一执行：将 Doris 内表、开放湖表、全文与向量召回、跨源 Join、聚合、窗口计算和权限过滤连接成一条 SQL 链路。
从多系统组合走向统一平台
多系统拼接的问题不只是系统数量多。真正困难的是同一业务实体在多套系统中拥有不同更新时间、不同版本和不同权限边界。一件已下架的商品、一台正在维修的设备或一个已被撤回的文档，仍可能被过期向量召回并交给 Agent。
把统一放在查询与执行层之后，数据的分工反而更清晰：开放格式继续保存长期数据与多模态资产，Doris 内表承载需要高并发与低延迟的实时业务事实，Doris MPP 引擎在同一条查询中完成检索、过滤、关联和分析，应用不再需要在多个系统之间搬运和拼接结果。同一业务实体的状态判断与权限过滤在这一层统一完成，过期候选不会再绕过它到达 Agent。
图 3：多模湖仓数据架构演进。从传统多系统拼接走向 Doris 统一执行，数据保留在合适的开放格式中，Doris 统一查询、计算与服务。
OLAP：从“召回候选”走向“判断业务结果”
向量或全文检索只负责发现候选，真正的业务问题通常还需要 Join、聚合、窗口计算和多维排序。
例如，以图搜商品不能只返回视觉相似度最高的商品，还要关联库存、区域可售、价格、转化率和退货率；设备故障诊断不能只找到相似日志，还要比较型号、固件版本、传感器指标和维修结果。
无论候选来自 Doris 内表还是开放湖表，Doris 的价值都是让检索结果直接进入成熟的 MPP OLAP 执行链路，把“相似”转化为“当前有效、符合规则并值得行动”的业务结论。
Variant + 全文 + 向量：让不同证据在一条 SQL 中协同
模型生成的数据通常不是稳定宽表：OCR、Caption、标签、工具调用参数和评估结果会随着模型版本持续变化。Variant 提供灵活的半结构化承载方式；全文检索保证关键词与规则的准确命中；向量检索扩大语义召回；结构化条件则约束时间、状态、权限和业务范围。
Doris 5.0 让开放湖表中的 Variant 数据、全文与向量索引进入同一条 SQL，多模态数据不必为了获得检索能力而复制到额外的索引系统。
Physical AI：从一条记录走向一个完整 Episode
智能驾驶、机器人和工业设备产生的数据不是静态文档，而是连续的“观察、决策、行动、反馈”过程。分析的最小单位也不再是一张图片，而是一个带有时间、空间、设备状态、模型版本和业务结果的 Episode。
一个机械臂抓取失败的 Episode 可能同时包含 RGB-D 画面、3D Pose、关节与力矩、规划轨迹、控制指令、模型输出、设备日志和最终分拣结果。图片能够解释环境，轨迹能够解释动作，传感器数据能够解释执行过程，业务结果才告诉团队任务是否真正成功。
开放格式负责让这些数据长期保存、演进并可被不同工具共享；Doris 则按 Episode 将多种证据组织成一次可交互查询：先用时间、设备和状态过滤，再用全文与向量召回相似场景，最后关联模型版本和业务结果，比较失败率、重试率与任务耗时。
图 4：Physical AI Episode 分析闭环。Doris 将多传感器证据、模型上下文和业务结果组织为可复用的数据闭环。
Agentic AI：用实时分析填补模型与业务上下文之间的空白
大模型可以理解通用知识，却天然缺少企业当前时刻的状态：订单是否已取消、库存是否充足、设备是否在线、客户是否仍有权限、某个异常是否正在集中爆发。
因此，Agent 面对的核心矛盾不是“能不能生成 SQL”，而是能不能持续获得新鲜、可信、可解释且符合权限的数据上下文。
实时写入：让业务变化直接进入开放湖仓
Doris 对 Iceberg 的集成已经从可查询的数据源升级为可高效写入的开放数据底座，INSERT、INSERT OVERWRITE、CTAS 与行级更新均已落地。Doris 5.0 将把同样的写入能力带到 Paimon，并为 Iceberg 与 Paimon 补上 Variant 写入。
用户可以继续使用统一 SQL，将结构化数据与 Variant 直接写入开放表，不必先落入 Doris 内表再额外建设一条同步链路；实时业务事件、工具调用参数和持续变化的模型结果，因此可以直接沉淀为开放数据资产。
在执行链路中，Doris BE 分布式并行生成数据文件，FE 协调快照与原子提交，并负责幂等重试和失败清理。高效写入、提交一致性与 Schema 演进由 Doris 统一处理，应用无需自行拼装开放表事务。
实时分析：用最新的开放数据构造 Agent 上下文
写入 Iceberg 或 Paimon 的订单、设备状态、行为事件和模型衍生结果可以被不同计算引擎共享；Doris 直接查询这些最新数据，结合内表中的实时业务事实，经过跨表关联与权限过滤，为 Agent 构造新鲜、可验证的业务上下文。
对于新鲜度要求更高的事件流，新增的 Fluss Catalog 通过 Union Read 把 Fluss 中的实时增量与分层到 Paimon 的历史数据合并为同一张表来查询。Agent 拿到的上下文因此既包含完整历史，也包含刚刚发生的变化。
图 5：按需选择开放格式的 Agentic AI 实时闭环。Doris 面向用户选择的 Iceberg 或 Paimon 提供读写与 Variant 能力，面向 Lance 提供读取和多模态检索，再以统一 SQL 与 MPP OLAP 构造 Agent 上下文。
基于 Doris的多模湖仓业务场景
场景一：面向客户服务 Agent 的实时决策
知识文档、产品图片和相似故障样本保存在 Lance 中，订单、工单和历史服务数据保存在 Iceberg 与 Paimon 中，最新库存、保修与客户状态进入 Doris 内表。
Agent 收到客户问题后，Doris 统一完成语义召回、关键词匹配、权限与状态过滤，再关联维修成功率和库存情况。结果不再只是“一段最相似的文档”，而是当前客户真正可以执行的处理方案。
场景二：Physical AI 高价值 Episode 筛选
智能驾驶或机器人团队把视频、点云和 Embedding 保存在 Lance 中，持续变化的模型输出和任务结果以 Variant 写入 Paimon，历史评估结果沉淀在 Iceberg 中。团队要回答的不是“哪些 Episode 相似”，而是“哪些 Episode 值得投入标注、训练和复盘”。
沿用上文的 Episode 查询链路筛选之后，高置信异常进入训练与回归集，证据不一致的 Episode 进入人工复核，按模型版本聚合的失败率与接管率则用于判断新策略是否真正改善了特定场景。
场景三：工业质检从相似缺陷走向根因分析
质量工程师上传一张缺陷图片，Doris 从 Lance 中召回视觉相似样本，从 Variant 与全文字段中匹配缺陷描述，再关联 Paimon 中持续更新的设备事件和 Iceberg 中的批次、工艺与维修历史。
系统最终输出缺陷是否集中发生、涉及哪些设备和批次、不同模型版本的识别效果，以及后续批次良率是否恢复，把一次相似图片搜索升级为完整的质量分析闭环。
结语：数据留在开放格式，检索与分析交给 Doris
Doris 面向多模湖仓的核心方向只有一条：让内表上已经验证的统一检索与实时分析能力，同样作用于 Iceberg、Paimon、Lance 与 Fluss 中的数据。数据不必为了检索和分析离开开放格式，结构化数据、Variant、全文和向量也不必分别进入不同系统。Doris 成为这些数据之上的统一执行与服务层：
- 用统一 SQL 访问 Doris 内表和多种开放格式。
- 用 Variant、全文、向量和结构化过滤理解不同形态的数据。
- 用 MPP OLAP 把召回结果转化为业务指标与决策。
- 用实时写入补足 Agent 所缺少的最新业务状态。
- 用统一的权限过滤保证应用与 Agent 只看到各自应当看到的数据。
围绕 Doris 5.0，我们将针对 Iceberg、Paimon、Lance、Fluss 等开放格式陆续推出系列文章，深入介绍相关能力的技术原理、性能测评与典型落地场景。
目前，Iceberg、Paimon、Lance 等多模湖仓能力已合入 Doris 4.2 发版分支，将随 4.2 版本于 9 月底正式发布；Fluss 等更多能力也已进入 Doris 主干分支，并计划随 Doris 5.0在年底发布。
对于正在评估 Iceberg、Paimon、Lance 等开放数据格式，或有实时湖仓、多模数据分析等实际需求的用户，可通过 Doris 小助手（ApacheDoris_Official）了解。我们可以提供针对具体业务场景提供技术交流、方案评估与测试支持，帮助你更快完成验证和落地。
