數據庫行業發展至今，在數據層面有很多的加速和變革，尤其是過去幾年的云數倉爆炸式增長，帶來了行業的很多變化。毫無疑問，云數據倉庫已成為企業數據堆棧的基石，各種規模的公司和組織習慣使用數據倉庫來分析業務數據。Snowflake 的迅速崛起就是這一趨勢的典型代表。

但如果我們把大數據的變量拆成速度、數量和多樣性三個維度，我們發現大家最關注的維度仍然是速度。當我們重新審視對“大數據”的定義，并且結合數據資產的要素，我們最重要的需求是從 OLTP [1] 數據庫處理的數據資產上的微服務對低延遲消耗的要求。

【資料圖】

與此同時，很多大數據部門購買了所有新工具并從遺留系統遷移之后，他們發現仍然無法去理解這些數據，也許數據大小根本不是問題所在。世界的數據量變大了，但硬件也以更快的速度變大了，供應商仍在推動硬件的能力擴展。今天我們就來聊一家有點“不一樣”思路的數據庫創業公司——MortherDuck，看看他們的產品 DuckDB 是如何來理解這個世界的。

歷史沿革：歐美合作的商業化產物

說起 MortherDuck 的前世今生，首先還是要從產品 DuckDB 講起。DuckDB 是一個專門構建的進程內在線分析處理數據庫管理系統，其旨在實現高效數據分析。從 2019 年 DuckDB 第一個開源版本發布，到 2021 年，短短兩年間，DuckDB 的周下載量增長迅速。此時，這個原本由荷蘭數學和計算機科學研究學會 (CWI) 創立的項目被分拆出來獨立運作，項目研究人員 Hannes Mühleisen 和 Mark Raasveldt 成立了 DuckDB Labs。

故事至此，為什么 MortherDuck 還未出現呢？別急，我們還缺少另一位主角——谷歌 Big Query 的創始工程師 Jordan Tigani，他也關注著 DuckDB，并一直尋求為市場提供輕型數據庫產品。在和 DuckDB Labs 的聯合創始人 Mühleisen 溝通并獲得支持后，Tigani 開始嘗試將開源的 DuckDB 商業化。新公司 MortherDuck 就此誕生，并獲得了由紅點資本 (美國) 領投的 1250 萬美元天使輪融資和 A16Z 領投 3500 萬美元 A 輪融資，公司估值 1.75 億美元。

回頭來看，作為一家起步時間不長的初創公司，獲得這樣的資本認可不可謂不成功。由于 DuckDB 并非 MortherDuck 的原創開源產品，因此，想要未來長久且穩定地基于開源產品構建服務，得到項目創始團隊的支持至關重要。

在雙方的合作中 DuckDB 團隊一定程度上參與了 MotherDuck，而 MotherDuck 又是 DuckDB 基金會的成員，該非營利組織擁有 DuckDB 的大部分知識產權。DuckDB 自己的商業部門 DuckDB Labs 是 MotherDuck 的股東。不得不說 Tigani 與 DuckDB Labs 合作是聰明之舉，通過此舉，雙方利益得以綁定。

定位：OLAP 領域的 SQLite

要聊 DuckDB，我們先來看看 SQLite，其可以稱得上世界上使用最多的關系型數據庫系統，我們幾乎在每臺手機、每個瀏覽器和操作系統上都能找到它的身影，它甚至也在飛機上運行。

由于 SQLite 是嵌入式的，因此其不需要外部服務器管理。同時，他幾乎綁定了每種語言，也正是基于這些特點，讓其更容易使用，我們必須承認 SQLite 的偉大。但與此同時，其問題也突出。SQLite 是為 OLTP 而設計的，采用行存儲，不能利用內存來加快計算速度，查詢優化器非常有限，所以對于分析來說非常不友好。

正是基于此，DuckDB 看到了機會。簡單來講，它是用于分析 (OLAP 領域 [2] ) 的 SQLite，作為一個進程內數據庫，它使開發人員、數據科學家、數據工程師和數據分析師能夠使用純 SQL 以極快的分析能力為它的代碼提供支持。此外，它有能力在可能存在的地方分析數據，例如在筆記本電腦或云端。

DuckDB 使用了一個列式矢量化查詢引擎，該引擎仍會解釋查詢，但會在一次操作中處理大量向量，由此減少傳統系統 (如 PostgreSQL、MySQL 或 SQLite) 中按順序處理每一行的開銷，提升查詢性能。

SQLite 是小型的關系型數據庫，可用于進程內的部署。

DuckDB 所處象限

認知：數據庫行業的“非共識”

與行業大部分公司不同，MortherDuck 擁有不一樣的行業信仰。

首先，Tigani 認為大多數客戶和組織的數據存儲適中，并不大。同時，客戶數據大小服從冪律分布。最大客戶的存儲量是第二大客戶的兩倍，第三大客戶的存儲量是第二大客戶的一半，依此類推。因此，雖然有客戶擁有數百 PB 的數據，但大小很快就會下降。

其次，存算分離中存在存儲偏差，數據大小增速快于計算。假如業務是靜態的，既不增長也不收縮，數據隨時間線性增長，但計算需求不會改變太多，因為大多數分析都是針對近期數據進行的。這種存算偏差，讓我們可能根本不需要進行分布式處理。而且，很多用戶希望他們的問題得到簡單快速的答案 —— 他們不想等待云。

最后，大多數數據很少被查詢。得到處理的數據中，有很大一部分不到 24 小時。到數據保存一周時，查詢的可能性或許比最近一天低 20 倍。歷史數據往往很少被查詢，這也就意味著數據工作集大小比我們預期的易于管理。如果有一個包含 10 年數據的 PB 表，這些數據最后可能被壓縮至不到 50 GB。所以，很多云廠商專注于 100TB 的查詢性能，這可能不僅與大多用戶無關，且會分散他們提供出色用戶體驗的能力。

因此，MortherDuck 提出了自己的觀點，大數據是真實存在的，但大多數人可能不需要擔心。“大數據”已死——現今我們最重要的事情不是擔心數據大小，而是專注于我們將如何使用它來做出更好的決策。我們也會時常問自己，組織真的會生成大量數據嗎？如果生成了，真的需要一次使用大量數據嗎？如果需要，數據真的太大而無法放在一臺機器上嗎？也許不同的組織會給出不同的答案。

未來：沒有“銀彈”，沒有萬能的選擇

我們目前所處的時代高速變化，產生了很多數據庫管理系統。正如我們看到的情況，目前這個世界還沒有萬能的數據庫管理系統。大家都會采取不同的權衡取舍，以更好地適應特定的用例，DuckDB 也是如此。有時我們需要側重考慮為多個并發用戶提供服務，有時我們也需要一個對單用戶工作負載非常快的嵌入式數據庫。

DuckDB 會成功嗎？答案也許并不確定。不過我們確實看到了一個充滿活力的開源社區正在形成，雖然還未有任何商業化的信息披露，但我們應有耐心給予這個 A 輪公司，畢竟故事才剛剛開始。

DuckDB 在 Github 的 star 數量變化

注釋:

[1] OLTP：On-Line Transaction Processing 聯機事務處理過程，也稱為面向交易的處理過程。

[2] OLAP：Online Analytical Processing 聯機分析處理。聯機分析處理 OLAP 是一種軟件技術，它使分析人員能夠迅速、一致、交互地從各個方面觀察信息，以達到深入理解數據的目的。

關鍵詞： 數據倉庫 olap sqlite