OceanBase押注湖库一体，AI数据库进入统一架构时代

6月29日，OceanBase 正式抛出了一张新牌：湖库一体的 AI 数据库架构。这不是一次常规的版本迭代，而是把过去几年数据库圈子里一直在争论的几件事——湖仓要不要合、AI 应用该不该单独搞一套向量库、OLTP 和 OLAP 到底还能不能塞进一个引擎——一次性摆到台面上给出自己的答案：都合，用一套技术栈搞定。

对开发者来说，这件事的信号比发布会的口号更值得琢磨。因为它意味着 OceanBase 想抢的，已经不只是 MySQL 的位置，而是 Databricks、Snowflake 加上一众向量数据库的地盘。

为什么是现在提“湖库一体”

把时间倒回一年，行业里主流的说法还是“湖仓一体”（Lakehouse）。Databricks 用 Delta Lake 打出了名号，Snowflake 也在向 Iceberg 靠拢，核心逻辑是把数据湖的低成本存储和数据仓库的分析能力揉到一起，解决企业数据分散在 S3、HDFS 和数仓里对不上账的问题。

但 Agent 应用起来之后，这个组合突然不够用了。

一个典型的企业级 AI Agent，要做的事情横跨几个数据世界：读历史订单（OLTP）、跑用户画像分析（OLAP）、检索非结构化文档（向量库）、还要能实时接住业务系统写进来的最新数据。现在的做法是——OLTP 一套库，数仓一套，湖里放冷数据，再单独部署 Milvus 或 pgvector 做向量检索，中间用 Kafka 和一堆 ETL 管道串起来。数据在系统之间搬来搬去，延迟、一致性、成本全是问题。更麻烦的是，Agent 需要的是“当下这一刻”的全局视图，而不是 T+1 之后的报表。

OceanBase 的判断是：湖仓一体解决的是分析侧的整合，但 AI 时代真正的痛点在于离线数据和在线数据的割裂。所以它把架构往前推了一步，提出用一套引擎同时承接在线事务、离线分析、湖上数据访问和向量检索。这个提法在国内数据库厂商里算是相当激进的。

技术栈到底怎么“一体”

把四件事塞进一个引擎，听起来像宣传话术，但 OceanBase 的路径其实是有迹可循的。它本身是分布式 HTAP 起家，OLTP 和 OLAP 共用一套 LSM-Tree 存储引擎，通过副本级别的读写分离让分析查询不影响事务性能。这一部分是老底子。

新的东西主要在两块：

一是对开放表格式的原生支持。 湖库一体架构下，OceanBase 可以直接读写 Iceberg、Paimon 这类开放表格式，把 S3、OSS 上的 Parquet 文件当成外表来查询，不需要先导入到数据库里。这一步很关键，意味着企业已有的数据湖不用推倒重来，OceanBase 变成了访问入口而不是又一个数据孤岛。

二是向量能力的深度整合。 去年 11 月 OceanBase 开源了 AI 原生的 seekdb，主打混合搜索——把标量过滤、全文检索和向量检索在一个查询里完成。上个月刚发布的 seekdb 1.1.0 又补齐了 macOS 原生支持、Fork Table 写时复制机制，以及一个明显是为 AI Coding 场景准备的能力：让 AI 助手在接近真实分布的数据副本上生成 SQL，验证通过再落到生产环境。这套向量能力现在被整合进了主库的湖库一体架构里，而不是作为一个独立产品存在。

把这几层串起来看，OceanBase 想构建的是这样一个数据平面：

• 在线业务写入走 OLTP 路径，强一致、低延迟
• 分析查询通过列存副本承接，不干扰事务
• 冷数据下沉到对象存储的 Iceberg 表，按需查询
• 非结构化数据的 embedding 存在同一套系统里，支持混合检索
• Agent 通过统一 SQL 接口访问以上所有数据

对比一下：Databricks、Snowflake、还有一众向量库

这套架构最直接的对标就是 Databricks。Databricks 从 Spark 起家，靠 Delta Lake 把湖仓打通，去年又收购了 MosaicML 补 AI 能力，路线是“分析优先、AI 加持”。但它的短板一直是在线事务——你不会拿 Databricks 去支撑一个交易系统。

OceanBase 的路线正好反过来：从 OLTP 出发，往上长出分析和 AI 能力。这个起点的差别决定了两者适用的场景不同。金融、电信、政务这些对在线一致性和延迟敏感的行业，本来就是 OceanBase 的地盘，湖库一体让它有机会把这些客户的 AI 场景也吃下来，而不是让客户为了做 Agent 再去买一套 Databricks。

和 Snowflake 比，OceanBase 的开源属性和私有化部署能力在国内是显著优势。Snowflake 的存算分离架构很优雅，但在中国市场几乎不落地。

和纯向量数据库比，故事就更清楚了。Milvus、Qdrant 这类产品解决的是“如何高效检索向量”，但 Agent 应用真正需要的从来不是纯向量查询，而是结构化条件 + 全文 + 向量的混合过滤——比如“找出最近 30 天下单金额超过 1 万的用户中，客服工单语义最接近这条投诉的前 10 个”。这种查询在独立向量库里得靠应用层拼接，效率和一致性都难保证。OceanBase 把这一切放进 SQL 里，写起来就是一句话的事。

一些值得警惕的问题

把架构讲得很漂亮，落地起来是另一回事。有几个问题目前还没有清晰答案。

性能取舍怎么办。 OLTP 和 OLAP 共存已经不容易，再加上向量检索和湖上外表查询，任何一个负载压上来都可能影响其他。OceanBase 靠副本隔离和资源组做了些缓冲，但真到了大规模生产环境，工作负载互相干扰仍然是最容易翻车的点。

Iceberg 生态的兼容深度。 官方说支持开放表格式，但支持到什么程度——是只读、还是能写入？事务隔离级别怎么保证？和 Spark、Flink 生态的互操作有没有坑？这些技术细节发布会不会讲，得等社区版放出来大家实测。

AI 原生的成色。 seekdb 走的是独立开源路线，社区反馈还不错，但把它整合进主库之后，功能会不会打折？Embedding 生态、Rerank、多模态检索这些能力更新节奏能不能跟上开源向量库？这些是开发者选型时会真正在意的东西。

谁会买单

短期内，OceanBase 湖库一体最可能打动的是两类客户。

第一类是已经在用 OceanBase 做核心业务的大型企业，特别是金融和运营商。它们数据量大、对数据主权敏感、AI 项目又必须启动，与其再引入一套 Databricks 或者自建向量库集群，不如在现有数据库上加能力。银行搞智能客服、运营商做投诉分析，这种场景天然适合湖库一体的架构。

第二类是正在从传统 Oracle、MySQL 往云原生数据库迁移，同时又要规划 AI 中台的中大型企业。它们最怕的就是选型碎片化——OLTP 一个库、数仓一个平台、向量再一个组件，运维和数据同步的复杂度直接劝退。一个能覆盖大部分需求的统一平台，即使某些单项能力不是最强，综合成本也可能更划算。

至于个人开发者和中小团队，seekdb 的开源版本可能仍然是更合适的入口，毕竟湖库一体的完整能力主要面向企业级部署。

一点判断

数据库这个赛道过去几年最有意思的事情，是所有人都在往中间挤——OLTP 厂商想做分析，分析厂商想做 AI，向量库想接更多结构化能力。OceanBase 这次亮牌，等于是把“大一统”这条路径公开地押上了。

这条路能不能走通，取决于工程执行力和生态建设的速度，不是发布会能决定的。但方向本身值得关注——因为 Agent 时代对企业数据平台的要求，确实和过去分析报表时代不一样了。数据不再是被查询的对象，而是被 Agent 主动读、写、组合、推理的介质。这种场景下，减少系统间跳转、缩短数据到智能的路径，就是核心竞争力。

OceanBase 押的是这个方向。至于最终会不会有第二个玩家跟进，或者被更彻底的架构颠覆，还得看接下来这一年。

参考来源

目前公开的详细技术资料较少，建议关注 OceanBase 官方技术博客和后续社区版本发布，以获取湖库一体架构的实际落地细节和性能数据。