OceanBase CTO 杨传辉 | 量子位 | 公众号 QbitAI

AI时代，库体库技术迭代遵循“苟日新，重新日日新，定义又日新”的数据规律，数据库领域亦不例外。库体库

回顾主流数据库的重新演进历程，我们经历了从OLTP（在线事务处理）到OLAP（在线分析处理）分离形成数据仓库，定义再到大数据系统崛起的数据多次变革。长期以来，库体库数据库架构主要服务于人类应用、重新确定性交易及结构化数据分析。定义

然而，数据今天这一格局正在发生根本性变化。库体库

AI Agent已不再局限于被动读取数据或回答问题，重新而是定义开始主动调用工具、生成代码、执行任务、修改状态，甚至深度参与业务流程。数据库的使用者，正从传统的人类应用扩展至海量自主运行的Agent。

这引出了一个核心命题：当成千上万个Agent同时并发进行读写、搜索、试错、回滚及上下文生成时，数据库是否还应维持旧有形态？

我的回答是：否定。

AI正在重塑数据库的三大维度

AI不仅改变了技术，更在同时重构以下三个关键维度：

1. 使用者扩展：从人类应用延伸至自主Agent。
2. 数据形态扩展：从单一结构化数据，扩展至涵盖结构化、半结构化与非结构化的多模态数据。
3. 工作负载扩展：从传统的事务与分析，扩展至搜索、上下文工程及AI应用。

因此，AI数据库并非传统数据库简单叠加AI函数，也非向量数据库补充SQL能力。其核心使命是解决AI进入生产系统后的数据基础设施难题。

在统一底座上管理多模态数据，融合在线服务与离线计算，为Agent提供实时、可信、连续的上下文，并在读写、试错、回滚及治理中保持数据库级的一致性与可靠性——这并非功能增强，而是在AI时代对数据库技术架构的重新定义。

AI时代：数据库走向一体化

观察行业趋势，不同技术路线正殊途同归：

• Databricks与Snowflake：从湖仓和数仓出发，不断补充OLTP事务能力；
• OceanBase与Oracle：从交易库出发，持续提升OLAP及大数据处理能力；
• MongoDB、Milvus、Elasticsearch：从专用库出发，持续增强通用数据库能力。

无论起点如何，行业正共同向一个能够同时处理交易、分析、搜索、向量及AI计算的统一数据底座演进。

OceanBase始终坚持一体化设计思路：
1. 早期聚焦分布式OLTP，解决在线交易的扩展性与可靠性；
2. 随后在OLTP基础上融入实时OLAP，消除TP至AP的数据搬运损耗；
3. 去年发布多模一体化，将向量、全文、JSON、GIS等能力整合至同一数据库引擎。

如今，OceanBase湖库一体AI数据库的正式发布，标志着这一路径的深化：将库内的实时事务能力与湖上的开放存储、开放计算能力，融合于同一数据底座。

什么是湖库一体（OceanBase Lakebase）

OceanBase Lakebase并非简单的“数据库外接数据湖”，也不是为湖仓系统补几个在线查询接口。要使其真正进入生产系统，必须合并三条关键边界：

1. 数据形态统一：结构化、半结构化、非结构化数据、向量、图及全文索引，不应分散于不同系统。它们应在同一套表语义下被统一管理。
2. 计算路径统一：SQL查询、实时分析、混合搜索、Spark ETL、Ray上的AI计算，应围绕同一份数据工作，摒弃依赖不断导出、转换及中间落盘的协作模式。
3. 治理边界统一：元数据、权限、行级控制、审计、版本及生命周期管理，必须对所有数据类型一致生效。若结构化字段有权限控制而向量检索可绕过，该系统无法通过企业生产准入。

架构设计核心

• 底层：存算分离架构
  数据存储于对象存储，计算层独立运行。鉴于AI Agent工作负载具有突发性（如“小型双十一”效应），存算分离允许计算层独立伸缩：负载激增时瞬间扩容，空闲时缩至零，实现极致弹性。

• 中层：多模表统一数据
  通过多模表统一结构化、半结构化、非结构化及多模态数据，消除数据孤岛。

• 上层：开放计算支持
  除原生SQL计算（OLTP、OLAP、AI搜索）外，支持Spark处理ETL、Daft on Ray处理AI加工。将多计算引擎统一于同一数据之上，是湖库一体区别于传统数据库的核心目标。

湖的价值在于开放、弹性与低成本；库的价值在于事务、一致性、低延迟与治理。AI时代需将二者合二为一。

关键价值：实时性

传统模式下，数据加工离线进行，结果需搬运回在线系统，存在T+1甚至更长的延迟窗口。

湖库一体通过消除搬运实现实时性：
* Spark ETL产出，SQL引擎立即可查；
* 模型推理生成的向量，混合搜索立即可用。

不再有“加工完成等待同步”的滞后，实现离线加工与在线服务的无缝统一。

多模表：AI数据库的核心数据结构

OceanBase的第二个创新点在于多模表。

传统关系数据库底层为关系表（Int、Float、Varchar等结构化列）。而AI数据库的底层应为多模表，包含：
* 关系列：原有结构化数据；
* 多模列与AI列：支持非结构化数据。

灵活的LOB存储策略

OceanBase支持多种LOB存储模式以适应不同场景：
* 小LOB对象：行内存储，节省IO；
* 大LOB对象：切片存入对象存储，行内保留位置信息；
* 超大LOB对象：引用外部对象存储文件，仅存储元数据，上层应用仍视为一张表。

AI列：实时计算与事务一致性

在多模表之上设计AI列，作为表的实时计算列。数据写入后，自动触发Embedding、打标等模型计算并写回。
* 核心保障：事务一致性语义。例如，一批音频写入后，Embedding和打标要么全部成功，要么全部失败，杜绝部分成功/失败的状态不一致。

混合搜索：AI数据库的一类新负载

基于多模表，AI工作负载的查询模式从关系查找进化为混合搜索——在同一张表中完成关系过滤、全文搜索、向量搜索、图搜索及AI计算。

为何单纯向量搜索不足？

向量搜索虽常见，但实际场景中，通常需先通过关系过滤缩小候选集（如“最近30天订单”），再在候选集中进行混合搜索。
* 优势：数据库先缩小范围，模型仅处理高价值候选，从而降低推理成本、提高结果准确性、增强链路可控性。

我们判断：在AI时代，搜索将与OLTP、OLAP一样，回归数据库本体，成为数据库的一类核心负载。

性能验证

• 向量搜索：在768维和1536维测试场景下，同等召回率条件下，OceanBase性能显著领先Milvus、Elasticsearch和pgvector。
• 混合搜索：基于MS MARCO数据集评测，OceanBase混合搜索性能较Elasticsearch提升30%以上。

开放计算与统一Catalog

Agent的数据链路不仅包含SQL查询，还涉及ETL加工、AI推理及多模态理解。

传统方案依赖多系统拼接（Kafka接入、Flink流处理、Spark批处理、HDFS持久化、ClickHouse分析、HBase宽表、Elasticsearch搜索、Presto联邦查询），导致数据一致性差、计算延迟高、运维复杂。

OceanBase湖库一体通过以下方式解决此问题：
1. 数据共享：基于对象存储的多模表，实现一份数据服务所有计算引擎。
2. 引擎协同：
* SQL引擎：处理在线查询与事务；
* Spark：处理PB级批量ETL；
* Daft on Ray：处理AI推理。
3. 统一Catalog：
* 管理表、视图、Schema、Lineage、行级/列级权限。
* 所有操作进入系统前，经统一元数据与权限控制面过滤，防止越权访问。
* 目前支持最细粒度的行级权限控制（RLS）。

为Agent设计：版本控制与弹性规模

为使Agent真正进入生产系统，数据库需提供可隔离、可回滚、低成本的操作环境。

1. Fork Database：秒级版本控制

• 机制：类似Git分支，秒级创建完整数据库副本。
• 优势：PB级数据库也可秒级Fork，采用Copy-on-Write机制，未修改数据块指向湖上同一存储，仅占增量空间，无物理拷贝开销。
• 流程：Fork建分支 -> 实验/测试 -> DIFF查看差异（精确到行/值） -> MERGE合回或回滚。
• 价值：Agent获得SQL级原生版本控制能力，试错成本趋近于零。

2. 逻辑表：解决Schema爆炸

• 挑战：未来可能出现千亿级Agent并行运行，每个Agent拥有独立Schema，导致实例数量天文级增长。传统数据库优化于“少库+海量数据”，难以应对“千万库+少量数据”场景。
• 方案：逻辑表设计。每个Agent看到独立逻辑表，底层存储于同一物理表格，通过逻辑层抽象解决Schema爆炸问题。

Fork Database解决独立环境，逻辑表解决实例规模，二者协同实现单个Agent安全试错与海量Agent低成本并行。

上下文层：让AI理解企业与用户

引擎之上，需构建上下文层，连接AI数据库与应用：

1. 数据上下文：围绕数据语义与治理，让AI理解企业。
2. 应用上下文：围绕Memory和RAG，让AI理解用户。

记忆维度：PowerMem与seekdb M0

Agent记忆不应是上下文堆砌，而是可进化的结构化资产。
* PowerMem：构建于AI数据库之上，记忆检索即结构化过滤+语义相似度混合查询。
* 自进化能力：支持经验与技能的自进化。
* 实验验证：在AppWorld公平蒸馏实验中，seekdb M0方案通过率39%（Hermes为22%），完成任务步骤6.2步（Hermes为10.4步），Token消耗降低32%。

语义维度：OceanBase OSI

高质量数据语义是AI应用理解企业的关键。OceanBase OSI旨在统一指标、口径、原始数据、上下文图谱与本体层。
* 底层：语义层：基于Ant-OSI标准设计，兼容OSI开放标准，经蚂蚁集团实践验证。
* 中间层：上下文图谱：辅助大模型推理，提升准确率。
* 上层：本体层：统一业务语义与底层数据库语义，平衡全局与局部语义。
* 核心理念：“语义即代码”。数据语义一次定义，BI报表、Agent生成SQL、治理工具血缘分析均读取同一份定义。

基于OceanBase OSI开发的DataPilot产品，在行业POC测试中，客户反馈准确率显著优于业界其他产品。这源于语义上下文的质量差异：准确的业务口径定义本质性地提升了自然语言到SQL的翻译准确率。

一套技术栈：降低工程复杂度

上述能力整合，最直接的价值是组件数量的大幅减少。

传统方案需5-10个系统融合多模态数据，带来CDC延迟、ETL重试失败、多套运维/权限/监控等痛点。

OceanBase湖库一体引擎实现多合一：
* 一份数据：保证一致性；
* 离在线融合：保证实时性。

小结：湖库一体的AI数据库架构

OceanBase AI数据库架构可概括为三层：

1. 最底层：湖库引擎
   多模表运行于对象存储之上，支持开放计算：OceanBase SQL计算（OLTP、OLAP、搜索）、Spark ETL及大模型AI计算。

2. 中间层：上下文层

3. 数据上下文：让AI理解企业；

4. 应用上下文：让AI理解用户。

5. 最上层：应用Agent

6. 面向数据开发工程师的数据开发Agent；
7. 面向业务分析师的数据分析Agent。

基于多年Know-how经验，企业应用AI的关键一步是通过一体化的AI数据库管理好自身数据。只有管理好数据，企业的AI才能更准、更省、更快、更安全。

湖库一体的AI数据库，即是OceanBase面向AI Agent时代给出的答案。

(责任编辑：综合)