圖片來源 @視覺中國
文 | 牛透社，作者 | 鄭博
數據庫行業發展至今，在數據層面有很多的加速和變革，尤其是過去幾年的雲數倉爆炸式增長，帶來了行業的很多變化。毫無疑問，雲數據倉庫已成爲企業數據堆棧的基石，各種規模的公司和組織習慣使用數據倉庫來分析業務數據。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 是一種軟件技術，它使分析人員能夠迅速、一緻、交互地從各個方面觀察信息，以達到深入理解數據的目的。
更多精彩内容，關注钛媒體微信号（ID：taimeiti），或者下載钛媒體 App
