Data Warebase 成功押注 PostgreSQL 生態(tài)，或成 AI 時(shí)代數據底座

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

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

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

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

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

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

但從趨勢來(lái)看,未來(lái)具備能力訓練大模型的企業(yè)將是極少數。AI 工程之后的重點(diǎn),將逐步從基礎模型的訓練轉向應用層的落地與價(jià)值釋放。而 AI 應用層的兩個(gè)關(guān)鍵支點(diǎn)正是:

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

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

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

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

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

Neon

首先我們先來(lái)看 Neon 是什么。

Neon 是一個(gè)基于開(kāi)源 PostgreSQL 構建的云原生數據庫,它做了幾件非常關(guān)鍵、適合于 AI 應用開(kāi)發(fā)者的事情:

第一,它將傳統的單機數據庫架構轉變?yōu)榇嫠惴蛛x的云架構。

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

第二,在產(chǎn)品設計上,Neon 有兩個(gè)非常突出的亮點(diǎn):

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

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

·Branching(數據庫分支管理)

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

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

一個(gè)有趣的觀(guān)察:AI Agent 正在大量創(chuàng )建數據庫

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

從 2024 年 10 月到 2025 年 5 月,短短 7 個(gè)月時(shí)間,數據庫創(chuàng )建量出現了爆發(fā)式增長(cháng)。

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

Supabase

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

為什么這些公司在最近備受關(guān)注?

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

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

無(wú)論是 Neon、Supabase,還是其他新興的數據基礎設施項目,本質(zhì)上都在圍繞這個(gè)趨勢進(jìn)行布局。

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

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

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

為什么 PostgreSQL 會(huì )成為事實(shí)上的行業(yè)標準?

原因很簡(jiǎn)單:

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

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

以向量檢索為例:

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

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

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

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

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

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

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

舉個(gè)例子:

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

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

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

·分析需求用 ClickHouse 支撐;

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

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

當前,大模型并不能完全替用戶(hù)整理好所有數據,配合大模型一起工作的 AI workflow 主要集中在四個(gè)關(guān)鍵環(huán)節:

·Ingestion(數據攝取)

·Transform(數據加工)

·Explore(探索分析)

·Retrieve(查詢(xún)檢索)

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

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

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

·Ingestion(數據攝取)

·Transform(數據加工)

·Explore(探索分析)

·Retrieve(查詢(xún)檢索)

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

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

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

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

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

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

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

·“車(chē)的圖片”會(huì )被 embedding 成向量數據;

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

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

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

實(shí)現 Multi-Modal Retrieval,意味著(zhù)系統必須同時(shí)處理:

·結構化數據;

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

·向量數據。

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

·結構化數據用關(guān)系數據庫或數倉;

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

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

這樣的問(wèn)題是當我們要執行一個(gè) Top 100 推薦任務(wù)時(shí),分布在多個(gè)系統中的結果很難直接進(jìn)行 Join 操作,因為性能很差。于是,我們只能?chē)L試從每個(gè)系統中提取大量結果(如 Top 100 萬(wàn)),再在應用層合并關(guān)聯(lián)處理。這個(gè)過(guò)程不僅開(kāi)銷(xiāo)極大,而且也從理論上無(wú)法保障拿到最后正確的 Top 100。這正是 Hybrid Database(混合型數據庫)登場(chǎng)的理由:

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

AI Workflow 的五個(gè)關(guān)鍵需求

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

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

2.Instant Retrieval(即時(shí)檢索)需要毫秒級的數據訪(fǎng)問(wèn)能力,以滿(mǎn)足實(shí)時(shí)響應和推薦需求。

3.High Concurrency(高并發(fā))特別是在面向 C 端或 Agent 場(chǎng)景中,系統需能支撐成千上萬(wàn)用戶(hù)同時(shí)訪(fǎng)問(wèn),具備高吞吐能力。

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

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

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

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

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

·數據庫:擅長(cháng)處理 Fresh Data(數據新鮮性) 和 Instant Retrieval(即時(shí)檢索),適用于實(shí)時(shí)寫(xiě)入和快速查詢(xún)場(chǎng)景。但其大多基于單機或簡(jiǎn)單主從架構,難以支撐大規模的高并發(fā)訪(fǎng)問(wèn)。

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

換句話(huà)說(shuō),沒(méi)有一個(gè)系統能夠同時(shí)兼顧 AI 應用的五大關(guān)鍵訴求。

Introducing Data Warebase :什么是 Data Warebase

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

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

·事務(wù)型數據庫:用于實(shí)時(shí)寫(xiě)入與查詢(xún)(如訂單、行為日志)

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

·向量搜索引擎:支撐語(yǔ)義檢索

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

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

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

·用 Elasticsearch 處理全文檢索;

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

·用 ClickHouse 或 Snowflake 執行分析任務(wù)。

這種架構雖然功能齊全,但存在三大問(wèn)題:

·系統運維復雜:需管理多個(gè)技術(shù)棧,版本依賴(lài)、部署、運維壓力大;

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

·性能和響應鏈路長(cháng):查詢(xún)需跨系統拼接,影響響應時(shí)間和穩定性。

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

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

Data Warebase 本質(zhì)上是一個(gè)多模數據庫

正如之前討論的,幾乎所有的數據問(wèn)題理應由一個(gè)統一的數據系統解決,而這個(gè)系統必須對 AI 友好。AI Agent 需要一個(gè)多模數據庫來(lái)處理多種數據類(lèi)型和任務(wù),這一點(diǎn)我們之前已經(jīng)講過(guò)。

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

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

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

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

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

·行存:適用于鍵值查詢(xún)(KV)場(chǎng)景,支持快速單行訪(fǎng)問(wèn)。

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

·行列混存:在不確定負載特性時(shí),自動(dòng)兼顧行存與列存的優(yōu)勢。

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

Data Warebase 實(shí)現了多種索引機制,包括:

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

·倒排索引:滿(mǎn)足文本搜索需求。

·列存索引:優(yōu)化分析查詢(xún)。

·JSON 索引:支持半結構化數據的高效訪(fǎng)問(wèn)。

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

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

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

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

·熱存儲層:保證實(shí)時(shí)和近實(shí)時(shí)數據訪(fǎng)問(wèn)的低延遲。

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

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

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

4.其他關(guān)鍵能力

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

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

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

總結一下,Data Warebase 的誕生之初就預見(jiàn)到未來(lái)的所有應用系統將 build 在兩個(gè) API 之上:一個(gè)是 Data API,另一個(gè)是 AI API。 我們專(zhuān)注于做好 Data API,而它恰好在 AI 領(lǐng)域也能滿(mǎn)足 AI Workflow 的所有需求。我們下面來(lái)看看它是如何滿(mǎn)足這些需求的。

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

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

1.Ingestion

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

2.Transform

在 Transform 環(huán)節,我認為最重要的功能有三個(gè):

·實(shí)時(shí)增量物化視圖

·Schema Evolving

·Generated Columns 和 Built-in Functions。

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

3. Explore

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

4.Retrieve

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

Use Cases of Data Warebase:典型落地場(chǎng)景

接下來(lái)分享幾個(gè) Data Warebase 落地案例。簡(jiǎn)單來(lái)說(shuō),可分為六大類(lèi)。但從抽象層面來(lái)講,其實(shí)只有兩大類(lèi)型。

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

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

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

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

所以,其實(shí)可觀(guān)測性場(chǎng)景即需要 Simplicity 又需要 Instant Decision 的能力。

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

案例一:AI Agent

未來(lái)的 AI Agent,不需要對接多個(gè) MCP,而是連接一個(gè)多模數據庫。用一個(gè)數據庫,一個(gè) MCP 接口,極大降低 LLM 大模型的智力和推理的門(mén)檻。

首先是 AI Agent。未來(lái),所有的服務(wù)都將提供 AI Agent 的服務(wù)。以我們的產(chǎn)品為例,會(huì )出現至少兩個(gè)大的 MCP 出口。

第一個(gè) MCP 是數據庫本身。 我們用標準的 PG MCP 就可以把數據庫服務(wù)暴露給大模型調用?？蛻?hù)既可以使用 SQL 來(lái)查詢(xún),也可以通過(guò)大模型來(lái)訪(fǎng)問(wèn)我們的產(chǎn)品,使用 Data Warebase 會(huì )變得更加簡(jiǎn)單。

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

平臺服務(wù)以前主要是通過(guò) SDK 來(lái)實(shí)現的,但現在都轉向了 MCP。未來(lái)應用層的業(yè)務(wù)邏輯會(huì )越來(lái)越薄,業(yè)務(wù)應用慢慢的都會(huì )變成只由前端界面、AI 和數據這 3 層架構來(lái)支持。

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

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

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

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

案例三:車(chē)聯(lián)網(wǎng)案例

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

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

案例四:廣告和推薦案例

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

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

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

Data Warebase 與現有技術(shù)的差異與優(yōu)勢

最后再簡(jiǎn)單提一下很多小伙伴過(guò)來(lái)詢(xún)問(wèn) Data Warebase 與現有技術(shù)的差異與優(yōu)勢。

1. Data Warebase 與 HTAP 的區別

首先從客戶(hù)的角度來(lái)看,不應該常常要關(guān)心去區分 TP 和 AP,因為 SQL 本身是能寫(xiě)出來(lái) TP 和 AP 的 Query 來(lái)的。只是在數據量大的時(shí)候,一個(gè)系統要么是 TP 性能好一點(diǎn),要么是 AP 的性能會(huì )好一點(diǎn)。所以 HTAP 要求的是一個(gè)系統能夠在 TP 場(chǎng)景和 AP 場(chǎng)景下性能都非常好。

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

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

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

·低延遲:數據能夠即時(shí)進(jìn)入系統,無(wú)論在什么模式下,數據寫(xiě)入即可見(jiàn),并且立即能夠無(wú)延遲的服務(wù) AP 查詢(xún)。

·高吞吐:能夠支持高吞吐的查詢(xún)。

·復雜查詢(xún):支持完整的復雜的 OLAP 分析查詢(xún)。

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

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

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

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

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

關(guān)于湖倉一體,簡(jiǎn)單來(lái)說(shuō),就是讓倉和湖之間的數據能夠打通,流轉起來(lái),最終讓倉可以直接訪(fǎng)問(wèn)湖的數據,做一些查詢(xún)加速。其次要求數據倉庫能夠對接標準的湖存儲,做外表的查詢(xún),計算和寫(xiě)入。

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

結 語(yǔ)

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

作者簡(jiǎn)介:

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