作者 | 王紹翾 @ProtonBase

　　本文內(nèi)容整理自 ProtonBase CEO 王紹翾在 AICon 的主題演講《Data Warebase: Instant Ingest-Transform-Explore-Retrieve for AI Applications》。作者的職業(yè)經(jīng)歷貫穿了 AI 1.0、2.0 和 3.0 的時代，從搜索推薦，到視覺 / 語音 / NLP 智能，再到當前正全力投入的大模型 AI 浪潮，本文將結合其多年來對數(shù)據(jù)基礎設施的實踐與反思，深入探討生成式 AI 時代對數(shù)據(jù)系統(tǒng)提出的全新挑戰(zhàn)與潛在機遇。

　　文章結構：

　　·Trending：數(shù)據(jù)基礎設施在 AI 時代的新趨勢

　　·Introducing Data Warebase：什么是 Data Warebase

　　·Data Warebase for AI Workload：如何支撐 AI 工作負載

　　·Use Cases of Data Warebase：典型落地場景

　　·The Difference Between Data Warebase and Other Technologies：與現(xiàn)有技術的差異與優(yōu)勢

　　Trending：數(shù)據(jù)基礎設施在 AI 時代的新趨勢

　　未來的所有應用，將主要對接兩個接口：一個 Data API，一個 AI API。

　　首先，回顧一下近期在數(shù)據(jù)領域以及 Data for AI 領域的相關思考。這段時間里，有三條重大新聞格外引人注目：

　　第一，Neon：Databricks 以 10 億美元收購 Neon 的舉措在行業(yè)內(nèi)引發(fā)了廣泛關注。目前，全球最具影響力的數(shù)據(jù)公司無疑是 Snowflake 和 Databricks——它們不僅在數(shù)據(jù)基礎設施領域占據(jù)核心地位，也正成為眾多企業(yè)構建 AI 能力的關鍵平臺。

　　第二，Supabase在 4 月底宣布完成新一輪融資，金額高達 2 億美元，估值也隨之攀升至 20 億美元。與此同時，市場上傳出有多家科技巨頭有意收購 Supabase 的消息，無疑為數(shù)據(jù)基礎設施領域注入了新的活力與關注度。

　　第三，ClickHouse也完成了最新一輪融資，估值已超 60 億美元。從其對外宣稱的目標來看，ClickHouse 似乎已經(jīng)準備好向 Snowflake 發(fā)起挑戰(zhàn)。

　　接下來，我將分享我對這三家公司近期為何備受資本青睞、頻頻獲得投資、收購關注的幾點觀察與思考。

　　趨勢一：大語言模型的出現(xiàn)正在顛覆傳統(tǒng)范式

　　在我離開達摩院之前，盡管其在語音識別和自然語言處理(NLP)等領域已采用了大語言模型(LLM)的技術路線，但當時尚未嘗試使用 LLM 對全網(wǎng)數(shù)據(jù)進行統(tǒng)一訓練。直到 OpenAI 的成功落地，整個行業(yè)才真正意識到這種方式的可行性與革命性。隨之而來的是，幾乎所有技術公司都開始擁抱大語言模型，將海量數(shù)據(jù)匯聚在一起，借助大語言模型的能力為每個人回答日常問題，重構人機交互體驗。

　　但從趨勢來看，未來具備能力訓練大模型的企業(yè)將是極少數(shù)。AI 工程之后的重點，將逐步從基礎模型的訓練轉向應用層的落地與價值釋放。而 AI 應用層的兩個關鍵支點正是：

　　·Inference（推理）：如何以高效、低成本的方式透出模型能力;

　　·Database for Application（面向 AI 應用的數(shù)據(jù)庫系統(tǒng)）：如何支撐上下文管理、向量檢索、數(shù)據(jù)調用與語義理解等數(shù)據(jù)層能力。

　　根據(jù)美國市場調研數(shù)據(jù)，已有約 70% 的企業(yè)已在實際生產(chǎn)業(yè)務中使用 AI 相關的能力，說明這場范式轉變已迅速從前沿技術走向主流實踐。

　　趨勢二：Agent 數(shù)量快速增長，數(shù)據(jù)底座成核心支撐

　　在前文提到的三家公司中，前兩家均專注于構建基于 PostgreSQL 數(shù)據(jù)庫的智能代理（Agent）服務，而第三家則聚焦于通過提供數(shù)據(jù)倉庫的能力為 AI 應用提供數(shù)據(jù)分析的能力。這一趨勢顯示出，大模型 Agent 的生態(tài)正快速繁榮，背后對高效、高可用的數(shù)據(jù)基礎設施的需求也在同步升級。未來，Agent 的數(shù)量會越來越多，誰能夠提供真正適配 AI Agent 的數(shù)據(jù)系統(tǒng)，將成為基礎設施競爭的核心關鍵。

　　Neon

　　首先我們先來看 Neon 是什么。

　　Neon 是一個基于開源 PostgreSQL 構建的云原生數(shù)據(jù)庫，它做了幾件非常關鍵、適合于 AI 應用開發(fā)者的事情：

　　第一，它將傳統(tǒng)的單機數(shù)據(jù)庫架構轉變?yōu)榇嫠惴蛛x的云架構。

　　這一點使得數(shù)據(jù)庫具備了更強的彈性與可擴展性，也為其后續(xù)的一些創(chuàng)新能力打下了基礎。

　　第二，在產(chǎn)品設計上，Neon 有兩個非常突出的亮點：

　　·Scale to Zero(按需彈性，空閑即釋放)

　　Neon 官網(wǎng)強調其核心優(yōu)勢之一在于 Scale to Zero，也就是說，當你不使用它時，它能夠將計算資源完全釋放，真正做到“用多少，付多少”，這對于資源敏感型應用尤其重要。

　　·Branching(數(shù)據(jù)庫分支管理)

　　另一個亮點是 Branching 概念。就像我們使用 Git 一樣，Neon 支持數(shù)據(jù)庫級別的“分支”操作。為什么需要這個?

　　因為在 AI Agent 開發(fā)過程中，越來越多的場景涉及大量試驗、多人協(xié)作、并行工作——允許開發(fā)者快速創(chuàng)建、管理和切換數(shù)據(jù)庫的獨立副本(分支)，極大提升了開發(fā)、測試和數(shù)據(jù)管理的靈活性。Neon 將數(shù)據(jù)庫轉變?yōu)橐粋�支持敏捷協(xié)作的開發(fā)平臺，為 AI 和數(shù)據(jù)工程打開了全新的范式。

　　一個有趣的觀察：AI Agent 正在大量創(chuàng)建數(shù)據(jù)庫

　　Neon 團隊也觀察到一個顯著趨勢：AI Agent 正在以前所未有的速度創(chuàng)建數(shù)據(jù)庫實例。

　　從 2024 年 10 月到 2025 年 5 月，短短 7 個月時間，數(shù)據(jù)庫創(chuàng)建量出現(xiàn)了爆發(fā)式增長。

　　從 Neon 發(fā)布的柱狀圖中可以看到，綠色部分代表由 AI 自動創(chuàng)建的數(shù)據(jù)庫，相較于人工創(chuàng)建的實例占比顯著提升，這說明 AI Agent 正在成為數(shù)據(jù)庫使用的新主力，數(shù)據(jù)庫平臺也必須為這種新型工作負載做好準備。

　　Supabase

　　Supabase 同樣是構建在 PostgreSQL 之上的數(shù)據(jù)庫平臺，它與 Neon 構成了直接的競爭關系。但與 Neon 相比，Supabase 提供了更為豐富的功能集，包括身份驗證、對象存儲、實時訂閱、邊緣函數(shù)等服務，幾乎可以看作是“開源版的 Firebase”，定位為開發(fā)者的一站式后端服務平臺。

　　為什么這些公司在最近備受關注?

　　這背后有一個非常清晰的趨勢判斷：大模型訓練的紅利期正在接近尾聲。雖然業(yè)界尚未正式宣布“訓練時代”的終結，但從資本和技術動向來看，未來再去投資新的基礎模型公司已不再是主流。相反，所有人的注意力都在向“應用層”聚焦——這就是我們觀察到的第一個重要現(xiàn)象：

　　Inference（推理）和數(shù)據(jù)應用正在成為新焦點。

　　無論是 Neon、Supabase，還是其他新興的數(shù)據(jù)基礎設施項目，本質上都在圍繞這個趨勢進行布局。

　　PostgreSQL：新興數(shù)據(jù)庫的共識基石

　　幾乎所有的新型數(shù)據(jù)庫項目都選擇基于 PostgreSQL 構建。我們剛才提到的 Neon 和 Supabase 只是其中的兩個代表，實際上，全球近幾年新出現(xiàn)的數(shù)據(jù)庫產(chǎn)品，CockroachDB，YugabyteDB，和 DuckDB 也都無一例外的選擇了 PostgreSQL 作為查詢 API。

　　PostgreSQL 靠其強大的可擴展性和生態(tài)，贏得了全球所有新興數(shù)據(jù)庫的青睞。

　　為什么 PostgreSQL 會成為事實上的行業(yè)標準？

　　原因很簡單：

　　·PostgreSQL 非常標準和規(guī)范，除了 SQL 本身就覆蓋了 OLTP 和 OLAP 的需求外，其最大的優(yōu)點就是有強大的可擴展性。它允許用戶通過擴展（Extensions）來增強數(shù)據(jù)庫功能（全文檢索，向量檢索，地理信息檢索，時序處理等等），而無需修改核心代碼。

　　·PostgreSQL 已形成強大的社區(qū)生態(tài)和工具支持。

　　以向量檢索為例：

　　PostgreSQL 提供了原生的pgvector 擴展，可以直接支持向量數(shù)據(jù)的存儲與檢索;而在 MySQL 標準中，缺乏可擴展性接口與生態(tài)，MySQL 數(shù)據(jù)庫系統(tǒng)往往需要自行定義向量數(shù)據(jù)存儲和檢索的 API，導致實現(xiàn)千差萬別，缺乏標準。這也是為什么越來越多的 AI 公司，特別是 OpenAI、Anthropic、Notion 等大型 AI 初創(chuàng)項目，都選擇 PostgreSQL 作為其核心數(shù)據(jù)引擎。

　　我曾看到一則非官方的報道：OpenAI 內(nèi)部的一個 PostgreSQL 只讀從庫就部署了近 50 個實例。 雖然目前 OpenAI 尚未采用分布式數(shù)據(jù)庫架構，但隨著業(yè)務規(guī)模的持續(xù)擴張，這或將成為其未來必須應對的架構挑戰(zhàn)。

　　Agent Talk to MCP：PostgreSQL 是默認選項之一

　　我即將介紹的一個概念是“Agent Talk to MCP(Model Context Protocol)”。這個概念最早由 Anthropic 提出，而在其官方文檔中，明確列出的第二個支持平臺就是 PostgreSQL。

　　這進一步印證了 PostgreSQL 在 AI 應用工作負載中的關鍵作用——它不僅是一種數(shù)據(jù)庫，更是 AI 系統(tǒng)與數(shù)據(jù)交互的中樞平臺。

　　ClickHouse 的定位演變與多模數(shù)據(jù)庫的崛起

　　相比 Neon 和 Supabase，ClickHouse 的定位其實有所不同。它本質上是一款數(shù)據(jù)倉庫。此前，在它的多輪對外宣傳中，一直強調自身是一個 Real-time Data Warehouse(實時數(shù)倉)。但最近我再次打開 ClickHouse 的官網(wǎng)，發(fā)現(xiàn)它也開始稱自己為 Database(數(shù)據(jù)庫)了(ClickHouse 確實一直在開發(fā) OLTP 的能力，只是一直還沒有正式發(fā)布)。這背后反映出一個趨勢：未來 AI 應用層將越來越依賴數(shù)據(jù)庫，尤其是多模態(tài)數(shù)據(jù)庫將成為核心基礎設施。

　　舉個例子：

　　·如果你正在開發(fā)一個基于 AI 的 Agent，它勢必需要與各種數(shù)據(jù)系統(tǒng)和應用系統(tǒng)交互。按照傳統(tǒng)架構的分工模式：事務性數(shù)據(jù)放在關系型數(shù)據(jù)庫中;

　　·數(shù)據(jù)的橫向水平分布式擴展用 MongoDB 或 HBase;

　　·搜索功能用 Elasticsearch(ES)實現(xiàn);

　　·分析需求用 ClickHouse 支撐;

　　這意味著，一個企業(yè)僅在數(shù)據(jù)底層就要維護至少 4 個不同的 MCP(Model Context Protocol )服務。這對大模型來說是個巨大的挑戰(zhàn)。理論上它可以理解這些差異化的服務，但實際運作中非常復雜，對其“智力”構成高強度負荷。能對接一個 MCP，誰還要對接 4 個呢?這也正是為什么越來越多的 AI 初創(chuàng)公司選擇 PostgreSQL，而未來大型企業(yè)在面向 AI 場景進行數(shù)據(jù)庫選型時，也一定會傾向選擇支持多模態(tài)的數(shù)據(jù)庫平臺。

　　雖然我們剛才提到訓練的時代接近尾聲，但訓練本身的問題依然存在，尤其是在存儲層面。我們曾有一句行業(yè)共識：“AI 的瓶頸在計算，計算的瓶頸在存儲。”這句話主要是針對模型訓練階段而言的。而我們以后更關注的將是AI 應用和 Workflow 的執(zhí)行效率。

　　當前，大模型并不能完全替用戶整理好所有數(shù)據(jù)，配合大模型一起工作的 AI workflow 主要集中在四個關鍵環(huán)節(jié)：

　　·Ingestion（數(shù)據(jù)攝取）

　　·Transform（數(shù)據(jù)加工）

　　·Explore（探索分析）

　　·Retrieve（查詢檢索）

　　訓練的瓶頸仍然存在，但重點正在轉向 AI 應用流程（AI Workflow）

　　雖然我們剛才提到訓練的時代接近尾聲，但訓練本身的問題依然存在，尤其是在存儲層面。我們曾有一句行業(yè)共識：“AI 的瓶頸在計算，計算的瓶頸在存儲。”這句話主要是針對訓練階段而言的。而我們現(xiàn)在更關注的是 AI 應用和 Workflow 的執(zhí)行效率。

　　當前，大模型并不能完全替你整理好所有數(shù)據(jù)，尤其在真實生產(chǎn)環(huán)境中，它也不會自動創(chuàng)建數(shù)據(jù)庫。它能做的，主要集中在我們前面提到的四個關鍵環(huán)節(jié)：

　　·Ingestion（數(shù)據(jù)攝取）

　　·Transform（數(shù)據(jù)加工）

　　·Explore（探索分析）

　　·Retrieve（查詢檢索）

　　AI workflow 從數(shù)據(jù)庫、應用日志、埋點系統(tǒng)等來源收集數(shù)據(jù);隨后通過數(shù)據(jù)清洗與轉換進行加工;加工后的數(shù)據(jù)可能進入 Feature Store，然后由數(shù)據(jù)工程師或算法專家進行探索與分析，做出參數(shù)調整等關鍵決策。當這些數(shù)據(jù)準備充分后，結合大模型的能力，便可實現(xiàn)下一階段的重要能力。

　　Multi-Modal Retrieval：下一代智能檢索范式

　　什么是 Multi-Modal Retrieval？ 它的核心含義是：在數(shù)據(jù)檢索過程中，不再局限于某一種查詢方式，而是融合結構化、半結構化、非結構化以及向量檢索等多種方式，實現(xiàn)更智能、更全面的查詢體驗。這項能力對于 AI 應用尤其重要。因為 Agent 面對的問題往往不是“查一條信息或者一個向量”，而是需要對多個模態(tài)、多維數(shù)據(jù)進行理解、關聯(lián)和調用——這就需要底層數(shù)據(jù)庫具備原生的多模處理能力。

　　以“智能城市”為例，如果我們需要在監(jiān)控系統(tǒng)中搜索某輛車或某個人，最基礎的方式可能僅涉及向量檢索——比如通過圖片或視頻幀進行相似度匹配。但一旦我們引入更具體的查詢條件，比如“某個十字路口”“某個下雨天”“某個時間段”，“和某個車的圖片相似”的場景就會涉及到更多模態(tài)的信息：

　　·“十字路口”是位置標簽;

　　·“下雨天”是環(huán)境標簽;

　　·“時間段”是結構化數(shù)據(jù);

　　·“車的圖片”會被 embedding 成向量數(shù)據(jù);

　　這類查詢就不再是單一模態(tài)的檢索，而是需要同時融合結構化數(shù)據(jù) + 標簽信息 + 向量檢索的 Multi-Modal Retrieval（多模態(tài)檢索）。

　　再比如在社交推薦場景中，人與人之間的推薦可能通過 Embedding 大部分特征成為向量，再靠向量相似度檢索來實現(xiàn)。但如果用戶添加了“同一個城市”或“同一活動”的過濾條件，就引入了地理位置或事件標簽，從而升級為真正的多模態(tài)檢索任務。

　　多模態(tài)檢索對架構提出了更高要求

　　實現(xiàn) Multi-Modal Retrieval，意味著系統(tǒng)必須同時處理：

　　·結構化數(shù)據(jù)；

　　·半結構化數(shù)據(jù)（如 JSON）；

　　·向量數(shù)據(jù)。

　　在傳統(tǒng)架構中，不同類型的數(shù)據(jù)往往被存儲在不同的系統(tǒng)中：

　　·結構化數(shù)據(jù)用關系數(shù)據(jù)庫或數(shù)倉;

　　·半結構化數(shù)據(jù)的存儲和檢索用 NoSQL;

　　·向量檢索用向量數(shù)據(jù)庫。

　　這樣的問題是當我們要執(zhí)行一個 Top 100 推薦任務時，分布在多個系統(tǒng)中的結果很難直接進行 Join 操作，因為性能很差。于是，我們只能嘗試從每個系統(tǒng)中提取大量結果(如 Top 100 萬)，再在應用層合并關聯(lián)處理。這個過程不僅開銷極大，而且也從理論上無法保障拿到最后正確的 Top 100。這正是 Hybrid Database（混合型數(shù)據(jù)庫）登場的理由：

　　將多種模態(tài)數(shù)據(jù)統(tǒng)一存儲與檢索，消除系統(tǒng)間的分割，讓多模態(tài)查詢變得自然、實時且可擴展。

　　AI Workflow 的五個關鍵需求

　　為了支撐真正的 AI 工作流，從數(shù)據(jù)獲取到結果交付，系統(tǒng)必須滿足以下五大核心能力：

　　1.Fresh Data（數(shù)據(jù)新鮮性） 模型必須基于最新的數(shù)據(jù)進行推理，數(shù)據(jù)滯后將嚴重影響 AI 產(chǎn)出質量。

　　2.Instant Retrieval（即時檢索）需要毫秒級的數(shù)據(jù)訪問能力，以滿足實時響應和推薦需求。

　　3.High Concurrency（高并發(fā)）特別是在面向 C 端或 Agent 場景中，系統(tǒng)需能支撐成千上萬用戶同時訪問，具備高吞吐能力。

　　4.Fast Analytics（快速分析）不僅要能存儲數(shù)據(jù)，還要能快速完成聚合、過濾、排序等分析任務，為 AI 決策提供支持。

　　5.Simplicity（易用性）整個系統(tǒng)要具備良好的開發(fā)者體驗和管理簡潔性，避免多工具鏈、多平臺切換帶來的復雜性。

　　這些能力構成了現(xiàn)代 AI 應用工作流的基礎保障。只有構建一個滿足實時性、融合性、高并發(fā)與易用性的數(shù)據(jù)平臺，才能真正釋放大模型和 Agent 的智能潛力。

　　為什么傳統(tǒng)數(shù)據(jù)庫和數(shù)據(jù)倉庫難以滿足 AI Workflow 的全部需求？

　　前面提到的那些產(chǎn)品之所以備受歡迎，本質上是它們各自解決了 AI 工作流中的關鍵痛點，但仍存在明顯局限：

　　·數(shù)據(jù)庫：擅長處理 Fresh Data(數(shù)據(jù)新鮮性) 和 Instant Retrieval(即時檢索)，適用于實時寫入和快速查詢場景。但其大多基于單機或簡單主從架構，難以支撐大規(guī)模的高并發(fā)訪問。

　　·數(shù)據(jù)倉庫（如 ClickHouse）：在 分析性能(Fast Analytics) 和 使用簡潔性(Simplicity) 方面表現(xiàn)出色，但它們普遍不適合高頻寫入或低延遲響應場景。

　　換句話說，沒有一個系統(tǒng)能夠同時兼顧 AI 應用的五大關鍵訴求。

　　Introducing Data Warebase ：什么是 Data Warebase

　　因此，我們提出了 Data Warebase 的概念——將 Data Warehouse 與 Database 融合于一體，構建統(tǒng)一的數(shù)據(jù)底座，以全面支撐 AI 工作流中從數(shù)據(jù)采集、加工、分析到檢索的全過程。

　　根據(jù)我們前文的架構模型，任何一家公司在構建數(shù)據(jù)系統(tǒng)時，都會面臨如下幾類核心需求：

　　·事務型數(shù)據(jù)庫：用于實時寫入與查詢(如訂單、行為日志)

　　·文本搜索引擎：處理非結構化關鍵詞匹配(如全文搜索)

　　·向量搜索引擎：支撐語義檢索

　　·分析引擎：進行數(shù)據(jù)分析(如行情分析、指標監(jiān)控、報表)

　　傳統(tǒng)做法是將這些功能拆分成多個獨立組件，組成所謂的“多引擎架構”，例如：

　　·使用 MongoDB 或 HBase 做分布式存儲;

　　·用 Elasticsearch 處理全文檢索;

　　·用向量數(shù)據(jù)庫做 vector 檢索;

　　·用 ClickHouse 或 Snowflake 執(zhí)行分析任務。

　　這種架構雖然功能齊全，但存在三大問題：

　　·系統(tǒng)運維復雜：需管理多個技術棧，版本依賴、部署、運維壓力大;

　　·數(shù)據(jù)割裂嚴重：數(shù)據(jù)需在多個系統(tǒng)間反復同步、復制，口徑難統(tǒng)一;

　　·性能和響應鏈路長：查詢需跨系統(tǒng)拼接，影響響應時間和穩(wěn)定性。

　　我們將這種架構稱為典型的 Legacy Data Architecture（傳統(tǒng)數(shù)據(jù)架構）。它已經(jīng)難以適配 AI 時代日益增長的實時性、統(tǒng)一性和智能化需求。

　　Data Warebase 的目標，正是通過統(tǒng)一架構，將多模數(shù)據(jù)能力集成于一個平臺之上，以更簡潔的方式支持復雜 AI Workflow。它不是將多個引擎簡單拼裝，而是從底層架構開始融合事務處理、搜索引擎、向量檢索和實時分析，真正做到“一個系統(tǒng)、全場景覆蓋”。

　　Data Warebase 本質上是一個多模數(shù)據(jù)庫

　　正如之前討論的，幾乎所有的數(shù)據(jù)問題理應由一個統(tǒng)一的數(shù)據(jù)系統(tǒng)解決，而這個系統(tǒng)必須對 AI 友好。AI Agent 需要一個多模數(shù)據(jù)庫來處理多種數(shù)據(jù)類型和任務，這一點我們之前已經(jīng)講過。

　　當客戶問到如何實現(xiàn)這個目標時，最初他們往往難以相信一個系統(tǒng)能集成如此多的功能，因為挑戰(zhàn)確實很大。簡單來說，如果數(shù)據(jù)量只有 100 行，實現(xiàn)之前提到的功能并不難，大多數(shù)單機數(shù)據(jù)庫都能輕松勝任。但當數(shù)據(jù)量達到 1 億、10 億甚至 100 億行時，挑戰(zhàn)才真正開始。

　　因此，Data Warebase 的核心競爭力在于支持行列混存且具有分布式橫向水平擴展的能力。這種能力主要依賴三個關鍵技術支撐：存儲、索引和存算分離。

　　打造 Data Warebase 的核心三要素：存儲、索引和存算分離

　　1.存儲架構：靈活多樣，兼顧 OLTP/ 搜索 /OLAP 的需求

　　無論是傳統(tǒng)數(shù)據(jù)庫還是大數(shù)據(jù)系統(tǒng)，都通過行存儲支持點查或高速查詢，通過列存儲支持分析和搜索。Data Warebase 系統(tǒng)中任何一張表支持三種存儲模式：行存表、列存表和行列混存表。

　　·行存：適用于鍵值查詢(KV)場景，支持快速單行訪問。

　　·列存：適合分析和倒排索引，支持高效壓縮和列級掃描。

　　·行列混存：在不確定負載特性時，自動兼顧行存與列存的優(yōu)勢。

　　2.索引體系：全面 / 完整 / 正交

　　Data Warebase 實現(xiàn)了多種索引機制，包括：

　　·OLTP 的全局二級索引：支持跨節(jié)點的數(shù)據(jù)定位。

　　·倒排索引：滿足文本搜索需求。

　　·列存索引：優(yōu)化分析查詢。

　　·JSON 索引：支持半結構化數(shù)據(jù)的高效訪問。

　　有了這些索引，結合智能查詢優(yōu)化器，系統(tǒng)能夠動態(tài)選擇最優(yōu)執(zhí)行路徑，實現(xiàn)復雜查詢的低延遲響應。從理論上講，這些技術在以前各種數(shù)據(jù)庫和大數(shù)據(jù)系統(tǒng)都分別實現(xiàn)了，我們只是把這些索引能力放在了一個數(shù)據(jù)庫中并把它落地成為了現(xiàn)實。

　　3.存算分離：數(shù)據(jù)庫的云原生創(chuàng)新

　　Data Warebase 采用云原生架構設計，將存儲與計算資源解耦：

　　·計算層：靈活彈性，支持按需擴展。

　　·熱存儲層：保證實時和近實時數(shù)據(jù)訪問的低延遲。

　　·冷存儲層：經(jīng)濟高效，滿足海量歷史數(shù)據(jù)存儲，并且支持直接查詢冷存上的數(shù)據(jù)(通過一些架構的優(yōu)化，冷存上的查詢延遲可以做到接近熱存，但是吞吐會遠低于熱存)。

　　不同于傳統(tǒng)大數(shù)據(jù)存算分離直接使用云上高可用的對象存儲，Data Warebase 在塊存儲云盤上自主設計了高性能分布式文件系統(tǒng)，實現(xiàn)了在線數(shù)據(jù)庫級別的存算分離，這個挑戰(zhàn)要比大數(shù)據(jù)系統(tǒng)的存算分離難一個數(shù)量級。

　　同時，存算分離架構帶來的秒級彈性(infinite scale & scale to zero)，負載隔離，和數(shù)據(jù)克隆(Branching)的能力，是實現(xiàn) AI Agent 靈活工作流和多場景并發(fā)計算的關鍵。

　　4.其他關鍵能力

　　·數(shù)據(jù)分區(qū)（Partitioning）：細粒度數(shù)據(jù)劃分，方便管理數(shù)據(jù)，在某些場景下可提升查詢性能。

　　·實時增量物化視圖：突破傳統(tǒng)物化視圖“全量重計算”的瓶頸，實現(xiàn) Subsecond 級別的增量更新，極大簡化實時 Transform 流程。

　　·時間旅行（Time Travel）功能：支持基于時間維度的數(shù)據(jù)版本管理，滿足 AI 訓練過程中的特征追蹤與歷史數(shù)據(jù)回溯需求。

　　總結一下，Data Warebase 的誕生之初就預見到未來的所有應用系統(tǒng)將 build 在兩個 API 之上：一個是 Data API，另一個是 AI API。 我們專注于做好 Data API，而它恰好在 AI 領域也能滿足 AI Workflow 的所有需求。我們下面來看看它是如何滿足這些需求的。

　　Data Warebase for AI Workload：如何支撐 AI 工作負載

　　為了滿足 AI workload 需求，Data Warebase 需要完成數(shù)據(jù)接入（Ingestion）、轉換（Transform）、探索（Explore）和檢索（Retrieve）。我們分別來看這幾個環(huán)節(jié)：

　　1.Ingestion

　　數(shù)據(jù)進來時，首先需要能夠快速地導入。Data Warebase 能夠支持數(shù)據(jù)庫級別的即時增刪改查操作，保障了數(shù)據(jù)“寫入即可見”，同時它支持通過 Foreign Table 直接從 Data Lake 中讀取數(shù)據(jù)。此外，作為一個數(shù)據(jù)庫，它還支持 CDC 輸出，而許多大數(shù)據(jù)系統(tǒng)并不支持這一點。這種能力確保了整個 Workflow 可以無縫串聯(lián)起來，同時保證了數(shù)據(jù)存儲的強一致性。

　　2.Transform

　　在 Transform 環(huán)節(jié)，我認為最重要的功能有三個：

　　·實時增量物化視圖

　　·Schema Evolving

　　·Generated Columns 和 Built-in Functions。

　　首先，實時增量物化視圖可以高效地處理數(shù)據(jù)的實時更新和查詢，大大提升了數(shù)據(jù)處理的效率。大部分數(shù)據(jù)庫系統(tǒng)只支持全量物化視圖和非常有限的增量物化視圖能力，所以用戶往往還需要 Flink 這種產(chǎn)品做數(shù)據(jù)的 Transform。Data Warebase 實現(xiàn)了完整了增量物化視圖的能力，以后數(shù)據(jù)的 Instant Transform 再也不需要 Flink 了。其次，Schema Evolving 允許數(shù)據(jù)模式靈活演變，能夠適應不斷變化的數(shù)據(jù)結構。再次，Generated Columns 功能也非常強大。用戶可以直接在原表上添加一個新的計算列，而無需使用物化視圖，這使得 Transform 變得非常容易，成本更低。最后，Built-in Functions 可以輕松解決大量數(shù)據(jù)加工的 ETL 工作。

　　3. Explore

　　在數(shù)據(jù)經(jīng)過 Transform 之后，用戶需要在上面進行各式各樣的查詢和分析。我剛才提到，多模數(shù)據(jù)庫非常重要，因為很多查詢不僅僅是純分析型 OLAP 的，也不是純事務型的，而是需要混合型的查詢能力。此外，對于 AI 工程師來說，Sampling 功能也非常重要，因為他們需要通過采樣來觀察數(shù)據(jù)的趨勢。最后，正如剛才提到的，在有些時候算法工程師需要研究 Feature 的變化對模型的影響，因此他們需要知道一個 Feature 在不同時間點的精確數(shù)值，在普通的大數(shù)據(jù)系統(tǒng)中，這需要不斷地存儲所有 Feature 不同時間的數(shù)值，造成大量的存儲浪費。Data Warebase 作為一款數(shù)據(jù)庫，支持 Transaction 和 MVCC，因此有很好的 built-in 的 Time Travel 的能力，可以給算法同學提供低成本的 Feature 按時序觀測的能力。

　　4.Retrieve

　　在 Retrieve 環(huán)節(jié)，最關鍵的是要能做多模檢索。如果沒有多模檢索的能力，很多應用場景幾乎是無法實現(xiàn)的。剛才介紹的幾個具體場景，也看到了越來越多的場景需要這種能力。因此，多模檢索能力決定了系統(tǒng)在處理更復雜場景時的表現(xiàn)，尤其是當數(shù)據(jù)量增大時。如果數(shù)據(jù)量很小，比如只有 100 行數(shù)據(jù)，那么問題不大，但隨著數(shù)據(jù)量的增加，這種能力就顯得尤為重要。

　　Use Cases of Data Warebase：典型落地場景

　　接下來分享幾個 Data Warebase 落地案例。簡單來說，可分為六大類。但從抽象層面來講，其實只有兩大類型。

　　·依靠多模能力精簡架構(Simplicity)：例如 AI Agent 和 Feature Store， 未來大部分服務將依托 AI Agent 進行智能交互，而 AI Agent 需要一個強大的 Data API，Data Warebase 提供了強大的多模查詢、極致彈性、以及分支管理的能力，能夠很好地支持 AI Agent 的場景。

　　·實時決策 (Instant Decision)： 例如超實時高吞吐的金融行情分析和風控，高彈性高吞吐的運維可觀測性場景，車聯(lián)網(wǎng)車機信號實時監(jiān)控與故障診斷需求，以及實時搜索廣告推薦系統(tǒng)。

　　關于 AI Agent，之前已經(jīng)解釋過不再贅述。Instant Decision 下的一個大類是可觀測性。可觀測性從廣義上來說，萬物似乎都具備可觀測性，但這個范疇太寬泛了。而狹義的可觀測性，主要是指對日志、標簽和行為的分析。以前，這個領域主要是時序數(shù)據(jù)庫的天下。然而，大家后來發(fā)現(xiàn)時序數(shù)據(jù)庫存在一些局限性，比如它只能做數(shù)據(jù)的 Append 插入，不能 Update，也無法進行文本檢索和復雜的分析查詢。

　　于是，大家開始使用 ES 和 ClickHouse。不過，ES 最大的問題是冷熱數(shù)據(jù)分層的挑戰(zhàn)(冷數(shù)據(jù)需要重新加載，否則無法直接訪問)，而且它主要只能用于標簽過濾和文本檢索。ClickHouse 在大寬表上做多維分析的性能非常不錯，但它的 Upsert 能力和 Join 操作性能并不理想。更重要的是，在可觀測性場景下，彈性能力至關重要。因為在系統(tǒng)正常運行、沒有報警或行情平穩(wěn)時，可能只有小幾個人在觀測;而一旦系統(tǒng)出現(xiàn)問題或者來了一波新的金融行情，會有更多的人涌入查看，系統(tǒng)很容易崩潰。因此，云上的彈性能力非常重要。Data Warebase 因為使用了最領先的存算分離架構，可以做到業(yè)務無感情況下的秒級彈性擴縮容。

　　所以，其實可觀測性場景即需要 Simplicity 又需要 Instant Decision 的能力。

　　而在金融領域，像 Trading、Fraud Detection，以及車聯(lián)網(wǎng)領域中的信號收集、檢測和報警，以及 Ads、Search 和 Recommendation 這幾類場景中，它們都屬于需要 Instant Decision 的場景。接下來介紹幾個具體案例。

　　案例一：AI Agent

　　未來的 AI Agent，不需要對接多個 MCP，而是連接一個多模數(shù)據(jù)庫。用一個數(shù)據(jù)庫，一個 MCP 接口，極大降低 LLM 大模型的智力和推理的門檻。

　　首先是 AI Agent。未來，所有的服務都將提供 AI Agent 的服務。以我們的產(chǎn)品為例，會出現(xiàn)至少兩個大的 MCP 出口。

　　第一個 MCP 是數(shù)據(jù)庫本身。 我們用標準的 PG MCP 就可以把數(shù)據(jù)庫服務暴露給大模型調用�？蛻艏瓤梢允褂� SQL 來查詢，也可以通過大模型來訪問我們的產(chǎn)品，使用 Data Warebase 會變得更加簡單。

　　第二個 MCP 是平臺服務。 除了數(shù)據(jù)庫本身，Data Warebase 還提供平臺服務(擴縮容，監(jiān)控，報警)，這些平臺服務也可以對外暴露 MCP 服務。這樣，客戶的 OPS 系統(tǒng)可以通過 AI 來智能了解數(shù)據(jù)庫的運行情況。運維同學可以直接提出具體的問題，比如“今天一天中哪個時間點的 Workload 最高?”“今天的 Workload 比昨天高了多少?”“有哪些指標有些異常?”.

　　平臺服務以前主要是通過 SDK 來實現(xiàn)的，但現(xiàn)在都轉向了 MCP。未來應用層的業(yè)務邏輯會越來越薄，業(yè)務應用慢慢的都會變成只由前端界面、AI 和數(shù)據(jù)這 3 層架構來支持。

　　另外，我剛才提到的 Data Warebase 的混合查詢能力非常強。用戶再也不用擔心要管理多個數(shù)據(jù)庫，一個數(shù)據(jù)庫就能搞定大部分的事情。此外 Data Warebase 還支持 Scale to Zero，也就是說，當沒有連接和 Activity 的時候，計算資源可以直接釋放掉。同時，它也能支持無限的水平擴容。最后，剛才提到的存算分離架構能夠很好地支持數(shù)據(jù) Snapshot 的快速復制，可以很好地滿足 AI Agent 在 Branching 上的能力需求。

　　案例二：金融行業(yè)案例

　　第二個案例是金融行業(yè)的一個場景，你可以把它理解為一個交易系統(tǒng)。這個系統(tǒng)會接收到大量的行情數(shù)據(jù)，這些數(shù)據(jù)需要在客戶端以最快的速度展示(Freshness 在亞秒級)，因為每當有一個交易完成后，后面會有大量的 AI 機器人做分析和交易決策。所以，數(shù)據(jù)輸入必須是 Instant 的，要求“寫入即可見”，并且查詢量非常大。另外，它的查詢也比一般的點查復雜的多。它不僅僅是簡單地查看一行行數(shù)據(jù)，而是需要通過大量的標簽進行過濾做多維分析，以便能夠只觀測某些特別關注的標簽并據(jù)此做出決策。這也是為什么我之前提到可觀測性的范疇非常大，從理論上講，這也是可觀測性的一個應用場景。

　　在這種能力要求下，傳統(tǒng)數(shù)據(jù)庫能夠滿足的是 Subsecond Level 的新鮮度和高吞吐量，但它無法滿足多維分析的需求。而 Search 和 Lakehouse 架構能夠在一定程度上滿足分析需求，但它們無法同時滿足高吞吐量和低延遲的要求。所以，正如我之前所說，Data Warebase 的這種真正的混合能力，也就是多模查詢的能力，在這里就顯得非常重要。

　　案例三：車聯(lián)網(wǎng)案例

　　第三個案例是車聯(lián)網(wǎng)。我們接入了一個頭部的車聯(lián)網(wǎng)用戶，它的車機信號傳輸頻率非常高，每輛車每秒都會上傳車機信號，100 萬輛車就意味著每秒有 100 萬條數(shù)據(jù)涌入。以往，這些數(shù)據(jù)進來后，我們只是將其存儲起來，以滿足監(jiān)管要求。但如今，隨著電動車越來越受歡迎，情況發(fā)生了變化。大家都知道，電動車的系統(tǒng)升級是通過 OTA 來實現(xiàn)的，而不是像傳統(tǒng)汽車那樣需要開到車廠，插上線進行升級。這些電動車會不斷地推送軟件更新，而這些軟件更新可能會對車機產(chǎn)生影響。所以，現(xiàn)在數(shù)據(jù)進來之后，我們還需要對某些關鍵列進行分析。即使在不升級的時候，也需要對核心車輛信號做實時監(jiān)控報警，確保車輛和車主的安全。

　　以前的分析型數(shù)據(jù)庫可以統(tǒng)計一些聚合值，但不擅長明細查詢，因為明細查詢的時候可能需要對非主鍵字段做過濾，需要真正的全局二級索引，而這種索引一般也只有 OLTP 數(shù)據(jù)才具有。所以，這種場景非常適合使用多模數(shù)據(jù)庫。

　　案例四：廣告和推薦案例

　　第四個案例是廣告和推薦。廣告的量比推薦大，因為大部分廣告公司收集了眾多 APP 的流量，且每次做決策時的查詢邏輯也比較復雜。當我們在使用各種手機應用時，每次跳轉到下一個界面，其實都是一個決策過程。這些決策過程中查詢的數(shù)據(jù)量非常龐大。推薦系統(tǒng)也是如此，現(xiàn)在幾乎所有的推薦系統(tǒng)，尤其是電商平臺的推薦系統(tǒng)，都需要相對實時地進行決策。

　　例如，當你在電商平臺上搜索 1000 元的手機時，系統(tǒng)會在下一秒為你推薦 1000 元左右的手機，而不是 1 萬元的手機，因為系統(tǒng)已經(jīng)根據(jù)你的搜索范圍做出了精準的判斷。對于新用戶，系統(tǒng)可能一開始對你不了解，但一旦你購買了某一類藥品，系統(tǒng)就能根據(jù)這一行為推斷出你的大概年齡段和性別，從而進行個性化推薦。后續(xù)的推薦決策會變得更加積極主動，進一步提升用戶體驗。這種實時性和個性化的能力，是現(xiàn)代推薦系統(tǒng)區(qū)別于傳統(tǒng)推薦系統(tǒng)的重要特征。這種推薦系統(tǒng)同樣需要實時寫入，且高頻分析查詢。

　　總結一下，今天主要分享了在 Data for AI 時代我觀察到的現(xiàn)象和思考，以及 Data Warebase 的概念。最后，介紹了 Data Warebase 如何滿足 AI 應用在 Ingestion、Transform、Explore 和 Retrieve 等方面的需求。

　　Data Warebase 與現(xiàn)有技術的差異與優(yōu)勢

　　最后再簡單提一下很多小伙伴過來詢問 Data Warebase 與現(xiàn)有技術的差異與優(yōu)勢。

　　1. Data Warebase 與 HTAP 的區(qū)別

　　首先從客戶的角度來看，不應該常常要關心去區(qū)分 TP 和 AP，因為 SQL 本身是能寫出來 TP 和 AP 的 Query 來的。只是在數(shù)據(jù)量大的時候，一個系統(tǒng)要么是 TP 性能好一點，要么是 AP 的性能會好一點。所以 HTAP 要求的是一個系統(tǒng)能夠在 TP 場景和 AP 場景下性能都非常好。

　　真正的 HTAP，不止是簡單 TP+AP 的結合，更多的是存儲，索引，和查詢優(yōu)化器一體的結合。

　　其次，HTAP 的核心在于是否能真正實現(xiàn) TP 和 AP 的無縫融合。如果只是將 TP 系統(tǒng)的數(shù)據(jù)同步到 AP 系統(tǒng)去滿足報表查詢，這并不算真正的 HTAP。真正的 HTAP 需要具備以下特點：

　　·真正的 HTAP 數(shù)據(jù)庫應該既能獨立作為一個 OLTP 數(shù)據(jù)庫，也能獨立的作為一個 OLAP 數(shù)據(jù)庫，還能變成一個混合的 HTAP 數(shù)據(jù)庫。

　　·低延遲：數(shù)據(jù)能夠即時進入系統(tǒng)，無論在什么模式下，數(shù)據(jù)寫入即可見，并且立即能夠無延遲的服務 AP 查詢。

　　·高吞吐：能夠支持高吞吐的查詢。

　　·復雜查詢：支持完整的復雜的 OLAP 分析查詢。

　　如果沒有復雜查詢的需求，那么基本可以通過傳統(tǒng)的 TP 系統(tǒng)解決。只有像金融行情分析這樣的場景，需要數(shù)據(jù)實時寫入和高吞吐的復雜查詢，才是真正的 HTAP。Data Warebase 因為具有行列混存的能力以及豐富的索引，天然的支持 HTAP，用戶做了合理的存儲和索引的配置后，所有查詢 SQL 都能在物理極限上拿到最高的吞吐和最低的延遲。用戶再也不用為不同場景的數(shù)據(jù)庫選型而擔心。

　　2. Data Warebase 與流批一體的區(qū)別

　　流批一體的終極解法，不是 Flink，而是數(shù)據(jù)庫的實時增量物化視圖。

　　流批一體是我們最早在阿里搜索主搜時提出的，當時用 Flink 做實時處理，再用批計算，后來我們用 Flink 的批處理統(tǒng)一了流和批的計算框架和 SQL。但 Flink 運維難、成本高，我們認為物化視圖是解決流批一體的最佳方案。大部分數(shù)據(jù)系統(tǒng)只是支持全量物化視圖和非常有限的增量物化視圖(例如雙表的 join，大部分數(shù)據(jù)系統(tǒng)只能通過全量物化視圖來做)。Data Warebase 實現(xiàn)了實時增量物化視圖，這使得真正的流批一體最簡單的方案成為現(xiàn)實。

　　3. Data Warebase 與湖倉一體的區(qū)別

　　關于湖倉一體，簡單來說，就是讓倉和湖之間的數(shù)據(jù)能夠打通，流轉起來，最終讓倉可以直接訪問湖的數(shù)據(jù)，做一些查詢加速。其次要求數(shù)據(jù)倉庫能夠對接標準的湖存儲，做外表的查詢，計算和寫入。

　　剛才講的是數(shù)據(jù)庫的趨勢。如果放大到大數(shù)據(jù)的趨勢，只有一件事值得關注：未來數(shù)據(jù)湖的標準只有一個，就是 Iceberg。因為全球兩大數(shù)據(jù)巨頭 Snowflake 和 Databricks 都在圍繞 Iceberg 展開。Snowflake 的存儲一開始就是基于 Iceberg 設計和實現(xiàn)的，Databricks 之前有自研的 Delta Lake，后來收購了 Iceberg 背后的公司 Tabular。所以我們可以預見，未來這兩個世界最大的數(shù)據(jù)巨頭都會圍繞著 Iceberg 來布局數(shù)據(jù)湖生態(tài)。

　　結 語

　　數(shù)據(jù)庫和大數(shù)據(jù)演進到 Data Warebase，不只是架構革新，更是為 AI 工作流打下堅實的數(shù)據(jù)底座。在新一輪的 AI 浪潮中，誰擁有更完整更強大的 Data API，誰就擁有更高的智能上限。

　　作者簡介：

　　王紹翾，ProtonBase 創(chuàng)始人兼 CEO。曾在 Facebook 負責在線基礎設施開發(fā)，并深度參與了 Memcache，RocksDB 和自研分布式圖數(shù)據(jù)庫 TAO 的開發(fā)，該數(shù)據(jù)庫支撐了 Facebook 每秒幾十億次的海量數(shù)據(jù)查詢。2015 年加入阿里巴巴，先后負責兩項核心工作：一是用 Flink 打造了搜索推薦相關的數(shù)據(jù)處理與 AI 機器學習平臺，二是負責達摩院機器智能工程團隊，包括視覺 / 語音 /NLP 等 AI 場景的模型訓練，推理，以及向量檢索技術。2021 年開始創(chuàng)業(yè)，創(chuàng)立“小質科技”，推出了自研產(chǎn)品 ProtonBase，一款融合數(shù)據(jù)庫與數(shù)據(jù)倉庫能力于一體的新一代 Data Warebase(Data Warehouse + Database)。