AI 成为主流负载后,数据基础设施将如何演进?

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

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

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

Scale Intelligence, Accelerate Insight

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

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

2025：变化的起点

回看 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 时代同时承载分析与检索的统一数据平台。

AI 带来哪些机遇与挑战？

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

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

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

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

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

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

2026 年：从场景看演进

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

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

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

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

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

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

混合检索与分析（HSAP）

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

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

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

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

多模态场景 & AI SQL

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

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

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

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

面向 Agent 的分析能力

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

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

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

2026 年：从能力看演进

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

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

在 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 内存管理能力，系统在资源受限情况下仍能稳定执行大规模任务。

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

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

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

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

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

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

在开放数据湖方向，随着 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 时代的演进方向。

从拒绝AI到一切先问Agent，DHH：这是我最爽的编程时刻之一，但程序员黄金时代到头了

当前的上下文方案，本质是暴力破解！DeepMind 创始人：忽强忽弱的 AI，才是真正的灾难，突破在记忆系统

Claude Code越更越废？！大厂AI主管公开怒喷思考深度暴跌，官方回应更被怼爆：菜成AI“玩具”