OceanBase CTO 楊傳輝
量子位 | 公眾號 QbitAI

AI時代茍日新，日日新，又日新，數據庫也是如此。

主流數據庫的發展經歷了幾次重要演進：從最早的OLTP數據庫，到OLAP從其中分離出來成為數據倉庫，再到大數據系統。長期以來，數據庫架構主要圍繞人類應用、確定性交易和結構化數據分析設計。

今天，新的變化正在發生。

AI Agent不再只是讀取數據、回答問題，而是開始調用工具、生成代碼、執行任務、修改狀態，甚至參與業務流程。數據庫的使用者，正在從人類應用擴展到大量自主運行的Agent。

這帶來一個根本問題：當成千上萬個Agent同時讀寫、搜索、試錯、回滾和生成上下文，數據庫還應該是過去的樣子嗎？

我認為，答案是否定的。

首先AI正在同時改變三件事：

• 數據庫的使用者，從應用擴展到Agent；
• 數據庫管理的數據，從結構化數據擴展到涵蓋結構化、半結構化與非結構化的多模態數據；
• 數據庫承載的工作負載，從事務和分析擴展到搜索、上下文工程與AI應用。

因此，AI數據庫不是傳統數據庫增加幾個AI函數，也不是向量數據庫補上SQL能力。它要解決的是AI進入生產系統后的數據基礎設施問題。

多模態數據需要在統一底座上被管理，在線服務和離線計算需要融合，Agent需要獲得實時、可信、連續的上下文，讀寫、試錯、回滾和治理中保持數據庫級一致性與可靠性。

這不是一次功能增強，而是在AI時代重新定義數據庫的技術架構。

AI時代，數據庫走向一體化

我們先看行業發生了什么。

Databricks和Snowflake從湖倉和數倉系統出發，不斷補充OLTP的事務能力；OceanBase和Oracle從交易庫出發，持續提升OLAP和大數據能力；MongoDB、Milvus、Elasticsearch從專用庫出發，連續增強通用數據庫的能力。

不管出發點如何，不同路線都正在向一個能夠同時處理交易、分析、搜索、向量以及AI計算的統一數據底座演進。

其中OceanBase一直堅持走一體化設計思路。

最早我們開始做分布式OLTP，解決了在線交易的擴展性和可靠性。后來我們又在OLTP基礎上加入了實時OLAP支持，消除了TP到AP的數據搬運。去年，我們發布了多模一體化，把向量、全文、JSON、GIS等能力帶進同一個數據庫引擎。

直到今天，我們正式發布OceanBase湖庫一體的AI數據庫，是沿著這條路繼續往前走：把庫里的實時事務能力、湖上的開放存儲和開放計算能力，放到同一個數據底座里。

什么是湖庫一體

我理解的湖庫一體（OceanBase Lakebase），不單單停留在數據庫外接一個數據湖，也不能只是給湖倉補幾個在線查詢接口。要讓它進入生產系統，至少要合并三條邊界：

第一，數據形態要統一。結構化數據、半結構化數據、非結構化數據、向量、圖、全文索引，不能分散在不同系統里各管一份。它們應該在同一套表語義下被管理。

第二，計算路徑要統一。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引擎立即可查；模型推理生成的向量，混合搜索立即可用。不再有“加工完了還要等同步”的窗口期。

這里實時性不是靠加速搬運實現的，而是靠消除搬運實現的。

多模表：AI數據庫的核心數據結構

OceanBase的第二個關鍵點在多模表。

原來的關系數據庫，底層是一張關系表——里面有Int、Float、Varchar，所有列都是結構化數據。

今天的AI數據庫，底層應該是一張多模表。

多模表既包括原有結構化數據的關系列，也包括非結構化數據的多模列與AI列。非結構化數據，可以在外部Embedding或者打標之后以向量或者文本的方式寫入到多模表，也可以直接以LOB的形式寫入到多模表。

OceanBase支持非常靈活的LOB存儲：

• 如果LOB對象比較小，直接在行內存儲，節省IO；
• 如果LOB對象比較大，切片后存入對象存儲，行內只保留每個切片的位置信息；
• 如果LOB對象特別大，支持引用外部對象存儲中的已有文件，數據庫只存儲元數據。上層應用看到的仍然是一張表。

在多模表之上，我們還設計了AI列。它可以理解成表上的實時計算列：數據寫入后，自動觸發Embedding、打標等模型計算，并把結果寫回表里。這里最重要的是事務一致性語義。比如一批音頻寫入后，要么全部完成Embedding和打標，要么全部失敗，不能出現部分成功、部分失敗的情況。

混合搜索：搜索作為AI數據庫的一類負載

有了多模表，接下來是在其上執行AI工作負載。AI數據庫里面，查詢的基本模式從關系查找進化為混合搜索——在同一張表里完成關系過濾、全文搜索、向量搜索、圖搜索以及AI計算。

為什么單純的向量搜索不夠？

向量搜索在AI數據庫里是最常見的一種計算方式，但在實際場景里，我們往往首先需要通過關系過濾將全局數據縮小為一個更小的候選集（例如“只看最近30天的訂單”），再在候選集上做向量、全文、圖的混合搜索。

數據庫先縮小范圍，模型只處理高價值候選，這樣推理成本更低、結果更準、鏈路更可控。

我們判斷，在AI時代，搜索會與OLTP、OLAP一樣回歸數據庫本體，成為數據庫的一類負載。

性能上，我們也做了系統的評測驗證。

結果顯示，使用HNSW算法，在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湖庫一體設計解決的就是這個問題。

底層通過基于對象存儲的多模表，實現多套計算引擎之間的數據共享，即一份數據同時服務所有計算引擎。OceanBase的SQL引擎處理在線查詢和事務；Spark處理PB級批量ETL；Daft on Ray處理AI推理，從而解決多套系統之間的數據一致性以及計算延遲的問題。

為了同時支持這么多開放計算引擎，我們需要一個統一開放的Catalog來管理數據。表、視圖、Schema、Lineage、行級權限、列級授權，都應該在這里統一管理。

OceanBase AI數據庫的所有操作在進入系統之前，都需要經過統一元數據與權限控制面做一層過濾，避免數據越權訪問。目前我們已支持了最細粒度的行級權限控制（RLS）。

為Agent設計：版本控制與彈性規模

為了讓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數據庫的引擎和應用之間還缺一層——上下文。

上下文層分為兩個部分。數據上下文，圍繞數據的語義和數據的治理展開，讓AI理解企業。應用上下文，圍繞Memory和RAG展開，讓AI理解用戶。

在記憶維度，Agent 的記憶不能簡單地堆上下文，而是一個可進化的結構化資產。為此我們研發了PowerMem，以及基于PowerMem的云上產品seekdb M0。

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也開發了OceanBase DataPilot產品。在不同行業的客戶POC測試中，客戶反饋準確率遠好于業界其他產品。

這背后不是模型的差異，而是語義上下文的質量差異——當AI擁有準確的業務口徑定義，從自然語言到SQL的翻譯準確率會本質性地提升。

一套技術棧降低工程復雜度

所有這些能力加在一起意味著什么？最直接的答案是：組件數量的大幅減少。

如果采用傳統方案，企業需要5到10個系統來融合處理多模態數據，且多個系統縫合帶來一系列問題，包括：CDC延遲、ETL失敗重試、多套獨立運維、多套權限體系、多套監控告警，等等。

通過OceanBase湖庫一體引擎，能夠實現多合一，通過一份數據保證一致性，通過離在線融合保證實時性。

小結：湖庫一體的AI數據庫

如果把這些能力放在一起看，OceanBase AI數據庫的架構可以概括為三層。

最底層是湖庫引擎——多模表運行在對象存儲之上。通過多模表和對象存儲，支持各種開放計算：OceanBase的SQL計算（OLTP、OLAP、搜索）以及Spark ETL和大模型AI計算。

中間是上下文層——數據上下文讓AI理解企業，應用上下文讓AI理解用戶。

最上層是我們開發的應用Agent——面向數據開發工程師的數據開發Agent，和面向業務分析師的數據分析Agent。

根據我們多年的Know-how經驗，要讓企業真的把AI用起來，最重要、最基本的一步，是通過一個一體化的AI數據庫，讓企業把自己的數據管理起來。只有管理好自己的數據，才能讓企業的AI更準、更省、更快、更安全。

湖庫一體的AI數據庫，這就是我們面向AI Agent時代給出的答案。