OceanBase 推湖库一体架构：一套技术栈统一离在线，重新定义 AI 数据库

在 AI 浪潮席卷数据库行业的今天，OceanBase 给出了一套激进的解答。7 月 1 日，OceanBase CTO 杨传辉在公开分享中正式发布了湖库一体（OceanBase Lakebase）AI 数据库，核心思路是用一套技术栈实现离在线统一，将实时事务能力与湖上开放存储、开放计算能力融合进同一个数据底座。

杨传辉指出，AI 时代正在从三个层面颠覆数据库的既有定义：使用者从人类应用扩展到大量自主运行的 AI Agent；管理的数据从结构化扩展到结构化、半结构化与非结构化的多模态；承载的工作负载从事务和分析扩展到搜索、上下文工程与 AI 应用。在他看来，AI 数据库不是传统数据库增加几个 AI 函数，也不是向量数据库补上 SQL 能力，而是要解决 AI 进入生产系统后的数据基础设施问题。

杨传辉认为，湖库一体要真正进入生产系统，至少需要合并三条边界：数据形态统一——结构化、半结构化、非结构化、向量、图、全文索引在同一套表语义下管理；计算路径统一——SQL 查询、实时分析、混合搜索、Spark ETL、Ray 上的 AI 计算围绕同一份数据工作，无需导出、转换、中间落盘；治理边界统一——元数据、权限、行级控制、审计、版本、生命周期对所有数据类型一致生效。

基于此，OceanBase Lakebase 采用存算分离架构，数据存储于对象存储，计算层独立运行，以应对 AI Agent 突发式的工作负载。中间层通过多模表统一各类数据，上层支持开放计算，除原有 SQL 计算外，还支持 Spark 处理 ETL、Daft on Ray 处理 AI 加工。杨传辉强调，湖的价值在开放、弹性和成本，库的价值在事务、一致性、低延迟和治理，AI 时代需要将这两组能力合并。

OceanBase 引入多模表作为 AI 数据库的核心数据结构。多模表既包含结构化数据的关系列，也包含非结构化数据的多模列与 AI 列。非结构化数据可以以向量、文本或 LOB 形式写入。OceanBase 支持灵活的 LOB 存储：小对象行内存储节省 IO；大对象切片后存入对象存储，行内保留切片位置信息；超大对象支持引用外部对象存储中的已有文件，数据库仅存储元数据。

在多模表之上，OceanBase 设计了 AI 列，可视为表上的实时计算列：数据写入后自动触发 Embedding、打标等模型计算，并将结果写回表内，且保证事务一致性语义——一批数据要么全部完成处理，要么全部失败。

有了多模表，OceanBase 将查询的基本模式从关系查找进化为混合搜索，在同一张表内完成关系过滤、全文搜索、向量搜索、图搜索以及 AI 计算。杨传辉解释，纯向量搜索在实际场景中往往不够，需要先用关系过滤缩小候选集（如“只看最近 30 天的订单”），再在候选集上做混合搜索，从而降低推理成本、提升结果准确性。

性能评测显示，在 768 维和 1536 维的 HNSW 算法测试中，同等召回率下 OceanBase 的向量搜索性能远领先于 Milvus、Elasticsearch 和 pgvector；在 MS MARCO 数据集上的混合搜索性能相比 Elasticsearch 提升 30% 以上。

针对 AI 数据链路中多系统并存的现状，OceanBase 湖库一体通过基于对象存储的多模表实现多套计算引擎间的数据共享。SQL 引擎处理在线查询和事务，Spark 处理 PB 级批量 ETL，Daft on Ray 处理 AI 推理，所有引擎围绕同一份数据工作，消除了系统间的数据搬运和延迟。

杨传辉总结，传统做法中数据加工是离线的，加工结果需搬回在线系统才能服务应用，存在 T+1 甚至更长的延迟。湖库一体直接将离线加工和在线服务统一在同一份数据上：Spark ETL 的产出，SQL 引擎立即可查；模型推理生成的向量，混合搜索立即可用。实时性不是靠加速搬运实现的，而是靠消除搬运实现的。