作者：楊克特 ProtonBase 技術副總裁

畢業於浙江大學計算機系，獲碩士學位，具備 10 多年核心系統設計和研發經驗。曾任阿里巴巴資深技術專家，負責過搜索引擎、資源調度、實時監控等系統的設計和研發。具備豐富的開源經驗，是 Apache Flink 和 Apache Druid 的 PMC 成員，以及 Apache 軟件基金會成員。

概念科普：Data Warebase = Data Warehouse + Database，由 ProtonBase 在業界首次提出。

今天主要和大家探討一下在雲原生時代大背景下，常見數據平台所面臨的機遇和挑戰，以及最新的演進趨勢。同時還會分享 ProtonBase 在這一過程中的實踐經驗。最後，結合當下 AI 的流行趨勢，探討一些看法，希望能給大家帶來一些啓發。

典型的數據架構演進路徑

在説到數據平台上雲之前，先來看線下一個比較典型的數據架構是如何一步步發展出來的。

一般來説，每家公司一開始都會有自己的應用以及後台的應用服務。這些應用服務往往需要一個數據庫來承接實時的讀寫流量。而當業務發展較為順利時，單機數據庫很可能無法滿足業務需求。此時，很多公司會在其基礎上進行分庫分表操作。如果有一些對存儲較為靈活的需求，可能會採用像 MongoDB 這樣天然具備分佈式能力的數據庫。

隨着業務的發展，數據庫上簡單的點查點寫可能無法滿足業務的複雜需求，比如像搜索這樣的需求。此時，可能需要引入像 ES 這樣的搜索引擎。由於公司裏的數據都在前面的 MongoDB 和數據庫裏，就需要搭建一個數據同步鏈路，每天把數據從數據庫裏全量同步到數據倉庫中，然後進行離線處理，再放到 ES 中，從而使整個業務具備搜索能力。

既然有了數據倉庫，大部分公司接下來會開始構建自己的離線數據倉庫，比如像典型的 Hive。構建完離線數據倉庫之後，公司裏的運營人員或主管們就可以開始查看報表。隨着大家對數據實時性的要求越來越高，一天級或者小時級的離線處理顯然無法滿足這樣的要求。那麼，很有可能會引入像消息隊列、Flink 這樣的實時處理技術，針對源頭業務中的數據通過 CDC 的方式拉取過來進行增量計算。

算完的結果可以同時放到 ES 和放到 Clickhouse 這樣的一個實時 OLAP 引擎裏，這個時候系統就具備了比較實時的做搜索以及實時分析這樣的能力，這是線下的一個典型的業務架構的比較自然而然的發展流程。

數據平台上雲的“得”與“失”

在雲原生時代，很多企業也會把自己的數據平台搬上雲，上雲之後會有以下好處：

首先，顯而易見的是資源的靈活性大大提升。就像剛才看到工商銀行袁老師的分享，工行線下有很多服務器，有些服務 CPU 性能強，有些服務器內存容量大，還有些服務器存儲能力強。但其實很難預知接下來一年公司內部的業務到底會更多地使用哪種機器資源。如果一開始規劃不好，很可能就會造成一些資源浪費。

而在雲上，這種情況就不存在了。雲上有各種各樣的資源，你可以按需採購，不用提前做那麼複雜的規劃。並且在上雲之後，各雲廠商或多或少都會提供一些半托管的產品，或者多種全託管的產品，有助於大家降低運維壓力。

同時，各大雲廠商也都有比較優秀的自研產品。因此，上雲之後，企業不再侷限於線下只能選擇一些開源系統，而是有了更多的系統選擇。

但上雲也並非沒有挑戰：

首先，當你的數據架構完全平移到雲上之後，會面臨一個現實問題：由於每個系統的迭代速度不一樣，有些系統可能並沒有針對雲原生做特別的優化，只是將原來運行在線下的系統直接搬到線上。這種情況下，其實和線下並沒有太本質的區別。但當你選擇了一個雲廠商之後，數據反而可能會被其鎖定（Lock-in），因為實現數據的多雲部署其實並不容易。

而且，當你選擇了一個雲廠商之後，對於相同的軟件，不同雲廠商之間在該產品的能力上會存在差異。比如以我比較熟悉的 Flink 為例，阿里雲的 Flink 在某些功能和性能優化方面可能表現得更為出色，而其他雲廠商的 Flink 版本在這些方面可能相對弱一些。

以 AWS 為例，當系統架構遷移到雲上之後，你會發現 AWS 的 RDS 非常出色，我們可以將原本的開源 MySQL 替換為 RDS。同時，AWS 的 Redshift 也很強大，可以將 Hive 升級為 Redshift，以獲得更高效的數據分析能力。此外，還可以替換搜索系統，以實現更強大的搜索功能。同時，S3 提供了非常經濟高效的存儲解決方案，可以利用它來存儲大量數據。

所以，完成這樣的升級之後，你會發現架構的本質並沒有發生根本性的變化，但確實帶來了一些顯著的好處。當然，這也伴隨着一些成本的付出。然而，各個公司對業務的需求遠遠沒有停下來，反而越來越多。例如，常見的 TP 和 AP 混合查詢在這種架構下就比較難以應對。

我們常常面臨一個比較尷尬的問題：到底是應該在 TP 庫中運行 AP 查詢，還是在像 ClickHouse 這樣的 AP 系統中運行一些點查（TP）操作呢？如果同一個業務流程中涉及到的查詢既需要 TP 的實時性，又需要 AP 的分析能力，那就更讓人頭疼了。如果放在 TP 庫中運行，不僅速度會變慢，還可能影響 TP 庫的穩定性；而如果放在 AP 系統中運行，又可能因為數據延遲，導致 AP 系統中找不到最新的數據。

當我們建立了離線和實時兩套 BI 流程後，大家在使用過程中發現實時計算出的結果和昨天離線計算的相同時間點結果對不上，這就會讓人感到困惑。因此，這也促使我們開始探索離線和實時一體化處理的解決方案。

現在 AI 很火，大家也開始思考如何從業務數據中提取和加工 AI 所需的特徵。對於離線特徵，由於企業所有的業務數據都存儲在 S3 上，我們可以在 S3 上進行處理，生成離線特徵並將其存儲到 Redshift 中。同時也可以通過 Flink 計算實時特徵，並將這些特徵存儲到 MongoDB 中，以便進行實時服務。

隨着生成式 AI 的主鍵流行，基於業務數據做向量檢索的需求也不斷增加，我們又會選擇搭建一個專門的向量數據庫，並進行數據同步。

總之，隨着新的需求的不斷到來，圖裏的線似乎可以無止境地畫下去，甚至還可以在上面擺出更多系統。雖然上雲帶來了諸多靈活性的優勢，但它並沒有解決整個數據系統內在的原生複雜度。在我看來，這種複雜度會引發三個方面的問題。

數據系統的“熵”

• 開發視角：首先，從業務開發人員的視角來看。當業務系統越來越多時，公司就需要招聘更多不同類型的研發人員。有些研發人員對系統 A 和 B 比較熟悉，而有些研發人員可能對系統 C 和 D 比較熟悉。系統越多，所需的研發人員類型就越豐富，這無疑提高了門檻。而且，每個研發人員還需要清楚地瞭解系統 A 擅長什麼，系統 B 擅長什麼，如果這兩個系統都不擅長，那就得去找系統 C，這就大大拖慢了開發的效率。
• 運維視角：同時，因為系統眾多，系統間的數據搬遷就成了一大難題。你不得不開發大量數據遷移任務，這些任務數量往往非常龐大，成了系統穩定性的薄弱環節。除此之外，大量的數據同步任務也使得成本急劇上升。
• 業務視角：另外，從業務人員的角度來看，假設有一天業務方提出了一個新需求，我們要做的第一件事情不是開發業務代碼，而是增加新的數據同步鏈路。這樣一來，迭代效率就會變得很低。更糟糕的是，假如現有的業務系統中沒有一個能滿足要求，還需要臨時去採購一個新的系統，而這個採購週期通常要以半年以上來計算。

回過頭來看，數據鏈路的複雜度逐日上升的根本原因是，過去二十年我們對大數據帶來的挑戰沒有形成一個系統性的解法。當時的解法就是見招拆招。數據存不下，那就先造個 HDFS，把海量數據存起來；面對海量的 KV 讀寫需求，那就先造個 HBase 來扛住。每個系統都只具備少數幾個核心能力，當需求複雜了後自然就需要大量系統的協同工作。

理想中的數據系統

但如果站在 2025 年的今天來回溯，假設我們已經掌握了所有的相關知識，面對剛才提到的那些數據需求，從零開始去打造一個理想中的系統，那麼它大概會是什麼樣子呢？

• 統一的 API：首先，我覺得第一點是必須有一個統一的 API。就像剛才提到的，業務開發人員不希望去學習五花八門的多種語言，每個系統的 API 都不一樣。如果能有一個統一的 API，那麼這個 API 的表達能力就需要足夠強大。
• 統一存儲：同時，我們也不希望數據在不同的七八個系統之間來回流轉。而是希望整個數據存儲至少在一個地方都能看到，沒有數據孤島，也不需要做太多的數據同步。
• 存算分離：此外，藉助雲計算靈活的資源環境，我們希望整個系統是存算分離的。存儲不夠就加存儲，計算不夠就加計算，這樣可以實現非常高效的水平擴縮容。
• 實時寫入、實時查詢：從系統的查詢能力來講，這個系統能夠實現數據實時寫入、實時可見、實時可查。
• 多模態支持：同時，系統應具備搜索引擎的能力，支持全文檢索、多維檢索和聚合查詢。此外，系統還應具備實時分析和向量檢索的能力。總的來説，它需要具備多模的能力。

過去幾年，我們也帶着這個問題去做了一些嘗試。先從 API 看起，從語言的表達能力來看，SQL 是久經考驗的，選擇 SQL 基本不會引起太大爭議。但具體選擇什麼樣的 SQL，就需要仔細考量。我們發現 PG（PostgresSQL）的生態近年來發展得非常繁榮。雖然在 10 多年前，PG 可能還處於不温不火的狀態，但如今，它的上下游工具、文檔以及相關產品都形成了非常完善的生態。

PostgreSQL 生態的優勢與挑戰

從流行度來看，PG 在過去 10 年一直保持着高速增長，並且在近兩年的 Stack Overflow 開發者調查中，連續蟬聯了“最受歡迎的數據庫”這一稱號。

PG 的流行離不開它的諸多優點：

首先，它是一款數據庫，天然具備 ACID 能力，能夠保證數據的強一致性。它支持多種數據類型和多種索引。最關鍵的是，它的可擴展架構非常強大。從上圖可以看出，基於 PG 構建的系統，不僅可以直接使用 PG 本身的功能，而且很多創業公司基於 PG 開發出了適用於不同場景的核心能力。比如，有些公司基於 PG 開發了時間序列的擴展，還有公司開發了 PG vector 這樣的向量檢索擴展。這説明 PG 的擴展性非常強，也給我們帶來了很大的啓發。

如何解決 PG 水平擴展的問題？

但如果基於 PG 去構建一個全新的系統，最大的問題是：PG 是一個單機數據庫，我們需要實現水平擴展的能力，以及如何做到彈性伸縮。

先來看第一個擴展問題，這個問題的關鍵點在於如何給數據做分片。常見的分片策略其實都比較簡單。一種是哈希分片。如果一開始大概知道表要分成三片，做過分庫分表的同學應該就很熟悉了：給 key 計算一個哈希函數，然後對 3 取模，根據取模的結果就能確定某一行數據應該去到哪一個分片。

還有一種比較主流的做法是 Range 分片。這種方式不是按哈希值來分，而是根據數據的取值範圍來劃分。比如， a 到 c 是一個分片， d 到 h 是第二個分片。

我們仔細對比一下它們的優劣：

首先，從系統開發者的角度來説，哈希分片是很吸引人的。它實現起來非常簡單，而且效果也不錯。只要選擇一個合適的哈希函數，數據進來後基本都能均勻分配到各個分片，用户無需太擔心熱點問題。而且，哈希分片的查詢路由也很簡單。如果查詢是基於 key ，系統只需要計算一下哈希值，就能直接定位到數據所在的分片。如果不是基於 key 的查詢，那就直接廣播到所有分片即可。所以哈希分片的實現複雜度其實很低，效果也不錯。

Range 分片比較吃虧，因為在數據進入系統之前，系統無法預知數據的範圍分佈，比如無法確定是 a 到 c 是一個分片，還是 a 到 d 是一個分片更加合理。因此，系統需要一直維護一個全局的路由信息來管理這些分片。

但如果反過來，從使用者的角度來看，這兩種分片策略在實際表現上會有一些不同。比如，Range 分片在範圍查詢方面就比較有優勢。假設你的過濾條件是 Key 上的大於、小於或等於之類的範圍查詢，Range 分片在查詢時會更高效，因為它不需要廣播查詢到所有分片。從易用性角度來看，Range 分片也更好一些，用户不需要提前預配置分片數。在實現時，系統通常會自動進行分片，並且能自動進行拆分（split）或合併（merge）。

哈希分片一旦在一開始配置好了分片數，後續想要修改就比較困難，這是一件比較傷筋動骨的事情。想象一下，假如一開始配置成了 10 個分片，所有數據的哈希值都是模 10。這個時候如果想把分片數從 10 改成 11，所有數據的哈希值都要改為模 11。由於以前模 10 的結果和現在模 11 的結果會有非常大的區別，所以整個數據可能需要重新搬遷一次。因此，從用户的角度出發，如果想給用户提供更好的使用體驗，ProtonBase 認為 Range 分片會更好一些。

如何選擇一個合理的存算分離架構？

解決完分片的問題之後，再來看看如何選擇一個合理的存算分離架構。這是一個非常簡單的示意圖：

現在，絕大多數大數據系統基本上都是採用存算分離架構。具體來説，底層可以使用像 S3 這樣的對象存儲，計算節點直接連接 S3 進行存儲和計算。為了保證吞吐量，通常還會引入一些本地的高速磁盤，用於做本地緩存。

這種架構在吞吐量方面表現較好，但面臨的一大挑戰是高併發實時寫入場景。比如在使用數據庫時，通常會有高併發的實時寫入，或者單條記錄的更新、刪除等操作。在這種架構下，由於所有寫入操作都需要同步地持久化到底層存儲，而像 S3 這樣的存儲本身並不擅長支持低延遲且高頻的調用，因此在這種實時高併發場景下，該架構較難滿足需求。

要解決這個問題，如果希望既要保證吞吐量，又要在延遲上有較好的表現，一般來説，首先需要依賴一個高速的底層存儲。比如高速的本地 SSD 盤，或者高速的雲盤，來實現非常低延遲的持久化操作。

再往上，由於數據需要可靠存儲，就需要引入分佈式一致性協議來保證數據不丟失。因此，若想在保證吞吐量的同時確保低延遲，大部分情況下就需要引入專門的存儲服務，由它來提供高可靠、高吞吐、低延遲的讀寫能力。唯一的缺點是實現起來比較困難，但既然這是正確的方向，ProtonBase 還是希望朝着這個目標去努力。

結合剛才提到的 Range 分片和存算分離，我們可以回過頭來思考一下：折騰了這麼久，我們到底是為了達到什麼樣的效果？

✨ Data Warebase 核心能力 1：秒級彈性伸縮

其實 ProtonBase 考慮了很多方面，其中我個人覺得從用户角度來説非常重要且體驗很好的一點，就是低成本且快速的擴縮容能力。

在一個正在運行的集羣中，由於計算節點是無狀態的，我們可以隨時隨地增加或減少計算節點。當用户加入一個計算節點後，如果現有的分片數量不足以充分利用新節點的計算能力，系統可以自動對已有的分片進行拆分。由於採用的是 Range 分片，分片拆分的代價隨時很低的。而且，得益於存算分離架構，新拆分出來的分片可以被新節點實時的看到。這樣一來，新節點就能實時地將部分負載從其他節點接管過來。

從用户的角度來看，當他們加入一個新節點時，可能只需 5 秒鐘，這個節點就能立刻開始提供服務，並且完全不需要進行任何數據搬遷。同樣地，當系統的計算節點容量出現冗餘，或者計算資源過多時，用户可以輕鬆地移除一個節點，而無需擔心數據搬遷的問題。在移除節點後的幾秒鐘內，原本分配給該節點的所有負載會自動且均勻地重新分配到其他計算節點上。這就是 ProtonBase 系統所具備的彈性伸縮能力。

HTAP 常見架構對比

現在我們來看一下 TP 和 AP 混合檢索的需求。首先，我們先對比一下現在主流的 HTAP 的實現架構。一般來説，企業會搞兩套數據庫，一套是 TP 的數據庫，一套是 AP 的數據庫。它們中間通過 ETL 任務去做數據的同步。

除了剛才提到的負載分發問題，通過 ETL 任務進行數據同步的方式還會引入一定的數據延遲，導致數據的可見性無法得到保障。現在有一些更新的架構，例如 HTAP 數據庫，它內部可以同時支持兩套存儲格式：行存和列存。行存適合 TP 引擎訪問，能夠高效處理事務操作；列存適合 AP 引擎訪問，能夠高效處理分析查詢。所有已提交的 TP 事務可以自動從行存同步到列存，而且這種同步的延遲可以做到非常低。

但是這裏面有一個比較細微的，但在某些業務場景下非常關鍵的問題，那就是很難保證事務的一致性。在此解釋一下什麼是事務的一致性：假設用户有一個業務場景，想在一個大的事務內完成一系列操作。一開始，用户先進行一些 TP 的簡單修改。修改完成後，由於不知道這些修改會引發多大的後續變動，用户需要先運行一些校驗操作。比如，修改了一個值，接着運行一些統計 SQL，以確保修改的結果符合預期。只有在這些校驗都通過後，用户才敢提交這個事務。如果列存只能看到已經提交的事務，那麼這種非常強的一致性要求就很難滿足了。

既然我們已經能夠將引擎統一到一個數據庫裏，並且同時支持行存和列存，那麼下一步比較直接的想法就是：為什麼不把這兩種存儲格式的優點結合起來，形成一種混合存儲格式呢？行存支持高效的 TP 工作負載，而列存則支持較好的 AP 能力。

✨ Data Warebase 核心能力 2：混合存儲

這就是 ProtonBase 的另一核心能力：混合存儲。由於數據存儲在同一種文件格式中，所以用户完全不用擔心一致性問題，它天然就是強一致的。所有寫入的數據都不需要進行額外的數據同步，也不需要外部的 ETL 操作。

在混合存儲之上，我們內置了一套 TP 引擎和一套 AP 引擎，它們之間的負載隔離非常重要。首先，有不同的隔離方式。如果不想把部署搞得過於複雜，可以在相同的計算組內做一定的軟隔離。

✨ Data Warebase 核心能力 3：負載隔離

從優化器的視角來看，它會幫助用户分析這是一個比較小的 TP 查詢，還是一個比較大的 AP 查詢，然後根據成本來動態選擇最合適的執行計劃。我們支持不同負載之間的優先級，並將優先級傳遞到 CPU、內存、IO 等共享資源上進行一定的負載隔離，保證 TP 和 AP 之間的負載不會有很大的互相影響。

但軟隔離終究有其侷限性，隔離能力肯定存在上限。如果需要實現非常強的硬隔離效果，可以啓動多個計算組。例如，一個計算組專門運行 TP 工作負載，另一個計算組用於處理複雜的分析場景。當然，還可以再創建一些計算組，用於運行特別複雜的離線加工作業。每個計算組都可以根據需求隨時啓動或停止。對於那些複雜的加工任務，如果平時不需要運行，完全可以將其全部停掉，等到需要時再啓動。

離線實時一體化架構演進的問題

剛才也提到了實時和離線口徑不統一的問題，這其實是很經典的問題，做大數據的同學應該都很熟悉。這種問題通常會採用 Lambda 架構來解決，Lambda 架構在一定程度上確實解決了如何融合離線和實時結果的問題。然而，它的問題也是顯而易見的。

比如，文件系統的存儲和消息隊列的存儲顯然是冗餘的。而且，你還需要用兩個大數據引擎來處理數據，用 Hive SQL 寫一套離線處理邏輯，同時可能還需要用 Flink 或 Spark SQL 寫一套實時處理邏輯。畢竟，每個鏈路都開發一套離線，一套實時計算系統，這個代價還是挺大的，並且還要兩邊互相調試、交叉對比。

所以，業界這幾年也一直在摸索架構的下一步迭代。

• 第一階段：計算引擎統一。比如，Spark 和 Flink 現在都具備了跑離線批處理和流處理的能力，這樣就不用再維護多個計算引擎了。同時，由於是同一個引擎，它們在語義上也能夠儘量做到一致，這是第一階段發生的事情。
• 第二階段：存儲統一。最初，文件系統存儲一套數據，消息隊列又存儲一套數據。現在，人們開始思考能否在一套存儲系統上，既能實現文件系統的批量掃描能力，又能具備消息隊列讀取增量數據的能力。因此，目前像 Iceberg、Hudi 等湖存儲的主流發展方向，正是朝着這種融合能力的方向發展。

但是在這兩個階段完成之後，仍然遺留了一些問題：

1.  儘管計算引擎實現了統一，但 SQL 並沒有統一。實時 SQL 仍然有其特殊性。不知道大家有沒有開發過 Flink 的實時作業，比如你可能需要理解一些像 Watermark 的概念，或者是否存在維表關聯等概念，所以它還是有一些獨特之處的。
2.  實時作業和離線作業的運行模式天然不同。離線作業基本上是計算一次、產出結果就完成了；而實時作業為了實現增量計算，需要在內部存儲大量的狀態信息，比如在進行 join 操作時需要將 join 的輸入都存在內部的狀態存儲裏。因此，離線 SQL 和實時 SQL 的運行模式存在本質區別，基本上很難實現兩者的無縫切換。
3.  實時作業雖然可以做到很低的延遲，例如達到秒級，但其成本相對較高。然而，在一些業務場景中，並不需要那麼高的實時性，比如 5 到 10 分鐘的延遲就足夠了。目前，無論是離線還是實時計算，都沒有很好地滿足這種對實時性要求介於兩者之間的需求。

因此，在前兩個發展階段的基礎上，ProtonBase 提出了對這個問題的一些思考。我們認為可以借鑑數據庫的物化視圖，結合增量計算的能力，來進一步統一計算模型，從而更好地解決這種需求。

✨ Data Warebase 核心能力 4：增量物化視圖

首先，物化視圖是數據庫中的一個原有概念，它與離線 SQL 完全一致，沒有任何實時的特殊性，從而解決了 SQL 語義不同或 SQL 方言不同的問題。

以一個物化視圖為例，當全量運行時，它與離線作業並無二致。比如，一個表與另一個表進行連接操作併產生結果。在此基礎上，如果表一和表二的數據發生了變化，我們不希望重新運行全量作業，而是希望讀取這些表的最新變化，並將這些變化反映到結果中。這本質上就是 Flink 或 Spark 等實時作業所做的事情，而增量物化視圖模型也完全可以實現這樣的功能。

它帶來的好處也很明顯。首先，ProtonBase 的表天然具備批量讀取和增量讀取的能力，沒有額外的冗餘存儲開銷。此外，還有一個顯著優勢是，以往這些數據處理鏈路中的作業都需要同步到外部的 OLAP 系統中進行服務。但如今，由於 ProtonBase 的系統本身具有強大的 OLAP 能力，無論是原始表還是經過加工的物化視圖（MV）結果，都可以直接在數據庫內部提供服務。因此，我們認為這種基於物化視圖結合增量計算能力的統一計算模型，是未來計算模型演變的一個趨勢。

Data + AI

剛才講的基本上都是圍繞數據相關的內容，接下來我想結合當下比較流行的 AI 和大家探討一下數據和 AI 到底能夠碰撞出什麼樣的火花。

在講 AI 之前，先回顧一下剛才講的內容。從整個數據鏈路的起點説起，包括後面提到的 HTAP 以及實時離線一體化等概念，它們為什麼會逐步提出這些需求？它們有哪些共性的本質變化在逐步演進？

一方面，對數據實時性的要求越來越高，數據從業務源頭產生到最終能夠被查詢的時間間隔需要不斷縮短。與此同時，用户對查詢的吞吐量（QPS）也提出了更高的要求，並且查詢的形式也越來越豐富多樣。最初可能只有簡單的點查點寫操作，但隨着業務的發展，逐漸增加了數據分析、關鍵詞搜索等多種查詢形式。

舉個例子，像最早大家都還在用離線數倉的時候，大部分情況下離線數倉的加工時效性只能以天或小時為單位。比如，企業可能每天凌晨運行一次數據處理任務，生成前一天的報表，這些報表通常只有公司高管或者少數關鍵人員才能看到。這其實本質上是因為數據時效性比較低，同時查詢的吞吐量（QPS）也不高，導致它能夠帶來的價值非常有限。所以在這個時期，降本基本就是主旋律。

隨着技術的發展， 整個數據鏈路的時效性開始提升至分鐘級甚至更低。與此同時，對數據的需求也從少數人員逐步擴大到更多的業務同學，甚至可能直接提供給公司的客户，這帶來了更高的 QPS 需求。更新鮮的數據，疊加更高頻的數據訪問，能夠帶來更大的業務價值。從這個階段開始，數據應用開始給業務增效。

畢竟人的查詢能力終究是有限的。我們也看到，現在很多業務系統開始採用代碼或規則引擎等方式來訪問數據。通過這種方式，系統可以基於數據自動執行一些簡單的決策，從而替代人工操作，對系統的訪問量可能又會上升一個台階。在這種情況下，代碼實際上替代了人的角色，能夠為公司帶來一些比較典型的業務價值。

更實時的數據，結合更加高頻的多模態查詢，才能真正發揮數據的價值，這也是過去數據系統不斷演進的底層邏輯。未來有了更加智能的 AI 之後，這個趨勢是否能延續下去？

AI 時代，數據還重要嗎？

這裏還得先回答一個問題：在 AI 時代，大模型已經掌握了世界上幾乎所有知識的情況下，你們公司內部的數據是否還重要？我覺得這個問題的答案最好還是交由 AI 自己來回答。

這就是我向 DeepSeek 提出的問題：

我並沒有透露自己是哪家公司的，也沒有多説其他信息，只是問了關於公司是否提供停車位的問題。DeepSeek 前面回答了一堆，但其實沒什麼幫助。不過，它最有價值的回答在最後那個框裏：“請提供更多的上下文讓我來幫你解答。”所以，數據重不重要，其實就藏在 AI 的答案裏。它雖然掌握了世界上所有的知識，但卻不知道你們公司內部的知識。

RAG 基本原理

這就引出了現在很流行的基於 RAG 的召回流程。簡單過一下這個流程，防止有一些同學可能對這個不是特別熟悉。就像剛才這樣的一個問題，我們把它打到後端的召回系統，召回系統會對這個問題進行抽象，把它加工成一個向量，然後向量就可以在公司內部的知識庫做搜索，之後可以把相關的文檔進行召回。

比如剛才提到的停車位的例子，召回的文檔可能包括公司各種停車策略以及負責停車事務的行政人員等信息。把所有相關文檔都召回後，將這些內容作為上下文提供給大模型，本質上就是先給它鋪墊 2000 字左右的背景信息，比如公司停車的具體策略、涉及的人員等，最後再問公司停車位的情況。這樣，大模型就能清楚地知道怎麼回答了。這其實就體現了大模型對上下文的需求，而且在大多數情況下，它能夠據此給出一個比較好的回答。

從知識庫中召回相關文檔是信息檢索中的關鍵步驟。對於有搜索引擎開發經驗的人來説，這一步驟可能並不陌生。過去，用户主要依賴關鍵詞搜索來召回文檔，通過關鍵詞的匹配和相似性計算來實現。而如今的向量搜索技術則通過語義理解來召回文檔。由於關鍵詞搜索在精確匹配方面具有優勢，因此將向量搜索與關鍵詞搜索相結合的混合檢索策略，可能會比單一策略更具優勢。

融合傳統搜索技術和向量檢索

單一的向量搜索在某些情況下效果並不理想。如果將向量搜索與成熟的關鍵詞搜索技術相結合，並利用關鍵詞搜索的相似性計算，這種融合策略往往比單一策略更有效。例如，有研究對比了僅對大模型進行微調與採用混合檢索策略的效果。研究發現，將向量搜索和關鍵詞搜索相結合的混合檢索策略，比僅對大模型進行微調後的效果更好。

✨ Data Warebase 核心能力 5：索引

在這種場景下，數據系統需要具備倒排索引和向量索引的能力，以滿足關鍵詞搜索和語義搜索的需求。倒排索引能夠快速定位包含特定關鍵詞的文檔，而向量索引則通過語義理解來匹配文檔。這種混合檢索策略結合了兩者的優點，能夠彌補單一檢索技術的不足，提升檢索效果。

AI 是對數據系統的一次“大考”

所以，如果讓我暢想一下未來 AI 對數據系統的要求，我覺得 AI 其實給整個數據系統帶來了一場全方位的“大考”。過去，用户對數據系統的使用在某些情況下可能還相對簡單，但一個成熟高效的 AI 應用鏈路，必然會對數據系統提出全方位的挑戰。

首先明確要求整個數據系統必須是實時的。無論是通過數據庫的實時同步，還是通過消息隊列的實時同步，關鍵在於所有源頭數據能夠實時寫入到這個數據系統中。

在將數據寫入該系統之後，需要在系統內進行二次加工。可能需要生成一些向量，也可能需要創建一些索引，同時還要完成數據倉庫中常見的操作，比如數據清洗、過濾等，所有這些工作都需要在這個系統內完成。

當準備好這一系列數據之後，一個比較智能的 AI agent 就會向數據系統發出各種各樣的查詢。這些查詢不僅限於剛才提到的關鍵詞搜索、向量搜索（這些是已經熟悉的），它還可能發起基於圖的檢索，或者其他一些我們目前還未演進出來的檢索方式。這可能需要根據 AI agent 的真正策略來決定，但可以肯定的是，這裏的檢索一定是一個多模態的檢索。

有了這樣的多模態檢索之後，它才能將決策實時反饋到業務端。而在這個過程中，還需要科學家對整個流程進行有效監控。他們需要對檢索結果進行實時分析和探索，甚至可能需要提供一些輸入，思考如何更新或迭代 AI agent 的策略。此外，科學家可能還需要在數據上進行實時挖掘和分析。因此，在一個完整的系統中，需要強大的支撐，這其實對數據系統來説是一個全方位的挑戰。

數據架構新範式

以上就是過去幾年 ProtonBase 的一個實踐，我們希望使用一個系統來解決當下以及未來對數據的大部分需求。

最後，簡單總結一下。在雲原生飛速發展的當下，如果能夠充分利用雲的能力，將為企業的數據系統帶來更出色的體驗。從過去的數據發展歷程，到未來 AI 面臨的挑戰來看，實時性、多模態、一體化這幾個方面都將面臨更多的需求和挑戰。而 ProtonBase 提倡的 Data Warebase 理念正是應對這些需求和挑戰的總結與解決方案。