過去，Data API 的實(shí)現(xiàn)極為復(fù)雜，用戶若想搭建一個(gè)應(yīng)用的底層，往往需要使用非常多數(shù)據(jù)系統(tǒng)。例如，數(shù)據(jù)庫橫向擴(kuò)展可能采用 MongoDB 或 HBase，文本檢索使用 Elasticsearch，還可能需要向量檢索，分析型數(shù)據(jù)庫等。如此一來，用戶最終必然會(huì)面對(duì) A、B、C、D、E 等諸多數(shù)據(jù)產(chǎn)品，硬件開銷以及運(yùn)維和開發(fā)成本急劇上升。

ProtonBase 產(chǎn)品研發(fā)之初是想讓業(yè)務(wù)的架構(gòu)回歸簡單(Simple)，解決架構(gòu)不得不從 A 到 B，從 B 到 C，從 C 到 D 不斷膨脹的問題。隨著產(chǎn)品面世之后，在與市場(chǎng)不斷磨合的過程中，我們發(fā)現(xiàn) ProtonBase 最強(qiáng)的 PMF(產(chǎn)品與市場(chǎng)的匹配度)在于滿足那些對(duì)實(shí)時(shí)決策(Instant Decision)有需求的業(yè)務(wù)，例如金融量化交易和風(fēng)控、車聯(lián)網(wǎng)、以及數(shù)據(jù)可觀測(cè)性等場(chǎng)景，這些場(chǎng)景的數(shù)據(jù)既需要具備極高的端到端的實(shí)時(shí)性，同時(shí)也要支持在這些實(shí)時(shí)數(shù)據(jù)之上的高并發(fā)復(fù)雜查詢—— 而這正是 ProtonBase 的優(yōu)勢(shì)所在。

Q3：在 ProtonBase 的研發(fā)過程中遇到的最?技術(shù)挑戰(zhàn)是什么?團(tuán)隊(duì)是如何突破這些難題，確保產(chǎn)品順利推進(jìn)的?

王紹翾：挑戰(zhàn)非常多，因?yàn)橐?ProtonBase 打造成一個(gè)強(qiáng)大、統(tǒng)一的 Data API 平臺(tái)，必須具備五大核心能力：OLTP、文檔數(shù)據(jù)庫、文本檢索、向量檢索，以及 OLAP。

許多客戶會(huì)問我們：“你們是如何將這些本質(zhì)上差異巨大的能力整合到一個(gè)系統(tǒng)中的?”其實(shí)，我們整個(gè)團(tuán)隊(duì)經(jīng)歷了數(shù)據(jù)庫，大數(shù)據(jù)，再到數(shù)據(jù)庫的時(shí)代，積累了大量的工程經(jīng)驗(yàn)。我們今天的產(chǎn)品其實(shí)就是集成了數(shù)據(jù)庫和大數(shù)據(jù)的最重要的三個(gè)能力，第一是存儲(chǔ)，第二是索引，第三是在高速存儲(chǔ)上做到數(shù)據(jù)庫級(jí)別的存算分離。

·存儲(chǔ)層：ProtonBase 支持?jǐn)?shù)據(jù)的行存、列存以及行列混存;

·索引層：ProtonBase 實(shí)現(xiàn)了數(shù)據(jù)庫最重要的全局二級(jí)索引(Global Secondary Index)，以及搜索所需要的倒排索引、向量索引、分析所需要的列存索引等等;

·存算分離：實(shí)現(xiàn)數(shù)據(jù)庫級(jí)別的存算分離的挑戰(zhàn)非常大。大數(shù)據(jù)的存算分離是基于公有云上高可用的對(duì)象存儲(chǔ)，而數(shù)據(jù)庫系統(tǒng)不能選用對(duì)象存儲(chǔ)，因?yàn)樗枰叩耐掏潞透偷难舆t。要做好一個(gè)實(shí)時(shí)或者近實(shí)時(shí)的數(shù)據(jù)庫級(jí)別的存算分離，難度和挑戰(zhàn)很大，但我們實(shí)現(xiàn)了。

Q4：企業(yè)在選擇一款數(shù)據(jù)庫產(chǎn)品時(shí)要考慮的因素很多，ProtonBase 最優(yōu)勢(shì)的場(chǎng)景是什么，在哪些技術(shù)場(chǎng)景下，企業(yè)適合考慮使? ProtonBase?

王紹翾：ProtonBase 在數(shù)據(jù) Data API 上，幾乎實(shí)現(xiàn)了中間層的所有功能，但我們并不希望客戶將 ProtonBase 僅用于單一模式，更希望把它視為多模數(shù)據(jù)庫，發(fā)揮出 1+1>2 的化學(xué)效果。目前我們至少在三個(gè)方向上看到了這種因?yàn)槎嗄５哪芰淼?1+1>2 的場(chǎng)景。

一是真正的 HTAP 場(chǎng)景。如果一個(gè)數(shù)據(jù)系統(tǒng)僅將 Transaction Data 存放在 OLTP 數(shù)據(jù)庫，再將數(shù)據(jù)同步到 OLAP 數(shù)據(jù)庫去做報(bào)表業(yè)務(wù)，那并非真正的 HTAP。真正的 HTAP 首先要實(shí)現(xiàn)寫入即可見(OLTP 和 OLAP 的查詢)，其次要支持較為復(fù)雜的偏分析類查詢，且查詢吞吐較高，我們將這種場(chǎng)景稱為真正的 HTAP，例如金融量化交易。

二是可觀測(cè)性和實(shí)時(shí)數(shù)倉場(chǎng)景。我們發(fā)現(xiàn)一個(gè)有意思的事情，數(shù)倉并不等同于 OLAP，越來越多的場(chǎng)景在數(shù)倉上提出了對(duì)數(shù)據(jù)庫能力的需求。例如，用戶在做 OLAP 分析后發(fā)現(xiàn)了一些規(guī)律，就想去查看明細(xì)數(shù)據(jù)，按某些主鍵 PK 進(jìn)行全部數(shù)據(jù)召回，甚至有時(shí)不僅需要對(duì) PK 進(jìn)行過濾召回，還需對(duì)非 PK 的主鍵進(jìn)行過濾召回。此時(shí)，就需要 OLTP 數(shù)據(jù)庫的全局二級(jí)索引的能力——而這是所有 OLAP 引擎所不具備的。

第三是 AI Agent 場(chǎng)景。因?yàn)?AI Agent 背后需要對(duì)接 MCP(Model Context Protocol )，假設(shè)一家公司有多個(gè)服務(wù)和數(shù)據(jù)系統(tǒng)，當(dāng)把數(shù)據(jù)存在 3～5 個(gè)數(shù)據(jù)系統(tǒng)之上，就會(huì)有 3～5 個(gè) MCP，大模型想去對(duì)接 MCP 做一些決策的時(shí)候就非常復(fù)雜。用一個(gè)數(shù)據(jù)庫，一個(gè) MCP 服務(wù)，可以大幅降低 LLM 的負(fù)擔(dān)和推理復(fù)雜度。所以 Agent 天然期望用一個(gè)多模數(shù)據(jù)庫來?持業(yè)務(wù)。

所以，真正的 HTAP、可觀測(cè)性+實(shí)時(shí)數(shù)倉、以及 AI Agent 這三個(gè)大場(chǎng)景，非常適合使用 ProtonBase 這種多模數(shù)據(jù)庫。在這些場(chǎng)景下，企業(yè)可以借助 ProtonBase 多模融合、實(shí)時(shí)響應(yīng)、高并發(fā)查詢的能力，獲得遠(yuǎn)超傳統(tǒng)架構(gòu)所帶來的業(yè)務(wù)回報(bào)。

Q5：從 2021 年成立至今，小質(zhì)科技的客戶已經(jīng)涵蓋金融、電商、?聯(lián)網(wǎng)與物聯(lián)網(wǎng)、制造、游戲、廣告、快消、教育等行業(yè)。能否簡單介紹下這些行業(yè)是怎么使用 ProtonBase 的，并從中挑選一兩個(gè)最具代表性的客戶案例，詳細(xì)分享一下合作過程、解決的問題以及最終取得的成效?

王紹翾：經(jīng)過 4 年發(fā)展，公司已服務(wù)幾十個(gè)客戶，我們始終聚焦于最能發(fā)揮 ProtonBase 產(chǎn)品特性的場(chǎng)景去打磨與落地。我們有兩個(gè)核心 PMF：

第一類 PMF：秒級(jí) Freshness + 高吞吐 Instant Decision(也就是我上面提到的真正的 HTAP)。具體應(yīng)用包括：

·金融場(chǎng)景：金融行情的量化分析和交易、金融的反作弊;

·廣告/推薦系統(tǒng)：廣告/推薦決策算法復(fù)雜且吞吐高，全鏈路越實(shí)時(shí)越有效;

·車聯(lián)網(wǎng)與 IOT：車機(jī)數(shù)據(jù)每秒更新，需即時(shí)進(jìn)行規(guī)則匹配和安全分析。

第二類 PMF：Simplicity，有些應(yīng)用期望數(shù)據(jù)庫天然具備 Hybrid 的能力。例如 AI Agent 場(chǎng)景中，系統(tǒng)希望直接對(duì)接一個(gè)統(tǒng)一的數(shù)據(jù)接口 MCP，所以 All-in-One 的多模數(shù)據(jù)庫是非常適合于 AI Agent 的，另外在可觀測(cè)性的場(chǎng)景下也越來越需要數(shù)據(jù)庫要具有 Hybrid 的能力。

下面我們挑選兩個(gè)最具代表性的落地案例，分別來自金融和車聯(lián)網(wǎng)行業(yè)，幫助大家具體理解 ProtonBase 的實(shí)際價(jià)值：

【案例一】金融客戶：支撐秒級(jí)實(shí)時(shí)決策的 AI 交易系統(tǒng)

這家客戶來自金融證券行業(yè)，需求非常典型：整個(gè)交易行情數(shù)據(jù)需要非常實(shí)時(shí)的寫入數(shù)據(jù)庫系統(tǒng)，寫入即可見，然后有大量的交易者或者分析師甚至 AI，對(duì)這些實(shí)時(shí)的數(shù)據(jù)做復(fù)雜的分析，然后做交易決策，所有過程都需要在幾秒內(nèi)甚至亞秒級(jí)完成(AI Trading)。同時(shí)，這個(gè)客戶內(nèi)部有很多數(shù)據(jù)需要做可觀測(cè)透出，他們最早使用的是 TSDB 這一類時(shí)序數(shù)據(jù)庫，但是 TSDB 不支持 update ，客戶轉(zhuǎn)而使用 Elasticsearch / ClickHouse 這些 OLAP 系統(tǒng)，但是這些系統(tǒng)不能很好地支持復(fù)雜查詢，在冷熱分離和彈性方面也有諸多詬病。最終這家金融客戶選用了 ProtonBase。

【案例二】車聯(lián)網(wǎng)客戶：支撐數(shù)百萬輛車并發(fā)的實(shí)時(shí)異常檢測(cè)系統(tǒng)

該客戶是頭部車企，該車企每輛車每秒上傳更新很多車機(jī)信號(hào)，需要系統(tǒng)快速應(yīng)用各種規(guī)則分析數(shù)據(jù)，檢測(cè)是否存在軟件更新故障或其他突發(fā)問題。檢測(cè)出問題后，需要立即按照某些特定列值召回某輛車或某批車的某些數(shù)值，這就天然形成了一個(gè)對(duì) OLTP 和 OLAP 要求極高的場(chǎng)景。最終這家公司也是選用了 ProtonBase。

Q6：ProtonBase 作為?款基于 Data Warebase 理念的產(chǎn)品，既是?個(gè)數(shù)據(jù)庫，也是?個(gè)數(shù)倉，還?持?jǐn)?shù)據(jù)實(shí)時(shí)加?計(jì)算和數(shù)據(jù)湖上的查詢加速計(jì)算。那么它和 HTAP、流批?體、以及湖倉?體架構(gòu)的關(guān)聯(lián)和區(qū)別是什么?

王紹翾：很多人都會(huì)問到類似的問題。簡單來說，ProtonBase 用創(chuàng)新性的架構(gòu)和實(shí)現(xiàn)，解決了數(shù)據(jù)庫和大數(shù)據(jù)領(lǐng)域詬病已久的諸多問題，能力覆蓋了 HTAP、流批一體、湖倉一體等若干多模場(chǎng)景?？蛻魧?duì)數(shù)據(jù)產(chǎn)品的需求往往只需要使用 ProtonBase 這一款產(chǎn)品就夠了。

Data Warebase 與 HTAP 的區(qū)別

首先 HTAP 不是一個(gè)數(shù)據(jù)庫的概念，因?yàn)?SQL 天然就是一種既能支持 OLTP，也能支持 OLAP 的語言，但當(dāng)數(shù)據(jù)量變大、系統(tǒng)負(fù)載變復(fù)雜時(shí)，很多系統(tǒng)不得不在兩者間做取舍。這也是傳統(tǒng)數(shù)據(jù)庫和數(shù)倉系統(tǒng)割裂的根源。所以 HTAP 要求的是一個(gè)系統(tǒng)能同時(shí)在 OLTP 和 OLAP 這兩個(gè)場(chǎng)景下都擁有很好的寫入和查詢的性能。ProtonBase 作為一個(gè) Data Warebase，既是 Database 也是 Data Warehouse，所以天然就能滿足 HTAP 這個(gè)場(chǎng)景。

但是光有 HTAP 是不夠的，未來是一個(gè)多模數(shù)據(jù)庫的時(shí)代，首先要有很好的 OLTP 和 OLAP 的能力和性能，其次要支持實(shí)時(shí)增量物化視圖做數(shù)據(jù)的 Instant Transform、文本搜索、向量搜索、文檔數(shù)據(jù)存儲(chǔ)和查詢，甚至還要支持對(duì)湖上數(shù)據(jù)的查詢，因此我們提出了 Data Warebase 的概念，它是 Database+Data Warehouse 的合集，是未來多模數(shù)據(jù)庫的一個(gè)新范式。

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

流批一體這個(gè)概念其實(shí)最早就是我們提出的。2015 年我加入淘寶的時(shí)候負(fù)責(zé)商品搜索的數(shù)據(jù)加工，當(dāng)時(shí)很多商品的屬性和指標(biāo)是非實(shí)時(shí)的，我們引入 Flink 解決了數(shù)據(jù)實(shí)時(shí)性的問題，還用 Flink 的 Batch 能力解決了批計(jì)算問題，在那個(gè)場(chǎng)景下將實(shí)時(shí)增量計(jì)算和批計(jì)算做到了計(jì)算引擎和 SQL 的統(tǒng)一，初步實(shí)現(xiàn)了流批一體化。

但這并不是最優(yōu)的架構(gòu)，因?yàn)?Flink 的運(yùn)維和成本比較高，我們認(rèn)為物化視圖是解決流批一體的最佳方案，用戶可以根據(jù)對(duì)每個(gè)物化視圖的 freshness 需要來決定它們的刷新頻率。這樣就完美地實(shí)現(xiàn)了實(shí)時(shí)、近實(shí)時(shí)、以及 T+1 離線計(jì)算的 SQL 與引擎的統(tǒng)一，且運(yùn)維和開發(fā)的易用性極好。

可惜的是，當(dāng)前大部分的數(shù)據(jù)庫或數(shù)據(jù)倉庫提供的物化視圖都不支持增量刷新，導(dǎo)致實(shí)時(shí)刷新物化視圖的成本很高。ProtonBase 投入大量精力實(shí)現(xiàn)了物化視圖的增量刷新，成功打造了一款性價(jià)比極致的流批一體計(jì)算引擎。

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

按照我的理解，湖倉一體只需要滿足兩個(gè)條件：第一是要打通數(shù)據(jù)倉庫和數(shù)據(jù)湖兩套體系，讓數(shù)據(jù)和計(jì)算在湖與倉之間自由流動(dòng);第二是數(shù)據(jù)倉庫能夠?qū)訕?biāo)準(zhǔn)的湖存儲(chǔ)，做外表的查詢、計(jì)算和寫入。ProtonBase 支持 Iceberg，Delta Lake，以及 Hive (ORC/Parquet)等主流湖存儲(chǔ)的互聯(lián)互通和外表查詢，這意味著 Data Warebase 同時(shí)也是支持湖倉一體的數(shù)據(jù)引擎。

Q7：隨著 AI 技術(shù)的?速發(fā)展，數(shù)據(jù)與 AI 的融合越來越緊密，這將為企業(yè)數(shù)據(jù)管理和應(yīng)用帶來全新的變革。在 AI 時(shí)代，您還洞察到企業(yè)對(duì)數(shù)據(jù)庫和大數(shù)據(jù)的需求有哪些變動(dòng)?

王紹翾：我分享兩個(gè)觀察，一是在數(shù)據(jù)庫領(lǐng)域，PostgreSQL 會(huì)變成非常主流的數(shù)據(jù)庫。首先全球幾乎所有的新興數(shù)據(jù)庫都是基于 PostgreSQL API 的。包括被 Databricks 收購的 Neon、被 Snowflake 收購的 Crunchy Data、剛?cè)谫Y的 Supabase、以及最近爆火的 DuckDB、還有 CockroachDB、Yugabyte 等新型分布式數(shù)據(jù)庫公司，無一例外的都選擇了 PostgreSQL 作為查詢 API。所有的 AI 公司也幾乎無一例外都選用了 PostgreSQL，如 OpenAI、Cursor、Notion、Perplexity、Anthropic 等。

大家選擇 PostgreSQL 的原因很簡單， PostgreSQL 非常標(biāo)準(zhǔn)且擁有強(qiáng)大的 Extension，一套 API 幾乎定義了 Data API 所需要的所有能力：OLTP、OLAP、 JSON、GIS、全文檢索、向量檢索。這正是 AI 時(shí)代應(yīng)用和 Agent 所需要的終極 All-In-One 數(shù)據(jù)庫解決方案。ProtonBase 從創(chuàng)立之初就預(yù)見到這個(gè)趨勢(shì)，并基于 PostgreSQL API 構(gòu)建，提前布局 AI 時(shí)代的標(biāo)準(zhǔn)接口。OpenAI o1 發(fā)布之后 AI 的 reasoning 變得非常強(qiáng)大，加上 Anthropic 提出 MCP 的規(guī)范后，使得 language to SQL 成為可能。在 ProtonBase 上使用 PG 標(biāo)準(zhǔn)的 MCP 再配合強(qiáng)大的 AI 模型就可以直接實(shí)現(xiàn)很豐富的 language to SQL 的應(yīng)用場(chǎng)景。

二是在大數(shù)據(jù)領(lǐng)域，未來數(shù)據(jù)湖的標(biāo)準(zhǔn)是 Iceberg。我們看到世界上兩個(gè)最大的數(shù)據(jù)巨頭 ，一個(gè)是 Snowflake，主推的是 Iceberg ，另一個(gè)是 Databricks，以前主推 Delta Lake ，后來收購了 Apache Iceberg 背后的公司 Tabular。所以我們可以預(yù)見到未來企業(yè)的數(shù)據(jù)湖基本都會(huì)圍繞著 Iceberg 構(gòu)建，ProtonBase 也很好地對(duì)接了 Iceberg 數(shù)據(jù)湖，完善了湖倉一體的能力。

Q8：創(chuàng)業(yè) 4 年，您對(duì)其他 AI 和數(shù)據(jù)的同行或者創(chuàng)業(yè)者有哪些建議分享?

王紹翾：一路走來還是學(xué)到很多，邊做邊學(xué)。有幾個(gè)感觸最深的點(diǎn)：

第一點(diǎn)就是需要想清楚作為創(chuàng)業(yè)公司自己的產(chǎn)品 PMF 是什么?客戶是誰?如何賣給客戶?在這個(gè)過程中你的產(chǎn)品能力一定要在這個(gè)領(lǐng)域最好是第一，最差也要在前三。ToB 是 Value Selling(價(jià)值銷售)和 Solution Selling(解決方案銷售)，對(duì)一家創(chuàng)業(yè)公司而言，想清楚自己產(chǎn)品的 PMF 和打造好產(chǎn)品的競(jìng)爭力至關(guān)重要。

其次，前期要專注于服務(wù)大客戶。因?yàn)榇罂蛻舻奶魬?zhàn)和場(chǎng)景非常多且復(fù)雜，他們往往代表了其所在行業(yè)最大的挑戰(zhàn)，如果能解決好大客戶的問題，也會(huì)極大提升你在此行業(yè)中的影響力和公信力。

最后就是 ToB 業(yè)務(wù)繞不開的話題：全球化和出海。這是一個(gè)必選項(xiàng)，中國有大量卓越的軟件工程師能夠做出世界一流的產(chǎn)品，我們需要把這些產(chǎn)品和能力輸出，在全球做生意，把利潤帶回來， “Made in China，Sold Global” 是我們這代人的使命。

zhupb