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 时代需要把这两组能力合在一起。但还有一个关键价值容易被忽视——实时性。传统做法里数据加工是离线的加工完的结果还要搬回在线系统才能服务应用中间有 T1 甚至更长的延迟。湖库一体把离线加工和在线服务统一在同一份数据上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 级批量 ETLDaft on Ray 处理 AI 推理从而解决多套系统之间的数据一致性以及计算延迟的问题。因为需要支持这么多开放计算引擎我们需要一个统一开放的 Catalog 来管理数据。表、视图、Schema、Lineage、行级权限、列级授权都应该在这里统一管理。OceanBase AI 数据库的所有操作在进入系统之前都需要经过统一元数据与权限控制面做一层过滤避免数据越权访问。我们也已经支持了最细粒度的行级权限控制RLS。为了让 Agent 真正进入生产系统数据库必须给它一个可隔离、可回滚、成本足够低的操作环境。通过 Fork Database可以秒级创建一个完整的数据库副本——像在 GitHub 里拉一个分支。即使 PB 级数据库也能在秒内完成 fork且只占增量空间Copy-on-Write未修改的数据块指向湖上同一份存储不产生物理拷贝。拉完分支之后可以在分支上做各种 AI 的开发、测试和实验。实验成功就提交实验失败直接回滚基本上没有代价。配合 DIFF 和 MERGEAgent 就获得完整的数据版本控制能力——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 企业版体验国产数据库能力立即试用
基于 OceanBase 湖库一体架构，构建 AI 时代的数据基础设施
发布时间：2026/7/8 9:34:02
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 时代需要把这两组能力合在一起。但还有一个关键价值容易被忽视——实时性。传统做法里数据加工是离线的加工完的结果还要搬回在线系统才能服务应用中间有 T1 甚至更长的延迟。湖库一体把离线加工和在线服务统一在同一份数据上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 级批量 ETLDaft on Ray 处理 AI 推理从而解决多套系统之间的数据一致性以及计算延迟的问题。因为需要支持这么多开放计算引擎我们需要一个统一开放的 Catalog 来管理数据。表、视图、Schema、Lineage、行级权限、列级授权都应该在这里统一管理。OceanBase AI 数据库的所有操作在进入系统之前都需要经过统一元数据与权限控制面做一层过滤避免数据越权访问。我们也已经支持了最细粒度的行级权限控制RLS。为了让 Agent 真正进入生产系统数据库必须给它一个可隔离、可回滚、成本足够低的操作环境。通过 Fork Database可以秒级创建一个完整的数据库副本——像在 GitHub 里拉一个分支。即使 PB 级数据库也能在秒内完成 fork且只占增量空间Copy-on-Write未修改的数据块指向湖上同一份存储不产生物理拷贝。拉完分支之后可以在分支上做各种 AI 的开发、测试和实验。实验成功就提交实验失败直接回滚基本上没有代价。配合 DIFF 和 MERGEAgent 就获得完整的数据版本控制能力——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 企业版体验国产数据库能力立即试用
