為什麽又造了個新詞 Data Warebase：我看到了 AI 時代數據平台應當的樣子

作者 | 蔣曉偉

引言：在這個 AI 技術飛速發展的時代，我們有能力更深入地發掘數據潛在的價值，而數據處理不應當成為阻礙。雲原生分布式 Data Warebase 將開啟處理數據的新範式，它讓數據的使用返璞歸真，不論是儲存還是查詢，一個系統滿足業務全方位數據需求。打破復雜數據架構的束縛，大大降低數據的使用門檻，釋放數據潛能， 讓數據湧現智慧 。

1 背景

1. 近二十年大數據發展史

2002 年我加入 Microsoft SQL Server 引擎團隊。那時的資料庫市場相對簡單，主要有三個廠商：Oracle、IBM（DB2）和 Microsoft（SQL Server）。資料庫行業似乎已經相當成熟，發展趨於穩定，新的產品 / 廠家看起來不再有機會。我曾一度思考過繼續做資料庫是不是一個正確的職業選擇。與資料庫行業的成熟穩定相比，互聯網業務蓬勃發展，對資料庫能力和效能的要求與日俱增，一場解決水平擴充套件的戰爭悄然開始。

Microsoft SQL Server 等傳統資料庫存在一個較大的限制：作為一個單機的架構，只能透過用更大的機器向上擴張，因此效能總會受到單機效能的瓶頸制約。要將其轉變為分布式架構是一項非常艱巨的任務。盡管 SQL Server 在這方面進行了一些嘗試，但真正開始引領分布式革命的是谷歌發表的幾篇論文。

GFS 和 MapReduce ：Google 分別於 2003 和 2004 年發表了這兩篇論文。GFS 描述了分布式檔案系統的實作，為海量數據的儲存指明了方向。MapReduce 則是進行大規模數據處理的一種架構。這兩篇論文對整個行業產生了深遠的影響，它使業界認識到使用普通硬體就可以實作海量數據的分布式儲存和計算。

Hadoop ：受到 GFS 和 MapReduce 的啟發，開源框架 Hadoop 在 2006 年應運而生，此後十多年裏，整個 Hadoop 大數據生態系蓬勃發展。

Bigtable ：2006 年，谷歌發表了 Bigtable 論文，介紹了這一分布式儲存系統，旨在解決大規模結構化數據的儲存與存取問題。Bigtable 的推出對後續的技術演進產生了重大影響，標誌著 NoSQL 時代的開始，促進了包括 HBase、Cassandra 和 MongoDB 等一系列 NoSQL 系統的發展。

Hive ：2008 年，Facebook 推出了 Hive，它基於 MapReduce 技術，大大簡化了處理大數據的過程，使用者僅需透過一條 SQL 語句即可執行復雜查詢，極大提升了分析領域的工作效率。

Spanner ：2012 年，谷歌釋出了 Spanner 的論文，介紹了這一內部開發的真正的分布式關系型資料庫的實作，業界終於看到了分布式關系型資料庫的可行性。

自 2003 年起的二十年，數據行業經歷了驚人的快速發展，推動了一系列的技術突破與創新。這一行程主要驅動力是解決日益增長的業務需求，尤其是在海量數據的儲存和處理方面。隨著數據量的激增，行業不斷前進演化以支持更高效、更強大的數據管理和分析能力。

2. 業務視角：以一個民宿 App 為例

這裏以一個民宿 App 為例來分析套用在數據的儲存和處理方面的需求。

首先，需要一個系統儲存每個民宿的基本資訊以及各種使用者數據，如一個民宿的地理位置、房間數、檔期、設施、價格、使用者的入住評論、還有使用者使用套用的互動日誌等。這些數據可以分為以下幾類：

1. 結構化的數據 ：民宿的基本資訊，如房間數量、價格等，這些可以用結構化數據來描述。

2. 半結構化數據 ：各類設施的款式、功能參數等，這些涉及到半結構化數據，需要更復雜的方式去儲存。

3. 非結構化數據 ：如民宿照片和文字評論等，是典型的非結構化數據。

其次，使用者可能在套用裏以多種方式去使用這些數據：

1. 簡單查詢 ：使用者知道民宿的名字，直接進行查詢。

2. 條件檢索 ：使用者根據一些條件，比如價格、地理位置、衛生狀況等，去搜尋符合需求的民宿。

3. 語意 搜尋 ：使用者進行一些語意層的搜尋，比如尋找衛生條件好、價效比高、簡約風格的民宿，這需要系統對影像和評論的語意進行理解。

4. 匯總分析 ：使用者希望檢視過去幾天或一個月內某城市評價最高的民宿，這需要系統對城市內所有民宿的評價進行匯總分析。

3. 現有數據架構的弊端

這款民宿套用必須能有效儲存結構化、半結構化和非結構化數據，還需具備多種查詢和分析的能力。作為一個互聯網級的套用，其水平擴充套件能力也是必須。然而，市場上尚無一款產品能夠很好地滿足所有的需求，因此業界通常需要將多種數據產品組合起來，比如將結構化數據儲存在 MySQL/PostgreSQL 等關系型資料庫中，將半結構化數據儲存在 MongoDB 裏，將需要搜尋的數據儲存在 ElasticSearch 中等等。這種復雜的業務架構可能帶來一系列問題：

開發門檻

在這樣一個復雜的業務架構下，任何新業務功能的開發都可能涉及使用多個數據產品，這就意味著業務開發需要去學習多個數據產品，理解它們各自適用的場景和利弊，以及如何把這些產品組合起來解決業務問題，這大大提高了開發的門檻。特別是在中小企業，因為數據人才的稀缺，往往會導致很多數據的業務價值沒有充分發揮出來。

開發效率

即使一個企業幸運地擁有一些能夠駕馭各種數據產品的專家，他們也不得不花很多時間在實作復雜的數據架構上，從而影響了業務的叠代效率。他們本可以把這些寶貴的時間用在業務的開發上，更好地支持業務的增長。

運維復雜 / 系統穩定性

每個數據產品都存在不足之處，都有各自潛在的問題。因此，運維需要與每個產品逐一磨合，深入理解並學會如何規避這些問題。任何一個產品出現問題都可能影響系統的穩定性。除了單個產品的穩定性問題，這種架構往往需要數據同步，這會進一步影響系統的穩定性：如果儲存某一份數據的產品（比如說 HBase）恰巧不能高效地支持某種查詢需求（比如說關鍵詞搜尋或語意搜尋），就需要透過同步任務把數據從一個產品同步到另一個產品，然後使用目標產品完成相應的查詢。數據同步往往是整個數據系統中最脆弱的環節之一，很容易影響系統的穩定性，一旦出現問題可能導致不同系統看到的數據不一致。

數據延遲

即便在數據同步沒有故障的情況下，也會存在同步延遲。即使透過各種最佳化讓延遲減少到平均僅一兩秒，但延遲可能會因為同步作業的熱點以及 failover 等原因出現不可控的毛刺。想象一下一個房東修改了自己民宿的內容，然後立刻以新的內容去搜尋自己的民宿卻因為偶發的延遲毛刺搜不到，這無疑給使用者帶來了不好的體驗。而要徹底解決這個問題，確保延遲永遠保持在很短的時間內幾乎是不可能的，業務上往往只能透過各種方式去減少其發生的機率。依賴大量數據同步的架構在互動式增刪改的場景很難提供好的體驗。

成本

業務的用量往往有波峰波谷，增長難以準確預測，除了按波峰提前購買所需硬體，為了應對突發流量，還需要額外預留一部份硬體，這些硬體的閑置帶來了一定的浪費。同時硬體資源分儲存、計算等多個維度，因為某個維度資源不夠增加機器可能會導致另外一個維度的資源浪費。

2 雲原生分布式 Data Warebase：資料庫與大數據的融合

那是否可能集眾產品之長，開發出一款能夠同時滿足上述需求的數據產品呢？我認為答案是肯定的，過去二十年技術的發展已經探索和解決了各個子問題，現在是綜合解決這些問題，大大降低數據使用門檻的時候了。

這樣一個產品具有以下幾個特征：

雲原生

部署和運維是數據產品很重要的一環，容器化能夠確保在不同的計算環境中有一致的執行行為，大大簡化產品在不同環境的部署和運維。透過 Kubernetes 排程這些容器，系統能夠根據流量的變化方便地擴縮容。透過使用儲存計算分離的架構，讓各個維度資源的擴縮容更加靈活，進一步最佳化資源利用，降低成本。

分布式

過去二十年數據產品的發展幾乎都在圍繞著解決一個問題，就是系統的水平擴充套件能力。只有分布式的系統才能徹底移除效能的天花板，滿足任何業務的效能需求。

Data Warebase

數據產品大體上可分為關系型資料庫、NoSQL 資料庫、搜尋引擎、向量搜尋和資料倉儲等幾類。「Data Warebase」這一術語融合了「資料倉儲（Data Warehouse）」和「資料庫（Database）」兩詞，用以概述一種集合了上述多類產品功能的產品。這類產品能同時滿足業務對不同數據儲存和計算能力的需求。

此時一個疑問自然浮現：這是否同時也意味著效能上的折衷？該系統是否在任一場景中都無法提供最優解？這是一個很好的問題，其核心在於這些功能之間是否存在根本的、不可調和的沖突，以及它們的組合是否產生協同效應，從而實作效能的疊加，使得整體的效果超過其部份的總和，實作 1 + 1 > 2。

以馬克士威方程式組為例

馬克士威是最偉大的理論物理學家之一，他將前人發現的電學和磁學的四個方程式放到一起，形成了著名的馬克士威方程式組。透過求解這個方程式組，馬克士威發現了電磁波，於是便有了光！這一合並過程雖看似簡單，卻促成了質的飛躍，孕育了超乎預期的新現象，這就是典型的 1 + 1 > 2 的場景。

（馬克士威方程式組）

透過把起源於不同場景的互補的數據技術融合在一起，不但能夠服務好這些場景本身，還能自然解決單個技術沒法很好解決的跨場景問題。這種融合的體驗將極大地降低業務使用數據的門檻，提升業務開發的效率，徹底解決數據延遲和不一致的問題，為數據產生業務價值提速！同時簡潔的業務數據架構將大大簡化運維，提升系統的穩定性。

3 構建雲原生分布式 Data Warebase 的要素

為什麽要把 Database 和 Data Warehouse 放在一起呢？我們先考慮一下反過來的問題：為什麽要把資料庫、搜尋、和數倉分開？從上面民宿 APP 的例子看到業務並沒有要求我們將這些系統分開，大家把它分為不同的產品實際上是受技術的限制。我們接下來先解釋一下技術上遇到的挑戰以及解決它們的方式。

1. 水平擴充套件能力

1.1 NoSQL 資料庫的優勢

要在關系型資料庫實作水平擴充套件是一個充滿技術挑戰的事情。但業務卻不能停滯發展，不會等待完美的技術方案出現，所以大家快速發展出了一系列能夠水平擴充套件的產品。NoSQL 資料庫就是當中的一類，它比較好地解決了水平擴充套件的問題，當然也對問題做了一些簡化和妥協。

接下來我們以 NoSQL 中使用廣泛的文件型資料庫為例分析其背後的一些思考。從單機走向分布式一個巨大的挑戰是分布式的事務，但是在一個特殊情況下事務的實作會得到極大的簡化，這就是單機事務的場景，也就是一個事務所有讀寫的記錄都恰好在一台機器的情況。我們可以在這種情況下采用類似單機資料庫的做法。但是在關系模型裏，業務上相關的數據會按照關系模型設計的三個範式分開儲存在多張表中，這就導致了業務的一次修改往往需要更新分布在多個表裏的多條數據，這些數據很可能分布在不同的機器上，因此關系模型限制了單機事務最佳化的適用場景。文件型資料庫的優勢這時候就發揮出來了，由於文件模型會把相關的數據組織成單個文件，很多業務場景只需更新單個文件，從而避免了多機事務的額外開銷。這種簡化使得文件型資料庫能夠較簡單地透過數據分片來實作水平擴充套件，從而滿足互聯網業務高速增長的效能需求，得到了較廣泛的套用。

（SQL VS NoSQL）

文件型資料庫另外一個優勢是儲存半結構化數據的能力，不同文件不必完全同構。比如說在描述民宿的設施時，冰箱可能有個欄位是容積，但是吹風機沒有這個欄位。這種靈活性使開發人員不再需要去找 DBA 修改表結構，進而提升了開發效率，成為敏捷開發一個很好的選擇。

1.2 關系型資料庫的優勢

既然文件模型有這麽多好處，我們是不是應該放棄關系模型而使用文件模型呢？在資料庫發展早期，類文件模型和關系模型曾經有過較量，結果是關系模型幾乎一統江湖。關系模型勝出的一個重要原因是它能較好地維持數據的一致性。

上文提到了關系模型設計的三個範式，它們從數據依賴的角度闡明了高效地組織數據並且避免重復的方式。開發者可以根據實體間的關系（一對一，一對多，或者多對多）設計表結構。文件模型可以嵌入一對一和一對多關系的實體，但對於多對多關系缺乏有效解決方案，可能導致數據重復儲存。 而數據一旦重復儲存保證它們的一致性就會成為一個挑戰， 業務程式碼在做修改時需要同時修改多份數據才能維持這種一致性，業務程式碼將變得更復雜。 更糟糕的是，需同時修改的數據可能分布於不同機器上，使單機事務最佳化不再適用。 為了在這種場景做到數據的一致性，分布式事務是一個任何系統都繞不過去的坎。 文件資料庫只在某些場景解決了數據組織的問題，而關系模型完整地解決這個問題。

文件模型因為沒有確定的表結構而能較容易地表達半結構化數據，但是這也是一把雙刃劍。這種情況類似於動態型別語言（如 JavaScript）與靜態型別語言（如 C++）之間的比較。動態型別語言不需預定義變量型別，易於上手，但在大型計畫中可能挑戰維護性。TypeScript 應運而生，並且在大型計畫中得到廣泛套用充分說明了這點。一些文件型資料庫也意識到了這個問題，透過讓使用者定義文件的模式（Schema），給文件內部的一致性提供了一定的保障。

除了文件內部的約束外，不同的數據實體間也可能存在一些約束。比如說關系型資料庫能夠透過外來鍵來維護實體間的一致性，這種功能在文件型資料庫中一般是缺失的，所以它們維持多文件間的數據一致性很困難。另外一個例子是唯一性二級索引，因為不支持分布式事務，跨節點的唯一性很難保證，所以這類系統往往要求唯一性二級索引包含分區鍵，這限制了它的適用場景。所以相比關系型資料庫，文件型資料庫對約束的支持比較弱，因此提供的數據完整性和一致性的保障也有差距。

除數據一致性優勢外，關系模型的另一強項是對 SQL 的支持，它允許將查詢的實作交由最佳化器處理，從而顯著提高開發效率。文件型資料庫因為不支持完整的 SQL，在查詢方面也面臨著一些挑戰。這類產品一般 Join 的能力都比較差或者不支持 Join。所以它們在涉及多個文件內容關聯的場景往往需要在業務端實作一些查詢邏輯。

1.3 NoSQL 和關系型資料庫的融合

NoSQL 資料庫因為率先解決了水平擴充套件的問題，以及其對敏捷開發模式的支持曾經紅極一時，甚至有人認為 NoSQL 才是資料庫的未來。但後續開發者也逐漸意識到了剛才提到的這些問題，所以 NoSQL 產品也開始吸收關系型資料庫的一些能力。這些發展甚至表現在 NoSQL 這個名字的解釋上。NoSQL 的首次提出在 1998 年，它最初的含義確實是「無 SQL」的意思，也就是 SQL 的反義詞。NoSQL 運動真正開始獲得關註是在 2009 年左右。在 2009 年一個討論非關系型資料庫的會議上這個名字被重新解釋為「Not Only SQL」，這個會議的原意是加倍下註，是想強調不僅不采用 SQL 作為查詢語言，也不采用關系模型的設計理念，徹底搞一套新的數據架構。NoSQL 也一度成為可以水平擴充套件和敏捷開發的代名詞。但是近年來一些 NoSQL 系統也開始實作分布式的事務（雖然並不建議在生產使用），同時也實作了部份 SQL 查詢語言。隨著關系型資料庫的這些能力被 NoSQL 產品吸收，NoSQL 又被大家解釋為「不僅僅是 SQL」，不再是 SQL 的反義詞，而是作為 SQL 的擴充套件。

過去的十來年，關系型資料庫產品也意識到了半結構化數據的重要性，開始引入 JSON 或者 JSONB 型別去表達半結構化數據，比如 PostgreSQL 有著非常完善的 JSON 支持。使用者可以在任何一張表裏引入 JSON 列，一個 JSON 列對應於文件型資料庫裏的一個文件。關系型資料庫突然有了文件資料庫靈活表達半結構化數據的能力。除了簡單的欄位提取外，還引入了 JSON Query（包含 JSON PATH QUERY）這種強大的查詢語言，能夠非常方便查詢和操作 JSON 數據。有了這些擴充套件後關系型資料庫在數據模型和查詢能力上已經是 NoSQL 資料庫的超集，有著更靈活高效的數據組織和查詢能力。我們看到關系模型和文件模型並不是一個互斥的關系，透過引入 JSON 型別的增強版關系模型，我們能夠在一個產品裏同時得到這兩種模型的好處。

（水平擴充套件）

解決了數據模型融合的問題後，剩下的就是水平擴充套件的問題了。上文已經解釋了除了使用數據分片技術外，分布式事務是任何一個想完全保證數據一致性的分布式產品都繞不過去的坎，實作它的挑戰也是巨大的，我們只能直面它解決它。好在 Spanner 的論文很好地展示了如何在一個關系型資料庫實作外部一致性的分布式事務。有了分布式事務後就能提供關系型資料庫完整的功能了。這些功能包含了外來鍵、全域唯一性二級索引等，給數據一致性和完整性提供全面的保證。Spanner 雖然是一個非常復雜的分布式資料庫，但它把復雜留給了自己，使用者使用時如同使用單機關系型資料庫一樣簡單，甚至更強大。這種易用性使得 Spanner 在 Google 內部取得了極大的成功。

無論是 NoSQL 資料庫還是關系型資料庫在實作分布式事務上遇到的挑戰是類似的。同時引入了 JSON 型別的關系型數據產品也能夠和 NoSQL 資料庫一樣地支持好可以被最佳化為單機事務的場景，所以這種新型的分布式關系型數據產品完全包含了 NoSQL 資料庫的優點。

2. 搜尋

最簡單的查詢模式是根據某個鍵值去找到相應的記錄（點查），這是傳統的關系型資料庫非常擅長且高效的場景。為了提升這類查詢的效能，關系型資料庫引入了二級索引的功能，使用二級索引可以根據索引鍵值直接定位到相關記錄，從而大大加速查詢。比如我們可以為民宿表建立一個民宿名字的索引，這樣就能夠快速地從名字找到相應的民宿。

稍微復雜一點的查詢需要根據多個欄位做過濾（搜尋）。二級索引在這類場景有一定的局限性。因為只有當查詢條件是索引鍵的字首時二級索引才能較好地發揮作用，所以針對不同的查詢模式可能需要建立不同的二級索引。在查詢模式固定並且較少情況，可以透過一個或者多個二級索引加速這些查詢。但是在一些業務場景查詢模式很靈活甚至事先不能完全確定。比如說除了按照名字尋找民宿外，使用者可能需要按照房間的價格，設施等多種條件的組合去尋找民宿。這些搜尋條件的組合會隨著可能檢索欄位的個數增加而指數級增加。如果我們為每種可能的查詢模式建立一個二級索引，所需建立的二級索引數量也會指數級增加。這些二級索引除了占用儲存空間外，還會增加每一次數據增刪改操作所帶來的維護索引的成本，建立大量的二級索引會變得不可行。

（倒排索引）

搜尋引擎使用了倒排索引的技術來解決這個問題，這種索引把欄位對映到包含它的文件列表（倒排鏈）。這些倒排鏈可以高效地做集合操作（比如求交集，聯集等）。倒排索引的技術在全文搜尋領域套用比較廣泛，但是其原理對結構化 / 半結構化數據的查詢一樣適用。我們只需對可能檢索的欄位建立單個欄位的倒排索引，就可以透過多個倒排鏈的集合操作去加速這些欄位的聯合過濾。

在分布式系統中，索引分區方式對查詢效能會有較大的影響。常見有兩種可能的方式：一是按照索引欄位的值去分區，好處是給定一個要尋找的欄位值能夠定位到確定的分區，所以單欄位的查詢非常高效，但是多個欄位的聯合查詢就需要對分布在多台機器的倒排鏈進行集合操作了，這對效能會產生比較大的影響。第二種方式是把數據和其對應的索引放在同一個分區。這種方式下即使單欄位的檢索也會需要尋找多個分區，所以單欄位的檢索效率沒有第一種方式高。但是好處是多欄位的聯合檢索能夠在分區內高效地完成倒排鏈的集合操作。所以為點查最佳化的二級索引往往采取第一種方式，而為靈活搜尋最佳化的倒排索引通常采用第二種方式。

這種倒排索引和分區技術在 Elastic 等產品中實作並且得到了廣泛的套用，這些技術很容易被分布式關系型資料庫吸收，使其具備高效的全文檢索和對結構化 / 半結構化數據搜尋的能力。

3. 向量搜尋

在過去的兩年中，基於 Transformer 架構的大語言模型取得了突飛猛進的發展，極大地推動了自然語言處理、影像辨識以及音視訊內容的理解和生成。如何有效地利用這些模型的能力，特別是在私域數據上的套用，已經成為了一個極其關鍵的議題。檢索增強型生成模型（RAG）提供了一種創新的解決方案，它巧妙地將資料庫或搜尋引擎的查詢能力與生成式人工智慧技術結合起來。例如，要回答一個自然語言問題，我們首先使用資料庫或搜尋引擎尋找與之相關的記錄。這些初步篩選的結果隨後輸入到大模型，讓大模型在理解了這些記錄的基礎上給出高品質的回答。

除了可以利用前文提到的全文檢索和結構化檢索能力，還發展出了一種基於嵌入（Embedding）的檢索模式。Embedding 檢索透過為每條記錄計算出一個高維嵌入向量，並利用這些向量的距離或內積來衡量它們在語意上的關聯度或相似度，從而實作了一種基於向量的檢索方法。在使用自然語言查詢的時候，我們可以為問題本身計算出一個高維嵌入向量，然後尋找與這個向量相似向量對應的文件。

（向量搜尋）

為了便於在系統中儲存和處理這些高維向量，我們可以引入向量數據型別，這樣便可以輕松地保留下這些記錄的嵌入表示。然而，當記錄數量極大時，從數億條記錄中快速尋找到與特定向量相似度高的向量將會是一個效能挑戰。為了高效能地實作這一點，索引這些向量就顯得尤為重要。目前常見的向量索引型別包括 IVFFlat 和 HNSW。那些整合了高維向量型別和索引功能的關系型資料庫，是針對這一挑戰很好的解決方案。相比專業的向量資料庫，引入了向量型別的關系型數據產品門檻更低，還能夠同時使用基於關鍵詞的全文檢索，結構化 / 半結構化數據的檢索，以及基於語意的向量檢索進行聯合查詢，這是分開的任何單一產品都不具有的能力。

4. 分析

傳統的數倉設計用於復雜的查詢和分析，其儲存的數據是相對靜態的，往往透過每天一次的方式匯入，不用考慮並行事務的問題，所以在數據寫入的事務處理上可以大大簡化，比如可以透過鎖表的方式來實作。因為在白天沒有數據匯入，所以查詢也不用擔心被寫入事務卡住。但是隨著業務對數據即時性要求的提高，出現了即時數倉的需求。數據需要持續不斷地即時匯入系統，同時我們希望查詢在這個過程中不會被阻塞。簡單粗暴地以鎖表方式去匯入數據顯然不再能滿足這個需求。多版本控制（MVCC）是解決這類讀寫沖突的一個有效的辦法。每條寫入的數據都會帶上寫入的時間戳，一條數據的多個版本在一段時間內會在系統共存。讀的時候可以選擇一個不再會有新寫入的時間戳，這樣就可以獲得對應於該時間戳的完整的快照。在這個快照上做各種復雜的分析查詢就不會被寫入阻塞。這種多版本控制的技術已經被很多資料庫產品所使用，比如說上文提到的 Spanner，同樣的技術也可以用在即時數倉裏。

因為數倉場景的數據量巨大，如果這些海量的數據需要即時寫入，就會需要海量的事務。高吞吐的分布式事務是個有挑戰的問題，可能給系統帶來一定的額外開銷，這也是大家（包括我自己）曾經一度認為資料庫和數倉必須分開的原因之一。我們在此深度剖析一下數倉場景的寫入問題。數倉場景的寫入模式主要有兩種：一種是批次匯入大量數據，如完全替換表中數據；另一種是逐條即時寫入，盡管可能透過批次處理實作更新，但本質上每條記錄都是獨立事務。幸運的是這兩種寫入模式都有最佳化的空間。第一類寫入模式雖然數據量巨大，但是事務數很少，所以基本不用擔心分布式事務所帶來的額外開銷，因為它和寫入這麽多數據帶來的計算量相比可以忽略不計。而第二類寫入模式每條數據可以當作一個獨立的事務，這讓前面提到的單機事務最佳化成為可能，因此也不需要承擔分布式事務帶來的額外成本。只要能為這兩類場景做針對性的最佳化，就能在一個產品中支持好數倉的海量數據寫入。

（行式儲存 VS 列式儲存）

現代數倉的一個秘訣是采用了列儲存，搜尋引擎透過建立倒排索引解決了多個欄位聯合過濾的問題，在分析類查詢中，我們可能還需要對某些列做快速的聚合。如果數據以傳統的行式儲存，這意味著單個列的聚合就需要把所有數據都讀取一遍，系統會因為讀取很多不必要的數據導致查詢變得很慢。而如果我們以列的方式去組織儲存，把同一列所有行的數據存在一起，無需讀取額外數據就能高效地實作這種聚合。同時有了高效讀取單列數據的能力後，還可以在沒有倒排索引的情況下實作高效的過濾。此外因為同一列的不同行數據有較高的相似性，這使得高效的編碼和壓縮成為可能，從而進一步減少讀取數據所需的 IO 量進而提升查詢的效能。除了儲存外，要完全發揮列存的優勢還依賴於向量化（ vectorized ） 的查詢引擎。 當然列存和向量化查詢並非在所有場景都最優，在需要讀取少量整行數據的場景，行存和行處理可能是更好的選擇。 但是我們也可以把行存和列存結合使用，讓最佳化器在查詢時根據具體的場景選擇使用最合適的儲存和處理方式。

（預聚合）

預計算也是數倉的一個常見最佳化，這類預計算包含總和、平均值、計數、最大值 / 最小值等一系列指標，這些聚合好的數據儲存在系統中，以便快速存取和分析，減少查詢的計算量，從而加快查詢響應時間。這些單表的預計算可以很好地用索引去抽象和實作。更加復雜一些的涉及到多個表的預計算邏輯也可以透過物化檢視去抽象。這些物化檢視可以透過手工或者系統自動去重新整理。

4 開啟創新之門

現在我們理解了各個技術創新點，構建一個全新的技術就水到渠成了。

1. 技術融合

我們可以看到各種產品都采用了一系列技術去最佳化相應的場景，這些最佳化包括：

如同電學和磁學的方程式一樣，雖然它們起源於不同的場景，但是這些技術並不沖突，完全可以在一個產品裏同時采用：

2. 體驗

剛才在馬克士威的例子裏我省略了一個重要的細節：他不是簡單地把四個相容的方程式放在一起形成一個方程式組。他註意到了電磁感應沒有相對應的磁效應，缺乏對稱性而不夠優美，就順手在方程式組裏做了一個「小」修改，給最後一個方程式加了一項位移電流。正是這個修改，解決了方程式組和電荷守恒定律沖突的問題。也正是因為這個修改，才產生了電磁波！

（位移電流）

簡單地把這一系列技術都在一個產品中實作是不夠的，如果使用者需要為不同的場景做大量的調參，產品還是會給使用者帶來割裂的體驗。為了去掉這些參數，系統必須做好自適應。上面提到了幾個最佳化的例子：最佳化器根據查詢決定使用行存還是列存，決定是不是可以使用預計算數據；系統根據是不是單機事務去做一階段送出的最佳化。但是真正要把體驗做好，這些還遠遠不夠，從儲存、記憶體管理、到並行控制等系統的方方面面都需要為自適應而設計，而不是把自適應當作一種事後的最佳化。這種能力如馬克士威的同位移電流，它將各個數據產品中的點狀的能力融合在一起，打破了場景的邊界，提供了一個全新的產品體驗。

當各種場景都在使用同一個產品的時候，不同工作負載間的隔離就變得尤為重要。隔離的實作可以透過軟體層次的軟隔離，感興趣的讀者可以參考 的文章。隔離也可以透過資源層的硬隔離去實作，也就是把需要隔離的不同請求用不同的計算節點去完成。但有時候在同一份數據上有不同的工作負載需要隔離，儲存計算分離的架構能夠允許不同的計算節點讀取同一份儲存而方便地實作這種隔離。當然除了隔離外，儲存計算分離的架構也為高效利用資源快速擴縮容帶來了很多好處。

我們正見證著數據產品一場深刻的變革。過去二十年間，整個行業都在致力於提高效能，以滿足業務不斷增長的需求。然而， 現在效能的提升已不再是主導變革的力量 。隨著效能問題的逐漸解決，它已轉變為一項基本的、必備的要求，不再構成業務發展的主要阻礙。隨著這一基礎需求的廣泛滿足，使用者對產品的更深層次需求開始顯現，那就是對體驗的追求。未來， 數據產品的成功將越來越依賴於提供卓越的使用者體驗——這將成為區分各類產品的決定性標準 。

5 數據開發的新範式

這時候，我們終於擁有了一種全新的數據產品 – 雲原生分布式 Data Warebase。這類新產品的問世標誌著數據管理的返璞歸真，它的設計理念是以滿足業務需求為核心，無論是數據儲存還是檢索，單一的產品就能全面覆蓋。這正本著業務驅動的原則，使使用者能夠真正地使用數據、享受產品，而不再受困於和眾多數據產品的賽局。

這種新範式將極大地簡化業務數據架構，使用者無需把自己的業務切割為資料庫場景、NoSQL 場景、搜尋場景和數倉場景。使用分布式 Data Warebase 時，數據的使用門檻大大降低。使用者將體驗到系統自適應力帶來的極致簡化的產品體驗，讓數據的潛能得以更簡單、更直接地釋放，從而極大地提升業務的靈活性。

采納新範式並不意味著要求使用者去學習全新的技術。這類數據產品可以設計為與成熟的關系型資料庫（例如 PostgreSQL）相容，借此利用其強大的生態。這種做法讓使用者幾乎不需要學習就能使用新技術，既能享受到新技術帶來的優勢，又無需離開他們已經熟悉和信賴的技術環境。

讓我們回顧一下文章開頭提到的民宿 APP，業務從未要求過應使用多種數據產品，那為何開發者的第一直覺是把數據的需求分解成多種場景，然後為每個場景選擇相應的數據產品呢？這是因為過去二十年間出現的各類數據產品都有其局限性，這些局限性不斷向使用者灌輸一個理念：不同的場景必須用不同的產品來解決。

我記得曾看過一個視訊，一個小女孩第一次看到紙質雜誌時，她嘗試用雙指放大內容。幾次失敗後，她終於意識到：雜誌不過是一部壞掉的 iPad！也許，終有一天我們會認識到：現行的數倉或資料庫實際上都是能力不完整的 Data Warebase！

作者簡介

蔣曉偉（ProtonBase 小質科技）

活動推薦

我們能否讓數據計算變得像資料庫一樣簡便易用且穩定？數據處理鏈路是否還能更簡潔高效？資料庫和大數據兩者是否能夠融為一體？在 4 月 11-13 日舉辦的 QCon 全球軟體開發大會（北京站）中，ProtonBase 小質科技技術 VP 金曉軍擔任「資料庫與大數據融合之路」專題出品人，並將分享【Cloud Native Distributed Data Warebase 資料庫與大數據的統一技術】，期待與你一起深入探討資料庫與大數據領域的交匯點，深刻了解如何有效結合二者的力量以驅動 AI 時代更靈活、高效、即時的數據洞察與決策。

目前會議 8 折優惠報名倒計時最後 2 周，掃碼添加小助手了解會議詳情：17310043226，點選 「閱讀原文」 即可了解大會全部專題。

今日好文推薦