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

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

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

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

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

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

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

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

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

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

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

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

Neon

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

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

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

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

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

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

Neon 官網(wǎng)強(qiáng)調(diào)其核心優(yōu)勢之一在于 Scale to Zero,也就是說,當(dāng)你不使用它時(shí),它能夠?qū)⒂?jì)算資源完全釋放,真正做到“用多少,付多少”,這對于資源敏感型應(yīng)用尤其重要。

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

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

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

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

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

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

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

Supabase

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

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

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

Inference(推理)和數(shù)據(jù)應(yīng)用正在成為新焦點(diǎn)。

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

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

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

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

為什么 PostgreSQL 會(huì)成為事實(shí)上的行業(yè)標(biāo)準(zhǔn)?

原因很簡單:

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

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

以向量檢索為例:

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

我曾看到一則非官方的報(bào)道:OpenAI 內(nèi)部的一個(gè) PostgreSQL 只讀從庫就部署了近 50 個(gè)實(shí)例。 雖然目前 OpenAI 尚未采用分布式數(shù)據(jù)庫架構(gòu),但隨著業(yè)務(wù)規(guī)模的持續(xù)擴(kuò)張,這或?qū)⒊蔀槠湮磥肀仨殤?yīng)對的架構(gòu)挑戰(zhàn)。

Agent Talk to MCP:PostgreSQL 是默認(rèn)選項(xiàng)之一

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

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

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

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

舉個(gè)例子:

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

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

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

·分析需求用 ClickHouse 支撐;

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

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

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

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

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

·Explore(探索分析)

·Retrieve(查詢檢索)

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

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

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

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

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

·Explore(探索分析)

·Retrieve(查詢檢索)

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

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

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

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

·“十字路口”是位置標(biāo)簽;

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

·“時(shí)間段”是結(jié)構(gòu)化數(shù)據(jù);

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

這類查詢就不再是單一模態(tài)的檢索,而是需要同時(shí)融合結(jié)構(gòu)化數(shù)據(jù) + 標(biāo)簽信息 + 向量檢索的 Multi-Modal Retrieval(多模態(tài)檢索)。

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

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

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

·結(jié)構(gòu)化數(shù)據(jù);

·半結(jié)構(gòu)化數(shù)據(jù)(如 JSON);

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

在傳統(tǒng)架構(gòu)中,不同類型的數(shù)據(jù)往往被存儲(chǔ)在不同的系統(tǒng)中:

·結(jié)構(gòu)化數(shù)據(jù)用關(guān)系數(shù)據(jù)庫或數(shù)倉;

·半結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和檢索用 NoSQL;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

換句話說,沒有一個(gè)系統(tǒng)能夠同時(shí)兼顧 AI 應(yīng)用的五大關(guān)鍵訴求。

Introducing Data Warebase :什么是 Data Warebase

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

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

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

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

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

·分析引擎:進(jìn)行數(shù)據(jù)分析(如行情分析、指標(biāo)監(jiān)控、報(bào)表)

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

·使用 MongoDB 或 HBase 做分布式存儲(chǔ);

·用 Elasticsearch 處理全文檢索;

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

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

這種架構(gòu)雖然功能齊全,但存在三大問題:

·系統(tǒng)運(yùn)維復(fù)雜:需管理多個(gè)技術(shù)棧,版本依賴、部署、運(yùn)維壓力大;

·數(shù)據(jù)割裂嚴(yán)重:數(shù)據(jù)需在多個(gè)系統(tǒng)間反復(fù)同步、復(fù)制,口徑難統(tǒng)一;

·性能和響應(yīng)鏈路長:查詢需跨系統(tǒng)拼接,影響響應(yīng)時(shí)間和穩(wěn)定性。

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

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

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

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

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

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

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

1.存儲(chǔ)架構(gòu):靈活多樣,兼顧 OLTP/ 搜索 /OLAP 的需求

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

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

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

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

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

Data Warebase 實(shí)現(xiàn)了多種索引機(jī)制,包括:

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

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

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

·JSON 索引:支持半結(jié)構(gòu)化數(shù)據(jù)的高效訪問。

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

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

Data Warebase 采用云原生架構(gòu)設(shè)計(jì),將存儲(chǔ)與計(jì)算資源解耦:

·計(jì)算層:靈活彈性,支持按需擴(kuò)展。

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

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

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

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

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

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

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

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

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

Data Warebase for AI Workload:如何支撐 AI 工作負(fù)載

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

1.Ingestion

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

2.Transform

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

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

·Schema Evolving

·Generated Columns 和 Built-in Functions。

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

3. Explore

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

4.Retrieve

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

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

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

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

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

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

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

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

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

案例一:AI Agent

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

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

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

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

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

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

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

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

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

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

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

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

案例四:廣告和推薦案例

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

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

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

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

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

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

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

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

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

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

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

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

·復(fù)雜查詢:支持完整的復(fù)雜的 OLAP 分析查詢。

如果沒有復(fù)雜查詢的需求,那么基本可以通過傳統(tǒng)的 TP 系統(tǒng)解決。只有像金融行情分析這樣的場景,需要數(shù)據(jù)實(shí)時(shí)寫入和高吞吐的復(fù)雜查詢,才是真正的 HTAP。Data Warebase 因?yàn)榫哂行辛谢齑娴哪芰σ约柏S富的索引,天然的支持 HTAP,用戶做了合理的存儲(chǔ)和索引的配置后,所有查詢 SQL 都能在物理極限上拿到最高的吞吐和最低的延遲。用戶再也不用為不同場景的數(shù)據(jù)庫選型而擔(dān)心。

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

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

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

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

關(guān)于湖倉一體,簡單來說,就是讓倉和湖之間的數(shù)據(jù)能夠打通,流轉(zhuǎn)起來,最終讓倉可以直接訪問湖的數(shù)據(jù),做一些查詢加速。其次要求數(shù)據(jù)倉庫能夠?qū)訕?biāo)準(zhǔn)的湖存儲(chǔ),做外表的查詢,計(jì)算和寫入。

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

結(jié) 語

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

作者簡介:

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