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

　　作者 | 王紹翾 @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 的時(shí)代，從搜索推薦，到視覺(jué) / 語(yǔ)音 / NLP 智能，再到當(dāng)前正全力投入的大模型 AI 浪潮，本文將結(jié)合其多年來(lái)對(duì)數(shù)據(jù)基礎(chǔ)設(shè)施的實(shí)踐與反思，深入探討生成式 AI 時(shí)代對(duì)數(shù)據(jù)系統(tǒng)提出的全新挑戰(zhàn)與潛在機(jī)遇。

　　文章結(jié)構(gòu)：

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

　　·Introducing Data Warebase：什么是 Data Warebase

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

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

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

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

　　未來(lái)的所有應(yīng)用，將主要對(duì)接兩個(gè)接口：一個(gè) Data API，一個(gè) AI API。

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

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

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

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

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

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

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

　　但從趨勢(shì)來(lái)看，未來(lái)具備能力訓(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ù)庫(kù)系統(tǒng)）：如何支撐上下文管理、向量檢索、數(shù)據(jù)調(diào)用與語(yǔ)義理解等數(shù)據(jù)層能力。

　　根據(jù)美國(guó)市場(chǎng)調(diào)研數(shù)據(jù)，已有約 70% 的企業(yè)已在實(shí)際生產(chǎn)業(yè)務(wù)中使用 AI 相關(guān)的能力，說(shuō)明這場(chǎng)范式轉(zhuǎn)變已迅速?gòu)那把丶夹g(shù)走向主流實(shí)踐。

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

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

　　Neon

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

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

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

　　這一點(diǎn)使得數(shù)據(jù)庫(kù)具備了更強(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)勢(shì)之一在于 Scale to Zero，也就是說(shuō)，當(dāng)你不使用它時(shí)，它能夠?qū)⒂?jì)算資源完全釋放，真正做到“用多少，付多少”，這對(duì)于資源敏感型應(yīng)用尤其重要。

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

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

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

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

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

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

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

　　Supabase

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

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

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

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

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

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

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

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

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

　　原因很簡(jiǎn)單：

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

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

　　以向量檢索為例：

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

　　我曾看到一則非官方的報(bào)道：OpenAI 內(nèi)部的一個(gè) PostgreSQL 只讀從庫(kù)就部署了近 50 個(gè)實(shí)例。 雖然目前 OpenAI 尚未采用分布式數(shù)據(jù)庫(kù)架構(gòu)，但隨著業(yè)務(wù)規(guī)模的持續(xù)擴(kuò)張，這或?qū)⒊蔀槠湮磥?lái)必須應(yīng)對(duì)的架構(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ù)庫(kù)，更是 AI 系統(tǒng)與數(shù)據(jù)交互的中樞平臺(tái)。

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

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

　　舉個(gè)例子：

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

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

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

　　·分析需求用 ClickHouse 支撐;

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

　　雖然我們剛才提到訓(xùn)練的時(shí)代接近尾聲，但訓(xùn)練本身的問(wèn)題依然存在，尤其是在存儲(chǔ)層面。我們?cè)�有一句行業(yè)共識(shí)：“AI 的瓶頸在計(jì)算，計(jì)算的瓶頸在存儲(chǔ)。”這句話主要是針對(duì)模型訓(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)練本身的問(wèn)題依然存在，尤其是在存儲(chǔ)層面。我們?cè)�有一句行業(yè)共識(shí)：“AI 的瓶頸在計(jì)算，計(jì)算的瓶頸在存儲(chǔ)。”這句話主要是針對(duì)訓(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ù)庫(kù)。它能做的，主要集中在我們前面提到的四個(gè)關(guān)鍵環(huán)節(jié)：

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

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

　　·Explore（探索分析）

　　·Retrieve（查詢檢索）

　　AI workflow 從數(shù)據(jù)庫(kù)、應(yīng)用日志、埋點(diǎn)系統(tǒng)等來(lái)源收集數(shù)據(jù);隨后通過(guò)數(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ù)檢索過(guò)程中，不再局限于某一種查詢方式，而是融合結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化以及向量檢索等多種方式，實(shí)現(xiàn)更智能、更全面的查詢體驗(yàn)。這項(xiàng)能力對(duì)于 AI 應(yīng)用尤其重要。因?yàn)?Agent 面對(duì)的問(wèn)題往往不是“查一條信息或者一個(gè)向量”，而是需要對(duì)多個(gè)模態(tài)、多維數(shù)據(jù)進(jìn)行理解、關(guān)聯(lián)和調(diào)用——這就需要底層數(shù)據(jù)庫(kù)具備原生的多模處理能力。

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

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

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

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

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

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

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

　　多模態(tài)檢索對(duì)架構(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ù)庫(kù)或數(shù)倉(cāng);

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

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

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

　　將多種模態(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í)檢索）需要毫秒級(jí)的數(shù)據(jù)訪問(wèn)能力，以滿足實(shí)時(shí)響應(yīng)和推薦需求。

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

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

　　5.Simplicity（易用性）整個(gè)系統(tǒng)要具備良好的開(kāi)發(fā)者體驗(yàn)和管理簡(jiǎn)潔性，避免多工具鏈、多平臺(tái)切換帶來(lá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ù)庫(kù)和數(shù)據(jù)倉(cāng)庫(kù)難以滿足 AI Workflow 的全部需求？

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

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

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

　　換句話說(shuō)，沒(méi)有一個(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ù)采集、加工、分析到檢索的全過(guò)程。

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

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

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

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

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

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

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

　　·用 Elasticsearch 處理全文檢索;

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

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

　　這種架構(gòu)雖然功能齊全，但存在三大問(wèn)題：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　1.Ingestion

　　數(shù)據(jù)進(jìn)來(lái)時(shí)，首先需要能夠快速地導(dǎo)入。Data Warebase 能夠支持?jǐn)?shù)據(jù)庫(kù)級(jí)別的即時(shí)增刪改查操作，保障了數(shù)據(jù)“寫(xiě)入即可見(jiàn)”，同時(shí)它支持通過(guò) Foreign Table 直接從 Data Lake 中讀取數(shù)據(jù)。此外，作為一個(gè)數(shù)據(jù)庫(kù)，它還支持 CDC 輸出，而許多大數(shù)據(jù)系統(tǒng)并不支持這一點(diǎn)。這種能力確保了整個(gè) Workflow 可以無(wú)縫串聯(lián)起來(lái)，同時(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ù)庫(kù)系統(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ì)算列，而無(wú)需使用物化視圖，這使得 Transform 變得非常容易，成本更低。最后，Built-in Functions 可以輕松解決大量數(shù)據(jù)加工的 ETL 工作。

　　3. Explore

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

　　4.Retrieve

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

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

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

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

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

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

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

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

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

　　案例一：AI Agent

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

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

　　第一個(gè) MCP 是數(shù)據(jù)庫(kù)本身。 我們用標(biāo)準(zhǔn)的 PG MCP 就可以把數(shù)據(jù)庫(kù)服務(wù)暴露給大模型調(diào)用。客戶既可以使用 SQL 來(lái)查詢，也可以通過(guò)大模型來(lái)訪問(wèn)我們的產(chǎn)品，使用 Data Warebase 會(huì)變得更加簡(jiǎn)單。

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

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

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

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

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

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

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

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

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

　　案例四：廣告和推薦案例

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

　　例如，當(dāng)你在電商平臺(tái)上搜索 1000 元的手機(jī)時(shí)，系統(tǒng)會(huì)在下一秒為你推薦 1000 元左右的手機(jī)，而不是 1 萬(wàn)元的手機(jī)，因?yàn)橄到y(tǒng)已經(jīng)根據(jù)你的搜索范圍做出了精準(zhǔn)的判斷。對(duì)于新用戶，系統(tǒng)可能一開(kāi)始對(duì)你不了解，但一旦你購(gòu)買(mǎi)了某一類藥品，系統(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í)寫(xiě)入，且高頻分析查詢。

　　總結(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)勢(shì)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　結(jié) 語(yǔ)

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

　　作者簡(jiǎn)介：

　　王紹翾，ProtonBase 創(chuàng)始人兼 CEO。曾在 Facebook 負(fù)責(zé)在線基礎(chǔ)設(shè)施開(kāi)發(fā)，并深度參與了 Memcache，RocksDB 和自研分布式圖數(shù)據(jù)庫(kù) TAO 的開(kāi)發(fā)，該數(shù)據(jù)庫(kù)支撐了 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ì)，包括視覺(jué) / 語(yǔ)音 /NLP 等 AI 場(chǎng)景的模型訓(xùn)練，推理，以及向量檢索技術(shù)。2021 年開(kāi)始創(chuàng)業(yè)，創(chuàng)立“小質(zhì)科技”，推出了自研產(chǎn)品 ProtonBase，一款融合數(shù)據(jù)庫(kù)與數(shù)據(jù)倉(cāng)庫(kù)能力于一體的新一代 Data Warebase(Data Warehouse + Database)。