當(dāng)前位置： 首頁 >> 科技數(shù)碼 >> 查看詳情

為什么Data Warebase是AI時(shí)代首選Data API？

來源： 環(huán)球科技網(wǎng) 日期：2025-06-09 責(zé)編： 殷緒江

【環(huán)球科技網(wǎng)】本文內(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í)代，從搜索推薦，到視覺/語音/NLP 智能，再到當(dāng)前正全力投入的大模型AI浪潮，本文將結(jié)合其多年來對(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ì)
未來的所有應(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億美元收購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í)，市場(chǎng)上傳出有多家科技巨頭有意收購Supabase的消息，無疑為數(shù)據(jù)基礎(chǔ)設(shè)施領(lǐng)域注入了新的活力與關(guān)注度。
第三，ClickHouse也完成了最新一輪融資，估值已超60億美元。從其對(duì)外宣稱的目標(biāo)來看，ClickHouse似乎已經(jīng)準(zhǔn)備好向Snowflake發(fā)起挑戰(zhàn)。接下來，我將分享我對(duì)這三家公司近期為何備受資本青睞、頻頻獲得投資、收購關(guān)注的幾點(diǎn)觀察與思考。
趨勢(shì)一：大語言模型的出現(xiàn)正在顛覆傳統(tǒng)范式
在我離開達(dá)摩院之前，盡管其在語音識(shí)別和自然語言處理（NLP）等領(lǐng)域已采用了大語言模型（LLM）的技術(shù)路線，但當(dāng)時(shí)尚未嘗試使用LLM對(duì)全網(wǎng)數(shù)據(jù)進(jìn)行統(tǒng)一訓(xùn)練。直到OpenAI的成功落地，整個(gè)行業(yè)才真正意識(shí)到這種方式的可行性與革命性。隨之而來的是，幾乎所有技術(shù)公司都開始擁抱大語言模型，將海量數(shù)據(jù)匯聚在一起，借助大語言模型的能力為每個(gè)人回答日常問題，重構(gòu)人機(jī)交互體驗(yàn)。但從趨勢(shì)來看，未來具備能力訓(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ù)美國市場(chǎng)調(diào)研數(shù)據(jù)，已有約70%的企業(yè)已在實(shí)際生產(chǎn)業(yè)務(wù)中使用AI相關(guān)的能力，說明這場(chǎng)范式轉(zhuǎn)變已迅速從前沿技術(shù)走向主流實(shí)踐。
趨勢(shì)二：Agent數(shù)量快速增長，數(shù)據(jù)底座成核心支撐
在前文提到的三家公司中，前兩家均專注于構(gòu)建基于PostgreSQL數(shù)據(jù)庫的智能代理（Agent）服務(wù)，而第三家則聚焦于通過提供數(shù)據(jù)倉庫的能力為AI應(yīng)用提供數(shù)據(jù)分析的能力。這一趨勢(shì)顯示出，大模型Agent的生態(tài)正快速繁榮，背后對(duì)高效、高可用的數(shù)據(jù)基礎(chǔ)設(shè)施的需求也在同步升級(jí)。未來，Agent的數(shù)量會(huì)越來越多，誰能夠提供真正適配AI Agent的數(shù)據(jù)系統(tǒng)，將成為基礎(chǔ)設(shè)施競(jìng)爭的核心關(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)勢(shì)之一在于Scale to Zero，也就是說，當(dāng)你不使用它時(shí)，它能夠?qū)⒂?jì)算資源完全釋放，真正做到“用多少，付多少”，這對(duì)于資源敏感型應(yīng)用尤其重要。
·?Branching（數(shù)據(jù)庫分支管理）
另一個(gè)亮點(diǎn)是Branching概念。就像我們使用Gi 一樣，Neon支持?jǐn)?shù)據(jù)庫級(jí)別的“分支”操作。為什么需要這個(gè)？因?yàn)樵贏I Agent 開發(fā)過程中，越來越多的場(chǎng)景涉及大量試驗(yàn)、多人協(xié)作、并行工作——允許開發(fā)者快速創(chuàng)建、管理和切換數(shù)據(jù)庫的獨(dú)立副本（分支），極大提升了開發(fā)、測(cè)試和數(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è)顯著趨勢(shì)：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)成了直接的競(jìng)爭關(guān)系。但與Neon相比，Supabase提供了更為豐富的功能集，包括身份驗(yàn)證、對(duì)象存儲(chǔ)、實(shí)時(shí)訂閱、邊緣函數(shù)等服務(wù)，幾乎可以看作是“開源版的Firebase”，定位為開發(fā)者的一站式后端服務(wù)平臺(tái)。

為什么這些公司在最近備受關(guān)注？
這背后有一個(gè)非常清晰的趨勢(shì)判斷：大模型訓(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è)趨勢(shì)進(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)對(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ù)庫，更是AI系統(tǒng)與數(shù)據(jù)交互的中樞平臺(tái)。
ClickHouse的定位演變與多模數(shù)據(jù)庫的崛起
相比Neon和Supabase，ClickHouse的定位其實(shí)有所不同。它本質(zhì)上是一款數(shù)據(jù)倉庫。此前，在它的多輪對(duì)外宣傳中，一直強(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è)趨勢(shì)：未來AI應(yīng)用層將越來越依賴數(shù)據(jù)庫，尤其是多模態(tài)數(shù)據(jù)庫將成為核心基礎(chǔ)設(shè)施。

舉個(gè)例子：
·如果你正在開發(fā)一個(gè)基于AI的Agent，它勢(shì)必需要與各種數(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ù)。這對(duì)大模型來說是個(gè)巨大的挑戰(zhàn)。理論上它可以理解這些差異化的服務(wù)，但實(shí)際運(yùn)作中非常復(fù)雜，對(duì)其“智力”構(gòu)成高強(qiáng)度負(fù)荷。能對(duì)接一個(gè)MCP，誰還要對(duì)接4個(gè)呢？這也正是為什么越來越多的AI初創(chuàng)公司選擇PostgreSQL，而未來大型企業(yè)在面向AI場(chǎng)景進(jìn)行數(shù)據(jù)庫選型時(shí)，也一定會(huì)傾向選擇支持多模態(tài)的數(shù)據(jù)庫平臺(tái)。
雖然我們剛才提到訓(xùn)練的時(shí)代接近尾聲，但訓(xùn)練本身的問題依然存在，尤其是在存儲(chǔ)層面。我們?cè)幸痪湫袠I(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ù)攝?。?br /> ·Transform（數(shù)據(jù)加工）
·Explore（探索分析）
·Retrieve（查詢檢索）
訓(xùn)練的瓶頸仍然存在，但重點(diǎn)正在轉(zhuǎn)向AI應(yīng)用流程（AI Workflow）
雖然我們剛才提到訓(xùn)練的時(shí)代接近尾聲，但訓(xùn)練本身的問題依然存在，尤其是在存儲(chǔ)層面。我們?cè)幸痪湫袠I(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ù)庫。它能做的，主要集中在我們前面提到的四個(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 Retri：下一代智能檢索范式
什么是Multi-Modal Retri？它的核心含義是：在數(shù)據(jù)檢索過程中，不再局限于某一種查詢方式，而是融合結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化以及向量檢索等多種方式，實(shí)現(xiàn)更智能、更全面的查詢體驗(yàn)。這項(xiàng)能力對(duì)于AI應(yīng)用尤其重要。因?yàn)锳gent面對(duì)的問題往往不是“查一條信息或者一個(gè)向量”，而是需要對(duì)多個(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è)車的圖片相似”的場(chǎng)景就會(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 Retri（多模態(tài)檢索）。再比如在社交推薦場(chǎng)景中，人與人之間的推薦可能通過 Embedding 大部分特征成為向量，再靠向量相似度檢索來實(shí)現(xiàn)。但如果用戶添加了“同一個(gè)城市”或“同一活動(dòng)”的過濾條件，就引入了地理位置或事件標(biāo)簽，從而升級(jí)為真正的多模態(tài)檢索任務(wù)。
多模態(tài)檢索對(duì)架構(gòu)提出了更高要求
實(shí)現(xiàn)Multi-Modal Retri，意味著系統(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ù)庫）登場(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 Retri（即時(shí)檢索）需要毫秒級(jí)的數(shù)據(jù)訪問能力，以滿足實(shí)時(shí)響應(yīng)和推薦需求。
3.High Concurrency（高并發(fā)）特別是在面向C端或Agent場(chǎng)景中，系統(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 Retri（即時(shí)檢索），適用于實(shí)時(shí)寫入和快速查詢場(chǎng)景。但其大多基于單機(jī)或簡單主從架構(gòu)，難以支撐大規(guī)模的高并發(fā)訪問。
·數(shù)據(jù)倉庫（如 ClickHouse）：在分析性能（Fast Analytics）和使用簡潔性（Simplicity）方面表現(xiàn)出色，但它們普遍不適合高頻寫入或低延遲響應(yīng)場(chǎ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)、全場(chǎng)景覆蓋”。
Data Warebase本質(zhì)上是一個(gè)多模數(shù)據(jù)庫
正如之前討論的，幾乎所有的數(shù)據(jù)問題理應(yīng)由一個(gè)統(tǒng)一的數(shù)據(jù)系統(tǒng)解決，而這個(gè)系統(tǒng)必須對(duì)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的核心競(jìng)爭力在于支持行列混存且具有分布式橫向水平擴(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）場(chǎng)景，支持快速單行訪問。
·列存：適合分析和倒排索引，支持高效壓縮和列級(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ù)的高效訪問。
有了這些索引，結(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ù)存算分離直接使用云上高可用的對(duì)象存儲(chǔ)，Data Warebase在塊存儲(chǔ)云盤上自主設(shè)計(jì)了高性能分布式文件系統(tǒng)，實(shí)現(xiàn)了在線數(shù)據(jù)庫級(jí)別的存算分離，這個(gè)挑戰(zhàn)要比大數(shù)據(jù)系統(tǒng)的存算分離難一個(gè)數(shù)量級(jí)。

同時(shí)，存算分離架構(gòu)帶來的秒級(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í)別的增量更新，極大簡化實(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ù)庫級(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ù)型的，而是需要混合型的查詢能力。此外，對(duì)于AI工程師來說，Sampling功能也非常重要，因?yàn)樗麄冃枰ㄟ^采樣來觀察數(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ù)庫，支持Transaction和MVCC，因此有很好的built-in的Time Travel的能力，可以給算法同學(xué)提供低成本的Feature按時(shí)序觀測(cè)的能力。

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

Use Cases of Data Warebase：典型落地場(chǎng)景
接下來分享幾個(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的場(chǎng)景。
·實(shí)時(shí)決策（Instant Decision）：例如超實(shí)時(shí)高吞吐的金融行情分析和風(fēng)控，高彈性高吞吐的運(yùn)維可觀測(cè)性場(chǎng)景，車聯(lián)網(wǎng)車機(jī)信號(hào)實(shí)時(shí)監(jiān)控與故障診斷需求，以及實(shí)時(shí)搜索廣告推薦系統(tǒng)。

關(guān)于AI Agent，之前已經(jīng)解釋過不再贅述。Instant Decision下的一個(gè)大類是可觀測(cè)性?？捎^測(cè)性從廣義上來說，萬物似乎都具備可觀測(cè)性，但這個(gè)范疇太寬泛了。而狹義的可觀測(cè)性，主要是指對(duì)日志、標(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操作性能并不理想。更重要的是，在可觀測(cè)性場(chǎng)景下，彈性能力至關(guān)重要。因?yàn)樵谙到y(tǒng)正常運(yùn)行、沒有報(bào)警或行情平穩(wěn)時(shí)，可能只有小幾個(gè)人在觀測(cè)；而一旦系統(tǒng)出現(xiàn)問題或者來了一波新的金融行情，會(huì)有更多的人涌入查看，系統(tǒng)很容易崩潰。因此，云上的彈性能力非常重要。Data Warebase因?yàn)槭褂昧俗铑I(lǐng)先的存算分離架構(gòu)，可以做到業(yè)務(wù)無感情況下的秒級(jí)彈性擴(kuò)縮容。所以，其實(shí)可觀測(cè)性場(chǎng)景即需要Simplicity又需要Instant Decision的能力。而在金融領(lǐng)域，像Trading、Fraud Detection，以及車聯(lián)網(wǎng)領(lǐng)域中的信號(hào)收集、檢測(cè)和報(bào)警，以及Ads、Search和Recommendation這幾類場(chǎng)景中，它們都屬于需要Instant Decision的場(chǎng)景。接下來介紹幾個(gè)具體案例。
案例一：AI Agent
未來的AI Agent，不需要對(duì)接多個(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ù)也可以對(duì)外暴露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è)場(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的，要求“寫入即可見”，并且查詢量非常大。另外，它的查詢也比一般的點(diǎn)查復(fù)雜的多。它不僅僅是簡單地查看一行行數(shù)據(jù)，而是需要通過大量的標(biāo)簽進(jìn)行過濾做多維分析，以便能夠只觀測(cè)某些特別關(guān)注的標(biāo)簽并據(jù)此做出決策。這也是為什么我之前提到可觀測(cè)性的范疇非常大，從理論上講，這也是可觀測(cè)性的一個(gè)應(yīng)用場(chǎ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ī)信號(hào)傳輸頻率非常高，每輛車每秒都會(huì)上傳車機(jī)信號(hào)，100萬輛車就意味著每秒有100萬條數(shù)據(jù)涌入。以往，這些數(shù)據(jù)進(jìn)來后，我們只是將其存儲(chǔ)起來，以滿足監(jiān)管要求。但如今，隨著電動(dòng)車越來越受歡迎，情況發(fā)生了變化。大家都知道，電動(dòng)車的系統(tǒng)升級(jí)是通過OTA來實(shí)現(xiàn)的，而不是像傳統(tǒng)汽車那樣需要開到車廠，插上線進(jìn)行升級(jí)。這些電動(dòng)車會(huì)不斷地推送軟件更新，而這些軟件更新可能會(huì)對(duì)車機(jī)產(chǎn)生影響。所以，現(xiàn)在數(shù)據(jù)進(jìn)來之后，我們還需要對(duì)某些關(guān)鍵列進(jìn)行分析。即使在不升級(jí)的時(shí)候，也需要對(duì)核心車輛信號(hào)做實(shí)時(shí)監(jiān)控報(bào)警，確保車輛和車主的安全。以前的分析型數(shù)據(jù)庫可以統(tǒng)計(jì)一些聚合值，但不擅長明細(xì)查詢，因?yàn)槊骷?xì)查詢的時(shí)候可能需要對(duì)非主鍵字段做過濾，需要真正的全局二級(jí)索引，而這種索引一般也只有OLTP數(shù)據(jù)才具有。所以，這種場(chǎng)景非常適合使用多模數(shù)據(jù)庫。
案例四：廣告和推薦案例

第四個(gè)案例是廣告和推薦。廣告的量比推薦大，因?yàn)榇蟛糠謴V告公司收集了眾多APP的流量，且每次做決策時(shí)的查詢邏輯也比較復(fù)雜。當(dāng)我們?cè)谑褂酶鞣N手機(jī)應(yīng)用時(shí)，每次跳轉(zhuǎn)到下一個(gè)界面，其實(shí)都是一個(gè)決策過程。這些決策過程中查詢的數(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萬元的手機(jī)，因?yàn)橄到y(tǒng)已經(jīng)根據(jù)你的搜索范圍做出了精準(zhǔn)的判斷。對(duì)于新用戶，系統(tǒng)可能一開始對(duì)你不了解，但一旦你購買了某一類藥品，系統(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)勢(shì)
最后再簡單提一下很多小伙伴過來詢問Data Warebase與現(xiàn)有技術(shù)的差異與優(yōu)勢(shì)。
1.Data Warebase與HTAP的區(qū)別
首先從客戶的角度來看，不應(yīng)該常常要關(guān)心去區(qū)分TP和AP，因?yàn)镾QL本身是能寫出來TP和AP的Query來的。只是在數(shù)據(jù)量大的時(shí)候，一個(gè)系統(tǒng)要么是TP性能好一點(diǎn)，要么是AP的性能會(huì)好一點(diǎn)。所以HTAP要求的是一個(gè)系統(tǒng)能夠在TP場(chǎng)景和AP場(chǎng)景下性能都非常好。真正的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)解決。只有像金融行情分析這樣的場(chǎng)景，需要數(shù)據(jù)實(shí)時(shí)寫入和高吞吐的復(fù)雜查詢，才是真正的HTAP。Data Warebase因?yàn)榫哂行辛谢齑娴哪芰σ约柏S富的索引，天然的支持HTAP，用戶做了合理的存儲(chǔ)和索引的配置后，所有查詢SQL都能在物理極限上拿到最高的吞吐和最低的延遲。用戶再也不用為不同場(chǎng)景的數(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ì)。如果放大到大數(shù)據(jù)的趨勢(shì)，只有一件事值得關(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）

作者簡介：

王紹翾，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場(chǎng)景的模型訓(xùn)練，推理，以及向量檢索技術(shù)。2021年開始創(chuàng)業(yè)，創(chuàng)立“小質(zhì)科技”，推出了自研產(chǎn)品ProtonBase，一款融合數(shù)據(jù)庫與數(shù)據(jù)倉庫能力于一體的新一代Data Warebase（Data Warehouse+Database）。

標(biāo)簽：科技黑科技瀏覽器軟件

上一新聞：新品ROG RO姬水冷散熱器燃爆登場(chǎng)，開啟二次元電競(jìng)奇妙之旅

下一新聞：三款三星Galaxy平板生命周期結(jié)束，將停止獲得安全更新

【免責(zé)聲明】：

凡注明 “環(huán)球科技網(wǎng)” 字樣的圖片或文字內(nèi)容均屬于本網(wǎng)站專稿，如需轉(zhuǎn)載圖片請(qǐng)保留 “環(huán)球科技網(wǎng)” 水印，轉(zhuǎn)載文字內(nèi)容請(qǐng)注明來源“環(huán)球科技網(wǎng)”；凡本網(wǎng)注明“來源：XXX(非環(huán)球科技網(wǎng))”的作品，均轉(zhuǎn)載自其它媒體，轉(zhuǎn)載目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)和對(duì)其作品內(nèi)容的實(shí)質(zhì)真實(shí)性負(fù)責(zé)，轉(zhuǎn)載信息版權(quán)屬于原媒體及作者。如轉(zhuǎn)載內(nèi)容涉及版權(quán)或者其他問題，請(qǐng)投訴至郵箱；1978751725@qq.com

本網(wǎng)公告
環(huán)球科技網(wǎng)從不發(fā)布負(fù)面新聞資訊，也絕不會(huì)發(fā)布負(fù)面信息。如發(fā)現(xiàn)負(fù)面信息鏈接請(qǐng)甄別是否為環(huán)球科技網(wǎng)所發(fā)。
本網(wǎng)系北京伯樂傳媒廣告有限公司主辦、所有。本網(wǎng)唯一域名（www.lzsczx.com），其它域名鏈接均為假冒。望廣大網(wǎng)民及企業(yè)主認(rèn)真甄別。

咨詢、采訪、合作、投稿等請(qǐng)致電：13911566744（含微信）