OceanBase CTO 杨传辉

主流数据库的发展经历了几次重要演进：从最早的OLTP数据库，到OLAP从其中分离出来成为数据仓库，再到大数据系统。长期以来，数据库架构主要围绕人类应用、确定性交易和结构化数据分析设计的。

今天，新的变化正在发生。AI Agent 不再只是读取数据、回答问题，而是开始调用工具、生成代码、执行任务、修改状态，甚至参与业务流程。数据库的使用者，正在从人类应用扩展到大量自主运行的 Agent。这带来一个根本问题：当成千上万个 Agent 同时读写、搜索、试错、回滚和生成上下文，数据库还应该是过去的样子吗？

我认为，答案是否定的。AI 正在同时改变三件事：

• 数据库的使用者，从应用扩展到 Agent；
• 数据库管理的数据，从结构化数据扩展到涵盖结构化、半结构化与非结构化的多模态数据；
• 数据库承载的工作负载，从事务和分析扩展到搜索、上下文工程与 AI 应用。

因此，AI 数据库不是传统数据库增加几个 AI 函数，也不是向量数据库补上 SQL 能力。它要解决的是 AI 进入生产系统后的数据基础设施问题。多模态数据需要在统一底座上被管理，在线服务和离线计算需要融合，Agent 需要获得实时、可信、连续的上下文，读写、试错、回滚和治理中保持数据库级一致性与可靠性。

这不是一次功能增强，而是在 AI 时代重新定义数据库的技术架构。

我们先看行业发生了什么。

Databricks 和 Snowflake 从湖仓和数仓出发，不断补充 OLTP 的事务能力；

OceanBase 和 Oracle 从交易库出发，不断补充 OLAP 和大数据能力；

MongoDB、Milvus、Elasticsearch 从专用库出发，不断增强通用数据库的能力。不管出发点如何，不同路线正在向一个能够同时处理交易、分析、搜索、向量以及 AI 计算的统一数据底座演进。

OceanBase 一直坚持走一体化设计思路。

最早我们做的分布式 OLTP，解决了在线交易的扩展性和可靠性。后来我们在 OLTP 基础上加入了实时 OLAP 支持，消除了 TP 到 AP 的数据搬运。去年，我们发布了多模一体化，把向量、全文、JSON、GIS 等能力带进同一个数据库引擎。

今天，我们发布湖库一体，是继续往前走一步：把库里的实时事务能力、湖上的开放存储和开放计算能力，放到同一个数据底座里。

我理解的湖库一体，不能停留在数据库外接一个数据湖，也不能只是给湖仓补几个在线查询接口。要让它进入生产系统，至少要合并三条边界。

第一，数据形态要统一。结构化数据、半结构化数据、非结构化数据、向量、图、全文索引，不能分散在不同系统里各管一份。它们应该在同一套表语义下被管理。

第二，计算路径要统一。SQL 查询、实时分析、混合搜索、Spark ETL、Ray 上的 AI 计算，应该围绕同一份数据工作，而不是靠不断导出、转换、中间落盘来协作。

第三，治理边界要统一。元数据、权限、行级控制、审计、版本、生命周期，必须对所有数据类型一致生效。否则结构化字段有权限控制，向量检索却绕过了权限，这样的系统进不了企业生产。

这也是 OceanBase Lakebase 的设计出发点：

底层使用存算分离的设计架构。数据存在对象存储上，计算层独立运行。AI Agent 的工作负载本质上是突发式的——每一个 Agent 都可能在任何一天流量激增，每一天都可能有一个小型的双十一。存算分离让计算层能够独立伸缩，负载上来瞬间扩容，空闲时缩到零。

中间用多模表统一结构化、半结构化、非结构化数据以及多模态数据。

上层支持开放计算。除了原有的 SQL 计算（OLTP、OLAP、AI 搜索），也支持 Spark 处理 ETL、Daft on Ray 处理 AI 加工。把这些计算引擎统一在同一份数据之上，是湖库一体区别于传统数据库的核心设计目标。

湖的价值在开放、弹性和成本。库的价值在事务、一致性、低延迟和治理。AI 时代需要把这两组能力合在一起。

但还有一个关键价值容易被忽视——实时性。

传统做法里，数据加工是离线的，加工完的结果还要搬回在线系统才能服务应用，中间有 T+1 甚至更长的延迟。

湖库一体把离线加工和在线服务统一在同一份数据上：Spark ETL 的产出，SQL 引擎立即可查；模型推理生成的向量，混合搜索立即可用。不再有“加工完了还要等同步”的窗口期。

实时性不是靠加速搬运实现的，而是靠消除搬运实现的。

原来的关系数据库，底层是一张关系表——里面有 Int、Float、Varchar，所有列都是结构化数据。

今天的 AI 数据库，底层应该是一张多模表。

多模表既包括原有结构化数据的关系列，也包括非结构化数据的多模列与 AI 列。

非结构化数据，可以在外部 Embedding 或者打标之后以向量或者文本的方式写入到多模表，也可以直接以 LOB 的形式写入到多模表。

OceanBase 支持非常灵活的 LOB 存储。

• 如果 LOB 对象比较小，直接在行内存储，节省 IO；
• 如果 LOB 对象比较大，切片后存入对象存储，行内只保留每个切片的位置信息；
• 如果 LOB 对象特别大，支持引用外部对象存储中的已有文件，数据库只存储元数据。上层应用看到的仍然是一张表。

在多模表之上，我们还设计了 AI 列。它可以理解成表上的实时计算列：数据写入后，自动触发 Embedding、打标等模型计算，并把结果写回表里。这里最重要的是事务一致性语义。比如一批音频写入后，要么全部完成 Embedding 和打标，要么全部失败，不能出现部分成功、部分失败的情况。

有了多模表，接下来是在其上执行 AI 工作负载。

AI 数据库里面，查询的基本模式从关系查找进化为混合搜索——在同一张表里完成关系过滤、全文搜索、向量搜索、图搜索以及 AI 计算。

为什么单纯的向量搜索是不够的？

向量搜索在 AI 数据库里一定是最常见的一种计算方式，但在实际场景里，我们往往首先通过关系过滤将全局数据缩小为一个更小的候选集（例如“只看最近 30 天的订单”），接下来在候选集上做向量、全文、图的混合搜索。数据库先缩小范围，模型只处理高价值候选——推理成本更低、结果更准、链路更可控。

在 AI 时代，搜索会与 OLTP、OLAP 一样回归数据库本体，成为数据库的一类负载。

性能上，我们做了系统的评测验证。

使用 HNSW 算法，在 768 维和 1536 维的测试场景下，同等召回率条件下 OceanBase 的向量搜索性能远领先于 Milvus、Elasticsearch 和 pgvector。

在混合搜索维度，使用 MS MARCO 数据集评测，OceanBase 混合搜索的性能相比 Elasticsearch 提升 30% 以上。这不是理论值——是标准数据集上的可复现结果。

Agent 的数据链路不止是 SQL 查询——还有 ETL 加工、AI 推理、多模态理解。

原先的做法，往往是采用多个不同的系统——Kafka 做接入，Flink 做流处理，Spark 做批处理，HDFS 做持久化，ClickHouse 做分析，HBase 做宽表，Elasticsearch 做搜索，Presto 做联邦查询。

OceanBase 湖库一体设计解决的就是这个问题。

底层通过基于对象存储的多模表，实现多套计算引擎之间的数据共享——一份数据同时服务所有计算引擎。OceanBase 的 SQL 引擎处理在线查询和事务；Spark 处理 PB 级批量 ETL；Daft on Ray 处理 AI 推理，从而解决多套系统之间的数据一致性以及计算延迟的问题。

因为需要支持这么多开放计算引擎，我们需要一个统一开放的 Catalog 来管理数据。表、视图、Schema、Lineage、行级权限、列级授权，都应该在这里统一管理。

OceanBase AI 数据库的所有操作在进入系统之前，都需要经过统一元数据与权限控制面做一层过滤，避免数据越权访问。我们也已经支持了最细粒度的行级权限控制（RLS）。

为了让 Agent 真正进入生产系统，数据库必须给它一个可隔离、可回滚、成本足够低的操作环境。

通过 Fork Database，可以秒级创建一个完整的数据库副本——像在 GitHub 里拉一个分支。即使 PB 级数据库也能在秒内完成 fork，且只占增量空间（Copy-on-Write，未修改的数据块指向湖上同一份存储，不产生物理拷贝）。

拉完分支之后，可以在分支上做各种 AI 的开发、测试和实验。实验成功就提交，实验失败直接回滚，基本上没有代价。

配合 DIFF 和 MERGE，Agent 就获得完整的数据版本控制能力——Fork 建分支，DIFF 看差异（精确到行和值），MERGE 按策略合回。这不是类比 Git，而是 SQL 级的原生实现。

另一个维度是规模。AI 的 Agent 数据量会是海量的，未来可能有千亿级甚至万亿级 Agent 在并行运行，每一个 Agent 都有自己的 Schema、自己的表——这会造成 Schema 爆炸的问题。

传统数据库为“少库 + 海量数据”优化，一个集群承载几十个库、每个库数十亿行。Agent 场景完全相反：千万个 Agent，每个只有几百行，但实例数量是天文级的。

OceanBase 的逻辑表设计，是让每一个 Agent 看到的是一张张独立的逻辑表，但存储在底层是同一张物理表格，通过逻辑层抽象解决 Schema 爆炸。

Fork Database 解决独立环境，逻辑表解决实例规模——两者协同才能让单个 Agent 安全试错、海量 Agent 低成本并行运行。

AI 数据库，光有引擎还不够。引擎和应用之间还缺一层——上下文。

上下文层分为两个部分。数据上下文，围绕数据的语义和数据的治理展开，让AI理解企业。应用上下文，围绕 Memory 和 RAG 展开，让 AI 理解用户。

在记忆维度，Agent 的记忆不能简单地堆上下文，而是一个可进化的结构化资产。为此我们研发了 OceanBase PowerMem，以及基于 PowerMem 的云上产品 OceanBase seekdb M0。

OceanBase PowerMem 构建在 AI 数据库之上，记忆的检索本身就是一次结构化过滤 + 语义相似度的混合查询。更关键的是它支持记忆的自进化——包括经验的自进化以及技能的自进化。

我们使用 AppWorld 公平蒸馏实验做了验证——同一份轨迹、同一模型、唯一变量是蒸馏和检索方案。结果：seekdb M0 方案的通过率达到 39%，Hermes 只有 22%；完成相同任务，M0 的步骤是 6.2 步，Hermes 是 10.4 步；整体 Token 消耗降低 32%。

在语义维度，高质量的数据语义让 AI 应用真正能够理解企业。OceanBase OSI 要解决的不是再造一套 BI 语义，而是把指标、口径、原始数据、上下文图谱、本体层统一起来。

• 最底层是语义层——指标、口径、原始数据等，基于 Ant-OSI 语义层标准设计，兼容 OSI 开放标准，并在蚂蚁集团得到了大量实践验证。
• 中间层是上下文图谱——大模型基于上下文图谱推理，提升准确率。
• 最上层是本体层——统一业务语义与底层数据库语义，做到全局语义与局部语义的平衡。核心理念是“语义即代码”——数据语义一次定义，BI 渲染报表、Agent 生成 SQL、治理工具做血缘分析，读的是同一份定义。

我们基于 OceanBase OSI 也开发了 DataPilot 产品。在不同行业的客户 POC 测试中，客户反馈准确率远好于业界其他产品。

这背后不是模型的差异，而是语义上下文的质量差异——当 AI 拥有准确的业务口径定义，从自然语言到 SQL 的翻译准确率会本质性地提升。

所有这些能力加在一起意味着什么？最直接的答案是：组件数量的大幅减少。

如果采用传统方案，企业需要 5 到 10 个系统来融合处理多模态数据，且多个系统缝合带来一系列问题，包括：CDC 延迟、ETL 失败重试、多套独立运维、多套权限体系、多套监控告警，等等。

通过OceanBase湖库一体引擎，能够实现多合一，通过一份数据保证一致性，通过离在线融合保证实时性。

如果把这些能力放在一起看，OceanBase AI 数据库的架构可以概括为三层。

最底层是湖库引擎——多模表运行在对象存储之上。通过多模表和对象存储，支持各种开放计算：OceanBase 的 SQL 计算（OLTP、OLAP、搜索）以及 Spark ETL 和大模型 AI 计算。

中间是上下文层——数据上下文让 AI 理解企业，应用上下文让 AI 理解用户。

最上层是我们开发的应用 Agent：面向数据开发工程师的数据开发 Agent，和面向业务分析师的数据分析 Agent。

为了让企业真的把 AI 用起来，最重要、最基本的一步，是通过一个一体化的 AI 数据库把企业自己的数据管理起来。管理好自己的数据之后，才能让企业的 AI 更准、更省、更快、更安全。

湖库一体的 AI 数据库，这就是我们面向 AI Agent 时代给出的答案。

活动预告

技术解读已就位

还想了解更多实战经验和行业洞察？

想和 AI 先行者们来个深度交流？7 月 10 日AI 碰撞会·上海站

等你来碰！

立即试用 OceanBase 企业版，体验国产数据库能力立即试用