Происхождение: CWI, Mark Raasveldt и Hannes Mühleisen, SIGMOD 2019, DuckDB Labs

Большинство популярных инструментов данных выросли из инженерных команд крупных компаний: Spark — из AMPLab Беркли и Databricks, Kafka — из LinkedIn. DuckDB вырос из другого места — из академической исследовательской лаборатории, причём из той самой, где двадцатью годами раньше изобрели технику, на которой DuckDB и построен. Это редкий и показательный случай.

Понимать происхождение DuckDB полезно не из любопытства. Корни в исследовательской группе по архитектуре баз данных объясняют, почему DuckDB устроен именно так: почему у него векторизованный движок, почему упор на storage-формат и сжатие, почему движок написан «до железа». Это не случайные инженерные решения — это прямое наследие конкретной научной школы, и зная это наследие, вы будете воспринимать внутренности движка осмысленно, а не как разрозненный набор фактов.

В этом уроке — кто, где и когда создал DuckDB, и почему место рождения определило его архитектуру. Мы пройдём по цепочке: институт CWI и его исследовательская группа, два автора движка, академическая публикация на SIGMOD, выделение компании DuckDB Labs — и в конце соберём, как каждый из этих фактов проявляется в сегодняшнем DuckDB.

CWI: где это всё началось

DuckDB создан в Centrum Wiskunde & Informatica (CWI) — Национальном исследовательском институте математики и информатики Нидерландов, в Амстердаме. CWI — старое и заметное место: именно там в начале 1990-х Гвидо ван Россум создал язык Python.

Внутри CWI есть Database Architectures group — исследовательская группа, десятилетиями занимающаяся одной темой: как строить системы баз данных, которые выжимают максимум из современного железа. Не «как добавить ещё одну SQL-фичу», а «как устроить движок, чтобы он эффективно использовал кэши процессора, конвейеры, SIMD, память».

Эта группа — не новичок в аналитических СУБД. Из неё вышел MonetDB — одна из первых колоночных аналитических СУБД, исследовательский проект, ставший важной вехой в истории column-store систем. Когда мы говорим, что DuckDB создан в CWI, важен именно этот контекст: это лаборатория с многолетней школой проектирования аналитических движков «до железа». DuckDB — её прямое продолжение.

Стоит зафиксировать, чем такое происхождение отличается от происхождения «инженерного». Многие инструменты данных рождались в продуктовых командах крупных компаний, решавших свою конкретную бизнес-задачу. Это даёт инструмент, отточенный под реальную нагрузку, но иногда — с компромиссами «лишь бы поскорее работало». Происхождение из исследовательской группы даёт другое: глубину. Для научной группы движок — это ещё и предмет изучения, площадка для проверки идей о том, как СУБД должна быть устроена. Поэтому в DuckDB внутренние решения — раскладка данных, схемы сжатия, модель исполнения — это не «первое, что заработало», а результат осознанного выбора между альтернативами, многие из которых группа исследовала десятилетиями. Когда дальше в курсе мы будем разбирать storage-формат или алгоритмы сжатия, за каждым решением будет стоять эта исследовательская проработка.

Авторы: Mark Raasveldt и Hannes Mühleisen

У DuckDB два создателя, оба из Database Architectures group CWI.

Hannes Mühleisen — исследователь CWI, к моменту создания DuckDB уже опытный человек в области систем баз данных, связанный с группой и её работами. Mark Raasveldt — на старте проекта PhD-студент CWI, чья диссертационная работа была связана с архитектурой аналитических систем.

Идея, из которой вырос DuckDB, была практической. Исследователям и аналитикам данных постоянно нужно было выполнять аналитические SQL-запросы прямо внутри своих рабочих сред — R, а позже Python — над данными в памяти. Существующие инструменты не подходили. Клиент-серверная аналитическая СУБД — это тяжело: поднять сервер, настроить, гонять данные туда-сюда через сеть. SQLite встраивается легко, но это OLTP-движок, на аналитике он медленный. Нужного инструмента — встраиваемого, как SQLite, но аналитического — просто не существовало.

Raasveldt и Mühleisen решили его построить. Так появился DuckDB: in-process аналитическая СУБД, «SQLite для аналитики», задуманная как недостающий инструмент для людей, которые работают с данными в R и Python.

Важно отметить, что DuckDB строился не на пустом месте, а опираясь на накопленный группой исследовательский багаж. Database Architectures group десятилетиями изучала, как устроить аналитический движок «до железа»: как организовать колоночное хранение, как сжимать данные, как исполнять запросы, чтобы процессор работал эффективно. Когда авторы взялись за DuckDB, у них уже были и проверенные идеи (та же векторизация), и понимание, какие решения работают, а какие нет. DuckDB стал способом собрать это знание в один практичный, доступный всем инструмент. Этим он отличается от проекта, который начинают «с чистого листа»: за ним стоит научная традиция, и это видно в качестве его внутренней инженерии.

Стоит также понимать выбор формы. Авторы могли бы сделать ещё одну исследовательскую систему «для статей» — такую, которой пользуются в основном сами исследователи. Вместо этого они с самого начала строили DuckDB как инструмент, удобный обычному инженеру и аналитику: простой в установке, с хорошим SQL, тесно интегрированный с Python и R. Сочетание исследовательской глубины внутри и практичной, дружелюбной оболочки снаружи — сознательное решение, и именно оно сделало DuckDB не нишевым академическим проектом, а массовым инструментом.

SIGMOD 2019: академическая публикация

DuckDB вырос из исследовательской среды, и у него есть «свидетельство о рождении» в академической форме. В 2019 году Raasveldt и Mühleisen представили demo-статью «DuckDB: an Embeddable Analytical Database» на конференции SIGMOD.

SIGMOD (ACM Special Interest Group on Management of Data) — одна из двух главных мировых научных конференций по системам баз данных. Demo-статья на SIGMOD — это короткая публикация, представляющая работающую систему, а не одну изолированную идею.

Само название статьи — точное определение проекта: embeddable (встраиваемая) и analytical (аналитическая). Эти два слова, заявленные ещё в 2019 году, остаются исчерпывающим описанием DuckDB и сегодня. Первый публичный релиз DuckDB состоялся в 2019 году — параллельно с академической презентацией.

Полезно осознать, что значит эта стабильность определения. Многие инструменты за годы развития «уплывают» от исходного замысла: начинались как одно, а под давлением пользователей и рынка превратились в другое. С DuckDB этого не произошло. То, чем он был заявлен в 2019 году — встраиваемая аналитическая СУБД — он и есть в 2026 году. За прошедшие годы движок колоссально вырос: появились новые типы данных, lakehouse-форматы, шифрование, десятки расширений. Но всё это росло внутри исходной рамки «embeddable analytical», не ломая её. Это признак того, что замысел был точным с самого начала: авторы сразу правильно определили нишу, и развитие шло вглубь этой ниши, а не в сторону от неё.

Есть и более общий смысл академической публикации. Demo-статья на SIGMOD означает, что систему рассматривали и обсуждали специалисты по базам данных — на конференции такого уровня работа проходит через рецензирование коллегами. То есть DuckDB с самого начала был не «ещё одним инструментом с GitHub», а проектом, заявленным и оценённым в профессиональном сообществе исследователей баз данных. Это часть его репутации и одна из причин доверия к качеству его внутренней инженерии.

DuckDB Labs: спин-офф из CWI

Открытый исследовательский проект — это хорошо, но у успешного движка появляются пользователи, а у пользователей — потребность в стабильности, поддержке и предсказуемом развитии. Исследовательская группа университета по своей природе не заточена под коммерческую поддержку продукта.

Поэтому в июле 2021 года Raasveldt и Mühleisen основали DuckDB Labs — отдельную компанию, выделенную (spin-off) из CWI. Её задача — развивать DuckDB, обеспечивать коммерческую поддержку и держать проект устойчивым.

Важно понимать модель. DuckDB Labs — это компания за проектом, но сам DuckDB остаётся полностью открытым под лицензией MIT. DuckDB Labs не «владеет» закрытой версией; движок свободен. Компания зарабатывает на поддержке и связанных продуктах (например, MotherDuck строится в партнёрстве с DuckDB Labs). Это распространённая и здоровая модель open-source: открытое ядро плюс компания, которая отвечает за его развитие.

Стоит пояснить, почему университетская исследовательская группа плохо подходит на роль долгосрочного хранителя популярного продукта. Цель научной группы — исследования и публикации; её ресурсы, найм, отчётность устроены под это. Поддержка продукта — отвечать на запросы пользователей, выпускать релизы по расписанию, исправлять ошибки в проде, давать гарантии стабильности — это другая деятельность, требующая другой организации. Пока DuckDB был небольшим проектом, его можно было вести внутри группы. Но по мере роста числа пользователей возник конфликт: поддержка требовала всё больше ресурсов, которых у научной группы под эту задачу нет. Спин-офф разрешил конфликт — вынес продуктовую часть в компанию, оставив за CWI исследования.

Спин-офф 2021 года и релиз DuckDB 1.0 в июне 2024 — две важные вехи зрелости. Спин-офф дал проекту организационную опору; 1.0 означал стабилизацию storage-формата и API — сигнал, что DuckDB готов для серьёзного production-использования. Номер версии 1.0 здесь не маркетинг: до него storage-формат и API ещё могли меняться между релизами, а 1.0 зафиксировал обещание стабильности — на такую базу уже можно опираться в продакшене, не опасаясь, что следующий релиз сломает совместимость. К моменту этого курса DuckDB прошёл далеко за 1.0 — актуальны версии линии 1.5 и LTS-линия 1.4.

Почему происхождение определило архитектуру

Соберём нить. DuckDB создан в исследовательской группе CWI, чья многолетняя специализация — аналитические СУБД, спроектированные «до железа». Это объясняет три фундаментальные черты движка.

Первое — векторизованное исполнение. Это техника, разработанная в той же группе CWI (о ней — следующий урок). DuckDB не «вдохновлялся» векторизацией со стороны; он построен людьми из лаборатории, которая её и придумала.

Второе — глубина проработки внутренностей. Storage-формат, схемы сжатия, morsel-driven параллелизм — у DuckDB всё это сделано на уровне исследовательского state of the art, а не «лишь бы работало». Это естественно для движка, выросшего из научной группы: для неё движок — ещё и платформа исследований.

Третье — встраиваемость и фокус на R/Python. DuckDB задуман для аналитиков и исследователей, работающих с данными локально. Отсюда in-process архитектура и zero-copy интеграция с Python-стеком — не побочные удобства, а сердцевина замысла.

Поэтому происхождение — не справка для эрудиции. Это ключ к тому, почему остальные модули курса выглядят именно так: глубокое погружение в векторизацию, storage-формат, сжатие и параллелизм — прямое следствие того, кем и где DuckDB был создан. Изучая эти внутренности дальше, держите в голове происхождение: вы изучаете не «случайные технические детали», а воплощение конкретной исследовательской школы проектирования аналитических СУБД.

Попробуй сам

Прочитайте первоисточники и сопоставьте их с тем, что вы уже знаете о DuckDB.

1. Найдите demo-статью «DuckDB: an Embeddable Analytical Database» (SIGMOD 2019) — она доступна в открытом доступе. Прочитайте хотя бы аннотацию (abstract). Обратите внимание, что цель и позиционирование, описанные в 2019 году, совпадают с тем, чем DuckDB является сейчас.
2. Откройте анонс спин-оффа на сайте DuckDB Labs (https://duckdblabs.com/news/, запись от июля 2021) и прочитайте, как сами авторы объясняют, зачем понадобилась отдельная компания.
3. Сформулируйте письменно: какие три архитектурные черты DuckDB напрямую объясняются его происхождением из исследовательской группы CWI? Сверьте свой ответ с последним разделом урока.