Data Warebase 成功押注 PostgreSQL 生態，或成 AI 時代數據底座

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

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

第三,ClickHouse 也完成了最新一輪融資,估值已超 60 億美元。從其對外宣稱的目標來看,ClickHouse 似乎已經準備好向 Snowflake 發起挑戰。

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

趨勢一:大語言模型的出現正在顛覆傳統范式

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

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

·Inference(推理):如何以高效、低成本的方式透出模型能力;

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

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

趨勢二:Agent 數量快速增長,數據底座成核心支撐

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

Neon

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

Neon 是一個基于開源 PostgreSQL 構建的云原生數據庫,它做了幾件非常關鍵、適合于 AI 應用開發者的事情:

第一,它將傳統的單機數據庫架構轉變為存算分離的云架構。

這一點使得數據庫具備了更強的彈性與可擴展性,也為其后續的一些創新能力打下了基礎。

第二,在產品設計上,Neon 有兩個非常突出的亮點:

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

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

·Branching(數據庫分支管理)

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

因為在 AI Agent 開發過程中,越來越多的場景涉及大量試驗、多人協作、并行工作——允許開發者快速創建、管理和切換數據庫的獨立副本(分支),極大提升了開發、測試和數據管理的靈活性。Neon 將數據庫轉變為一個支持敏捷協作的開發平臺,為 AI 和數據工程打開了全新的范式。

一個有趣的觀察:AI Agent 正在大量創建數據庫

Neon 團隊也觀察到一個顯著趨勢:AI Agent 正在以前所未有的速度創建數據庫實例。

從 2024 年 10 月到 2025 年 5 月,短短 7 個月時間,數據庫創建量出現了爆發式增長。

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

Supabase

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

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

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

Inference(推理)和數據應用正在成為新焦點。

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

PostgreSQL:新興數據庫的共識基石

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

PostgreSQL 靠其強大的可擴展性和生態,贏得了全球所有新興數據庫的青睞。

為什么 PostgreSQL 會成為事實上的行業標準?

原因很簡單:

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

·PostgreSQL 已形成強大的社區生態和工具支持。

以向量檢索為例:

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

我曾看到一則非官方的報道:OpenAI 內部的一個 PostgreSQL 只讀從庫就部署了近 50 個實例。 雖然目前 OpenAI 尚未采用分布式數據庫架構,但隨著業務規模的持續擴張,這或將成為其未來必須應對的架構挑戰。

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

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

這進一步印證了 PostgreSQL 在 AI 應用工作負載中的關鍵作用——它不僅是一種數據庫,更是 AI 系統與數據交互的中樞平臺。

ClickHouse 的定位演變與多模數據庫的崛起

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

舉個例子:

·如果你正在開發一個基于 AI 的 Agent,它勢必需要與各種數據系統和應用系統交互。按照傳統架構的分工模式:事務性數據放在關系型數據庫中;

·數據的橫向水平分布式擴展用 MongoDB 或 HBase;

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

·分析需求用 ClickHouse 支撐;

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

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

當前,大模型并不能完全替用戶整理好所有數據,配合大模型一起工作的 AI workflow 主要集中在四個關鍵環節:

·Ingestion(數據攝取)

·Transform(數據加工)

·Explore(探索分析)

·Retrieve(查詢檢索)

訓練的瓶頸仍然存在,但重點正在轉向 AI 應用流程(AI Workflow)

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

當前,大模型并不能完全替你整理好所有數據,尤其在真實生產環境中,它也不會自動創建數據庫。它能做的,主要集中在我們前面提到的四個關鍵環節:

·Ingestion(數據攝取)

·Transform(數據加工)

·Explore(探索分析)

·Retrieve(查詢檢索)

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

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

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

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

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

·“下雨天”是環境標簽;

·“時間段”是結構化數據;

·“車的圖片”會被 embedding 成向量數據;

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

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

多模態檢索對架構提出了更高要求

實現 Multi-Modal Retrieval,意味著系統必須同時處理:

·結構化數據;

·半結構化數據(如 JSON);

·向量數據。

在傳統架構中,不同類型的數據往往被存儲在不同的系統中:

·結構化數據用關系數據庫或數倉;

·半結構化數據的存儲和檢索用 NoSQL;

·向量檢索用向量數據庫。

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

將多種模態數據統一存儲與檢索,消除系統間的分割,讓多模態查詢變得自然、實時且可擴展。

AI Workflow 的五個關鍵需求

為了支撐真正的 AI 工作流,從數據獲取到結果交付,系統必須滿足以下五大核心能力:

1.Fresh Data(數據新鮮性) 模型必須基于最新的數據進行推理,數據滯后將嚴重影響 AI 產出質量。

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

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

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

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

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

為什么傳統數據庫和數據倉庫難以滿足 AI Workflow 的全部需求?

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

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

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

換句話說,沒有一個系統能夠同時兼顧 AI 應用的五大關鍵訴求。

Introducing Data Warebase :什么是 Data Warebase

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

根據我們前文的架構模型,任何一家公司在構建數據系統時,都會面臨如下幾類核心需求:

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

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

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

·分析引擎:進行數據分析(如行情分析、指標監控、報表)

傳統做法是將這些功能拆分成多個獨立組件,組成所謂的“多引擎架構”,例如:

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

·用 Elasticsearch 處理全文檢索;

·用向量數據庫做 vector 檢索;

·用 ClickHouse 或 Snowflake 執行分析任務。

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

·系統運維復雜:需管理多個技術棧,版本依賴、部署、運維壓力大;

·數據割裂嚴重:數據需在多個系統間反復同步、復制,口徑難統一;

·性能和響應鏈路長:查詢需跨系統拼接,影響響應時間和穩定性。

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

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

Data Warebase 本質上是一個多模數據庫

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

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

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

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

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

無論是傳統數據庫還是大數據系統,都通過行存儲支持點查或高速查詢,通過列存儲支持分析和搜索。Data Warebase 系統中任何一張表支持三種存儲模式:行存表、列存表和行列混存表。

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

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

·行列混存:在不確定負載特性時,自動兼顧行存與列存的優勢。

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

Data Warebase 實現了多種索引機制,包括:

·OLTP 的全局二級索引:支持跨節點的數據定位。

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

·列存索引:優化分析查詢。

·JSON 索引:支持半結構化數據的高效訪問。

有了這些索引,結合智能查詢優化器,系統能夠動態選擇最優執行路徑,實現復雜查詢的低延遲響應。從理論上講,這些技術在以前各種數據庫和大數據系統都分別實現了,我們只是把這些索引能力放在了一個數據庫中并把它落地成為了現實。

3.存算分離:數據庫的云原生創新

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

·計算層:靈活彈性,支持按需擴展。

·熱存儲層:保證實時和近實時數據訪問的低延遲。

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

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

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

4.其他關鍵能力

·數據分區(Partitioning):細粒度數據劃分,方便管理數據,在某些場景下可提升查詢性能。

·實時增量物化視圖:突破傳統物化視圖“全量重計算”的瓶頸,實現 Subsecond 級別的增量更新,極大簡化實時 Transform 流程。

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

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

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

為了滿足 AI workload 需求,Data Warebase 需要完成數據接入(Ingestion)、轉換(Transform)、探索(Explore)和檢索(Retrieve)。我們分別來看這幾個環節:

1.Ingestion

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

2.Transform

在 Transform 環節,我認為最重要的功能有三個:

·實時增量物化視圖

·Schema Evolving

·Generated Columns 和 Built-in Functions。

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

3. Explore

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

4.Retrieve

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

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

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

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

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

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

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

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

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

案例一:AI Agent

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

首先是 AI Agent。未來,所有的服務都將提供 AI Agent 的服務。以我們的產品為例,會出現至少兩個大的 MCP 出口。

第一個 MCP 是數據庫本身。 我們用標準的 PG MCP 就可以把數據庫服務暴露給大模型調用。客戶既可以使用 SQL 來查詢,也可以通過大模型來訪問我們的產品,使用 Data Warebase 會變得更加簡單。

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

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

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

案例二:金融行業案例

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

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

案例三:車聯網案例

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

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

案例四:廣告和推薦案例

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

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

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

Data Warebase 與現有技術的差異與優勢

最后再簡單提一下很多小伙伴過來詢問 Data Warebase 與現有技術的差異與優勢。

1. Data Warebase 與 HTAP 的區別

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

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

其次,HTAP 的核心在于是否能真正實現 TP 和 AP 的無縫融合。如果只是將 TP 系統的數據同步到 AP 系統去滿足報表查詢,這并不算真正的 HTAP。真正的 HTAP 需要具備以下特點:

·真正的 HTAP 數據庫應該既能獨立作為一個 OLTP 數據庫,也能獨立的作為一個 OLAP 數據庫,還能變成一個混合的 HTAP 數據庫。

·低延遲:數據能夠即時進入系統,無論在什么模式下,數據寫入即可見,并且立即能夠無延遲的服務 AP 查詢。

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

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

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

2. Data Warebase 與流批一體的區別

流批一體的終極解法,不是 Flink,而是數據庫的實時增量物化視圖。

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

3. Data Warebase 與湖倉一體的區別

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

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

結 語

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

作者簡介:

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