“大資料”已死——現今我們最重要的事情不是擔心資料大小，而是專注于我們将如何使用它來做出更好的決策。
資料庫行業發展至今，在資料層面有很多的加速和變革，尤其是過去幾年的雲數倉爆炸式增長，帶來了行業的很多變化。毫無疑問，雲資料倉庫已成為企業資料堆棧的基石，各種規模的公司群組織習慣使用資料倉庫來分析業務資料。Snowflake 的迅速崛起就是這一趨勢的典型代表。
但如果我們把大資料的變量拆成速度、數量和多樣性三個次元，我們發現大家最關注的次元仍然是速度。當我們重新審視對“大資料”的定義，并且結合資料資産的要素，我們最重要的需求是從 OLTP [1] 資料庫處理的資料資産上的微服務對低延遲消耗的要求。
與此同時，很多大資料部門購買了所有新工具并從遺留系統遷移之後，他們發現仍然無法去了解這些資料，也許資料大小根本不是問題所在。世界的資料量變大了，但硬體也以更快的速度變大了，供應商仍在推動硬體的能力擴充。今天我們就來聊一家有點“不一樣”思路的資料庫創業公司——MotherDuck，看看他們的産品 DuckDB 是如何來了解這個世界的。
曆史沿革：歐美合作的商業化産物
說起 MotherDuck 的前世今生，首先還是要從産品 DuckDB 講起。DuckDB 是一個專門建構的程序内線上分析處理資料庫管理系統，其旨在實作高效資料分析。從 2019 年 DuckDB 第一個開源版本釋出，到 2021 年，短短兩年間，DuckDB 的周下載下傳量增長迅速。此時，這個原本由荷蘭數學和計算機科學研究學會 (CWI) 創立的項目被分拆出來獨立運作，項目研究人員 Hannes Mühleisen 和 Mark Raasveldt 成立了 DuckDB Labs。
故事至此，為什麼 MotherDuck 還未出現呢？别急，我們還缺少另一位主角——谷歌 Big Query 的創始工程師 Jordan Tigani，他也關注着 DuckDB，并一直尋求為市場提供輕型資料庫産品。在和 DuckDB Labs 的聯合創始人 Mühleisen 溝通并獲得支援後，Tigani 開始嘗試将開源的 DuckDB 商業化。新公司 MotherDuck 就此誕生，并獲得了由紅點資本(美國) 領投的 1250 萬美元天使輪融資和 A16Z 領投 3500 萬美元 A 輪融資，公司估值 1.75 億美元。
回頭來看，作為一家起步時間不長的初創公司，獲得這樣的資本認可不可謂不成功。由于 DuckDB 并非 MotherDuck 的原創開源産品，是以，想要未來長久且穩定地基于開源産品建構服務，得到項目創始團隊的支援至關重要。
在雙方的合作中 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 所處象限
認知：資料庫行業的“非共識”
與行業大部分公司不同，MotherDuck 擁有不一樣的行業信仰。
首先，Tigani 認為大多數客戶群組織的資料存儲适中，并不大。同時，客戶資料大小服從幂律分布。最大客戶的存儲量是第二大客戶的兩倍，第三大客戶的存儲量是第二大客戶的一半，依此類推。是以，雖然有客戶擁有數百 PB 的資料，但大小很快就會下降。
其次，存算分離中存在存儲偏差，資料大小增速快于計算。假如業務是靜态的，既不增長也不收縮，資料随時間線性增長，但計算需求不會改變太多，因為大多數分析都是針對近期資料進行的。這種存算偏差，讓我們可能根本不需要進行分布式處理。而且，很多使用者希望他們的問題得到簡單快速的答案 —— 他們不想等待雲。
最後，大多數資料很少被查詢。得到處理的資料中，有很大一部分不到 24 小時。到資料儲存一周時，查詢的可能性或許比最近一天低 20 倍。曆史資料往往很少被查詢，這也就意味着資料工作集大小比我們預期的易于管理。如果有一個包含 10 年資料的 PB 表，這些資料最後可能被壓縮至不到 50 GB。是以，很多雲廠商專注于 100TB 的查詢性能，這可能不僅與大多使用者無關，且會分散他們提供出色使用者體驗的能力。
是以，MotherDuck 提出了自己的觀點，大資料是真實存在的，但大多數人可能不需要擔心。“大資料”已死——現今我們最重要的事情不是擔心資料大小，而是專注于我們将如何使用它來做出更好的決策。我們也會時常問自己，組織真的會生成大量資料嗎？如果生成了，真的需要一次使用大量資料嗎？如果需要，資料真的太大而無法放在一台機器上嗎？也許不同的組織會給出不同的答案。
大資料已死
未來：沒有“銀彈”，沒有萬能的選擇
我們目前所處的時代高速變化，産生了很多資料庫管理系統。正如我們看到的情況，目前這個世界還沒有萬能的資料庫管理系統。大家都會采取不同的權衡取舍，以更好地适應特定的用例，DuckDB 也是如此。有時我們需要側重考慮為多個并發使用者提供服務，有時我們也需要一個對單使用者工作負載非常快的嵌入式資料庫。
DuckDB 會成功嗎？答案也許并不确定。不過我們确實看到了一個充滿活力的開源社群正在形成，雖然還未有任何商業化的資訊披露，但我們應有耐心給予這個 A 輪公司，畢竟故事才剛剛開始。
DuckDB 在 Github 的 star 數量變化
注釋:
[1] OLTP：On-Line Transaction Processing 聯機事務處理過程，也稱為面向交易的處理過程。
[2] OLAP：Online Analytical Processing 聯機分析處理。聯機分析處理 OLAP 是一種軟體技術，它使分析人員能夠迅速、一緻、互動地從各個方面觀察資訊，以達到深入了解資料的目的。
作者簡介
鄭博，Aka Harbour 哈博。崔牛會非著名牛油，人到中年的 2B 基礎架構創業老炮，CnosDB 雲原生時序資料庫開源社群發起人。
CnosDB簡介
CnosDB是一款高性能、高易用性的開源分布式時序資料庫，現已正式釋出及全部開源。
歡迎關注我們的社群網站：https://www.cnosdb.com