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

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

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

歷史沿革：歐美合作的商業(yè)化產物

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

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

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

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

定位：OLAP 領域的 SQLite

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

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

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

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

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

DuckDB 所處象限

認知：數(shù)據(jù)庫行業(yè)的“非共識”

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

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

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

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

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

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

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

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

DuckDB 在 Github 的 star 數(shù)量變化

版權說明：
本文僅代表作者個人觀點，版權歸原創(chuàng)者所有。部分圖片源自網絡，未能核實歸屬。本文僅為分享，不為商業(yè)用途。若錯標或侵權，請與我們聯(lián)系刪除。

本文僅代表作者觀點，版權歸原創(chuàng)者所有，如需轉載請在文中注明來源及作者名字。

免責聲明：本文系轉載編輯文章，僅作分享之用。如分享內容、圖片侵犯到您的版權或非授權發(fā)布，請及時與我們聯(lián)系進行審核處理或刪除，您可以發(fā)送材料至郵箱：service@tojoy.com