AI 成为主流负载后，数据基础设施将如何演进？｜Apache Doris 2026 Roadmap

在过去几年中，数据基础设施的演进始终围绕一个核心问题展开：如何更快地分析数据？

但进入 2026 年，这个问题正在被重新定义。随着 AI 应用的爆发式增长，数据系统不再只是分析工具，而逐渐成为 智能系统的一部分。数据不再只是被查询，而是被 Agent 调用、被模型理解、被系统实时消费。

在这样的背景下，Apache Doris 社区提出了 2026 年的年度主题：

Scale Intelligence, Accelerate Insight

如果说过去 Doris 关注的是更快的数据分析，那么在 2026 年，我们要回答的问题是：

当 AI 成为主流负载之后，数据库应该演进成什么样子？

回看 2025 年，Apache Doris 的演进路径其实已经显露出这一变化的方向。

过去一年，社区发布了两个重要版本——3.1 与 4.0，分别在数据分析能力与检索能力上实现了关键突破。

在 3.1 版本中，进一步夯实了 Doris 在半结构化数据分析场景与 Lakehouse 上的基础能力，并在大量生产环境中得到稳定应用。

• 在半结构化数据分析上，围绕面向 JSON 的 Variant 类型，持续完善功能并优化性能，同时提升倒排索引与全文检索在空间利用率与可扩展性上的表现，并引入更灵活的 tokenizer 插件机制；
• 在 Lakehouse 方向，增强了对 Iceberg、Paimon 等外部数据源的支持能力，物化视图与查询优化能力持续提升，同时优化了数据写入与更新性能。

在 3.1 版本中，大量的精力被投入到一个看似比较局部的能力上——JSON，在当时主要是为日志、事件等半结构化数据服务。但进入 AI 时代，这类结构不稳定、模式不固定的数据，正在成为主流数据形态。

到了 4.0，这种变化进一步加速。

相较于 3.1，4.0 的核心演进可以概括为“混合检索与分析能力”的建立。越来越多的业务负载从结构化与半结构化数据，延伸至非结构化数据分析场景。从数据库视角来看，这一变化本质上对语义检索能力提出了更高要求。

以典型应用为例，企业需要对音频、视频、图像等非结构化数据进行 embedding，将其转化为向量形式存储，并在此基础上实现语义检索。

基于这一趋势，Doris 在 4.0 版本中正式引入了 Vector Search 能力，从而实现在同一引擎内对结构化数据、半结构化数据以及向量数据的统一检索。

而这，也让 Doris 的定位发生本质的转变：从一个分析型数据库，走向一个能够在 AI 时代同时承载分析与检索的统一数据平台。

进入 2026 年，AI 正在从应用层快速渗透至数据基础设施层。

首先，数据形态发生显著变化。以 Agent 交互、模型输出与用户行为记录为代表的数据，大量以 JSON 形式存在，且在规模与结构上高度不确定。这使问题不再只是能否支持 JSON，而是：

在 schema 持续变化、列数不断膨胀的情况下，如何仍然保持高效的存储与分析能力？

由此延伸出的，是 AI 可观测性（AI Observability）问题。围绕 Agent 行为日志展开分析，正在重塑传统以 trace、logs、metrics 为核心的分析方式，成为理解系统运行机制与识别行为模式的重要手段。

与此同时，AI 数据还带来了更高并发与更强实时性的要求。单个 Agent 请求往往会触发大量底层访问，从而显著提高系统对并发处理能力与响应时效的要求。未来的使用模式，将更强调快速反馈，而非长时间等待复杂推理过程完成。

此外，统一平台的重要性进一步提升。企业更倾向于在同一数据基础上，同时支持分析、检索等多样化需求，从而降低系统复杂度并保证数据一致性。

围绕这些变化，Doris 在 2026 年的演进可以从四类关键场景来理解。

01 半结构化数据分析 & AI 可观测性

AI 应用带来的一个直接变化，是 JSON 等半结构化数据的快速增长。问题的关键在于如何在深层嵌套结构、列数持续扩展的情况下，仍然保持可接受的存储成本与查询性能。与此同时，随着 Agent、LLM tracing 等新型应用快速发展，围绕 JSON 日志的分析也正逐步成为 AI 可观测性的重要组成部分。

• 在技术路径上，持续增强 Variant Type，在兼顾灵活性的同时兼具列式存储性能；构建统一的可观测性数据底座，将 trace、logs、metrics 等统一纳入 Doris，并与 OpenTelemetry 等生态深度集成。
• 在具体实现上，支持深层嵌套 JSON 结构，持续优化稀疏列与字符串列的高效存储机制，以提升存储效率与查询性能。

在此基础上，继续完善列式能力支持，如部分列更新、索引能力及超宽表处理，进一步强化 Variant 类型在 JSON 与半结构化数据分析场景中的整体支撑能力。

在此背景下，AI 可观测性也逐渐成为这一场景的重要延伸。此前，社区已通过相关实践展示了如何借助 Apache Doris 对类似 OpenClaw 这类黑盒系统的内部运行过程进行分析，并从中识别包括安全风险在内的多种行为模式，这正是 AI 可观测性的典型应用场景之一。

02 混合检索与分析（HSAP）

在 AI 场景中，检索范式正在从单一模式走向融合。在混合检索出现之前，用户通常需要额外引入向量数据库或 Elasticsearch 等检索系统，以满足语义检索与全文检索需求。然而，这种割裂式架构存在明显局限：仅依赖向量检索时，精确匹配能力不足；仅依赖文本检索时，又难以覆盖语义相关但不包含关键词的内容。

基于这一背景，Doris 在 4.0 版本中引入了混合检索能力，使用户能够通过单一 SQL 同时完成全文检索、语义打分与向量检索，从而兼顾关键词精确匹配与语义召回能力。

在 2026 年，混合检索与分析及相关能力将进一步增强：

• 持续增强语义检索与 Vector Search，引入基于磁盘的 ANN 算法与数据结构，以支持百亿级向量的高效存储与检索。
• 进一步融合向量能力与存储计算体系，包括在 Merge-on-Write 上构建可更新索引、优化索引优先访问路径，以及提升向量数据压缩与管理效率。
• 持续增强全局索引与延迟物化能力，以优化以 TopN 为主的语义检索查询，在减少数据访问量的同时显著提升性能。
• 探索开放湖格式上的向量能力建设，使用户在无需迁移数据的前提下，即可在 Iceberg、Paimon 等数据湖之上实现高效的向量检索与分析，进一步打通湖仓一体化生态。

03 多模态场景 & AI SQL

作为以 SQL 为核心的数据库系统，Doris 最初面向结构化数据设计，但随着 AI 应用发展，多模态需求快速增长，推动其在该方向持续演进。

Doris 在这一方向的核心目标，是降低数据处理门槛并统一处理流程：

• AI SQL 与 Python UDF 结合，形成覆盖数据预处理、特征提取、向量构建与分析的一体化能力体系，支撑更加完整的多模态数据处理链路。
• 引入 File 数据类型，该数据类型在不同执行环境下可具备不同语义。如在 SQL 中用于访问文件元数据，在 AI SQL 或 Python UDF 中则可直接处理文件内容，从而支持 embedding 与内容分析。

通过上述能力的逐步完善，Doris 的目标是在多模态场景下，依托统一的数据平台，为用户提供从数据接入、处理到分析的端到端能力支持。

04 面向 Agent 的分析能力

当数据库的主要调用方从人转向 Agent，交互方式也随之改变。仅依赖 Text-to-SQL 难以支撑复杂场景，因为 Agent 在缺乏语义信息时难以稳定生成正确查询。

因此，Doris 在 2026 年将重点建设：

• 加强语义层建设，包括数据标签体系与元数据开放 API，以支持构建更灵活、可控的语义层，并提升 Agent 交互质量。
• 持续推进 Data Agent 集成，使数据库具备面向 Agent 的原生服务能力，从而支持更自然的交互与更准确的结果返回。
• 完善元数据 API，强化对外部 Catalog 的集成能力，以对接统一的数据管理、权限与语义体系，为 Agent 提供一致、可靠的数据理解基础。

上述场景的落地，最终依赖于底层能力的持续演进。

01 查询引擎：能力、性能与稳定性提升

在 2026 年，查询引擎的演进将围绕三个核心目标展开。

• 能力完善。提供更丰富且兼容性更强的 SQL 语法与函数支持，包括 ASOF Join、Recursive CTE、UNNEST 等能力；持续推进语法简化与兼容性增强，降低 Lakehouse 场景下的迁移成本；MERGE INTO 能力增强，支持在单条 SQL 或事务中完成更完整的 CDC 流程。
• 性能优化。强化 Condition Cache，缓存 Block 级过滤结果以降低运行时计算开销；重构 ZoneMap（智能索引）表达式，提升数据过滤效率；提升复杂列场景（JSON）列裁剪能力，支撑高并发场景下稳定性能表现。
• 大规模任务的执行能力与稳定性提升，即“Run Big， Run Stable”。优化 Spill-to-Disk 与 Global Buffer Mgmt 内存管理能力，系统在资源受限情况下仍能稳定执行大规模任务。

同时，持续完善查询可观测性，使用户在调度平台与交互式查询场景中直观地理解执行状态。

02 存储引擎：规模、缓存与弹性优化

在存储层面，围绕规模（Scale）、缓存（Cache）与弹性（Elasticity）三个核心方向展开。

• 在规模方面，重点解决超宽表场景与大规模 Tablet 带来的元数据与管理问题，比如 JSON 经 Variant 子列抽取后，列数可能扩展至数千甚至上万列，类似问题在 Parquet 等列式系统中同样存在。
• 在缓存方面，持续优化 Smart Caching 加强跨计算组缓存预热、细粒度缓存策略及分布式共享缓存能力；缓存策略也将支持基于时间范围、表级或分区级定义缓存策略，或对特定热点分区进行定向预热。
• 在弹性方面，结合云基础设施优化动态伸缩能力，提升扩缩容效率、优化多计算组读写分离，以及通过元数据持久化与本地缓存机制加快节点启动过程，降低切换带来的性能影响。

总体而言，存储层的演进一方面面向更大规模与更复杂数据结构，另一方面致力于在存算分离架构下提供更加稳定、高效的实时服务能力。

03 开放数据湖：读写能力与统一治理

在开放数据湖方向，随着 Lakehouse 架构逐步成为主流，Iceberg、Paimon 等开放湖格式持续演进。2026 年，Doris 将围绕 读（Read）、写（Write）与治理（Govern） 三个核心维度展开能力建设。

• 查询能力：在不迁移数据的前提下，让湖表查询性能尽可能接近内表。优化在 Iceberg、Paimon 等湖表的实时查询能力，增强 Parquet Page Cache 与本地 File Block Cache，并将 Condition Cache 扩展至湖表场景，同时通过 Distributed Planning 优化超大规模湖表的元数据规划与解析。
• 湖表管理能力：支持 Iceberg 与 Paimon 的完整生命周期管理，包括 DDL 与 DML（Update、Delete、Merge Into）。同时持续跟进生态演进，如 Iceberg V3 行级血缘与 Paimon 索引能力。
• 生态接入能力：一方面，深化与 Flink 的集成，推进 Streaming Lakehouse；另一方面，扩展 Arrow Flight 能力，并引入基于 Arrow Flight 的 Catalog，降低多数据源接入成本，拓展数据访问边界。
• 统一治理能力：加强与各类 Catalog 服务的深度集成，包括支持第三方认证接入、兼容 Iceberg 与 Paimon 的 REST Catalog 标准，以及完善自身元数据 Open API 能力。使 Doris 能无缝融入现有数据治理体系。

数据形态正在从结构化走向 JSON、向量与多模态，数据使用方式也从面向人扩展到面向 Agent 。数据库面对的，不再是单一分析负载，而是分析、检索与 AI Agent 并存的复合负载。

Apache Doris 在 2026 年的规划，核心不再只是提升分析性能，而是响应 AI 时代数据基础设施的根本变化。

Scale Intelligence， Accelerate Insight，不仅是年度主题，也定义了 Doris 在 AI 时代的演进方向。

如果你对这些方向感兴趣，或者正在做相关探索，欢迎了解和参与 Apache Doris 社区：

• 想看看最新能力，可以体验最新版本
• 想了解实现细节，可以阅读官方文档
• 有实践经验或问题 ，欢迎一起交流讨论
• 也欢迎一起参与开源贡献，让这些能力真正落地

GitHub: https://github.com/apache/doris官方网站：https://doris.apache.org