DuckDB полезен тем, что ломает интуицию про обязательный отдельный аналитический кластер. Иногда правильный ход действительно в том, чтобы принести OLAP прямо к коду и данным.
В инженерной практике эта глава помогает увидеть, когда embedded-аналитика рядом с приложением, ноутбуком или локальным пайплайном дает больше скорости, чем тяжелая централизованная инфраструктура, особенно при работе с Parquet и CSV.
На интервью и в архитектурных обсуждениях она хорошо работает как пример зрелого ограничения: DuckDB ускоряет анализ и эксперименты, но не пытается притворяться универсальной заменой распределенной аналитической платформы.
Практическая польза главы
Embedded analytics boundary
Используйте DuckDB там, где нужна локальная аналитика рядом с приложением или notebook без отдельного кластера.
File-native workflows
Проектируйте пайплайны на Parquet/CSV с минимальным копированием данных и прозрачной воспроизводимостью.
Переход в прод-контур
Заранее определяйте, в какой момент локальные аналитики должны мигрировать в shared warehouse.
Interview articulation
Показывайте DuckDB как инструмент для speed-of-analysis, а не как универсальную замену распределенной аналитики.
Источник
Wikipedia: DuckDB
История проекта DuckDB и позиционирование как in-process OLAP СУБД.
Официальный сайт
DuckDB
Официальная документация, релизы, SQL-функциональность и интеграции с экосистемой данных.
DuckDB - in-process аналитическая СУБД с SQL-интерфейсом и vectorized execution. В системном дизайне её часто используют как embedded OLAP слой для локальной аналитики, ELT и работы с файлами data lake (Parquet/CSV), когда не нужен отдельный серверный кластер.
История и контекст
Публичный старт проекта
DuckDB появляется как open-source in-process OLAP движок для аналитики внутри приложения и ноутбуков.
Подготовка к 1.0
Линия 0.10.x расширяет SQL-возможности и performance-профиль перед стабильной 1.x веткой.
Стабильный мажорный релиз
Проект фиксирует стабильную 1.0 линию с фокусом на совместимость формата хранения и production-использование.
Развитие 1.x ветки
Продолжаются улучшения оптимизатора, SQL-функций и интеграций с аналитической экосистемой.
Стабилизация LTS-линии
LTS-ветка усиливает предсказуемость апгрейдов и поддержку production-сценариев с длинным циклом релизов.
Ключевые архитектурные элементы
In-process архитектура
DuckDB работает как библиотека в процессе приложения: без отдельного DB-сервера и сетевого hop между кодом и движком.
Vectorized SQL execution
Запросы выполняются батчами в pipeline-операторах, что ускоряет scan-heavy OLAP workload на одном узле.
Columnar storage + open formats
Колонночное хранение и прямой доступ к Parquet/CSV/Arrow делают DuckDB удобным SQL-слоем для data lake файлов.
ACID и concurrency ограничения
Есть ACID/MVCC/WAL, но модель конкурентной записи ориентирована на один writer process для файла БД.
Execution и storage модель
Ниже интерактивный разбор модели DuckDB: in-process deployment, vectorized engine, storage layout, транзакционность и ограничения по конкурентной записи.
Execution и storage модель DuckDB
DuckDB совмещает in-process deployment, vectorized execution и колонночное хранение, поэтому закрывает аналитические сценарии без отдельного серверного кластера.
Почему DuckDB — это отдельный класс аналитической СУБД
- Движок работает внутри процесса приложения, что снижает operational overhead для аналитики.
- Vectorized execution и columnar storage оптимизируют scan-heavy OLAP запросы.
- Есть ACID транзакции, WAL и checkpoint, но concurrency-модель ориентирована на один writer process.
- DuckDB нативно работает с Parquet/CSV/Arrow и подходит для embedded ELT/аналитики.
In-process deployment
DuckDB запускается как библиотека внутри приложения (Python/R/CLI/BI), без отдельного DB server процесса.
Ключевые элементы
Типичные сценарии
- Notebook analytics
- Local BI
- Application-side data processing
Пример
import duckdb
con = duckdb.connect('warehouse.duckdb')High-Level Architecture
Схема показывает high-level контур DuckDB: клиентский embedding, SQL/optimizer слой, vectorized execution pipeline, storage subsystem и экосистемные интеграции.
System view
Performance profile
Operational trade-offs
Read / Write Path через компоненты
Диаграмма объединяет write и read path: от SQL-команды клиента через optimizer и vectorized execution до записи в storage или возврата аналитического результата.
Read/Write Path Explorer
Интерактивный разбор прохождения DuckDB-команд через SQL planner, vectorized execution и storage слой.
Write path
- DuckDB оптимизирован под bulk-запись (`COPY`, батчевый `INSERT`, `CTAS`) в одном процессе.
- План записи проходит optimizer и исполняется vectorized операторами батчами.
- Транзакции ACID + WAL/`CHECKPOINT` обеспечивают durability в persistent режиме.
- Схемы с индексами/constraints повышают integrity, но могут замедлить массовую загрузку.
Когда выбирать DuckDB
Хорошо подходит
- Embedded аналитика в приложении, notebook и локальных BI-инструментах.
- ELT/EDA-пайплайны по Parquet/CSV/JSON без подъёма отдельного кластера.
- Feature engineering и ad-hoc аналитика рядом с Python/Pandas/Polars.
- Оффлайн и edge-сценарии, где важны простота доставки и минимальный operational overhead.
Стоит избегать
- Многопользовательский OLTP-сервис с интенсивными concurrent writes из разных процессов/нод.
- Требование к распределённому кластеру с автоматическим failover и горизонтальным масштабированием хранилища.
- Системы с высокой потребностью в row-level locking и длинных конкурентных транзакциях.
- Сценарии, где нужен постоянный удалённый DB endpoint для множества независимых сервисов.
Практика: DDL и DML
Ниже примеры SQL-операций в DuckDB: DDL для схемы/индексов и DML для ingest, трансформаций и аналитических запросов.
Примеры DDL и DML в DuckDB
DDL описывает схему/индексы, DML управляет загрузкой и аналитическими запросами.
DuckDB использует классический SQL DDL: таблицы, constraints, индексы, схемы и ATTACH для работы с несколькими БД-файлами.
Создание аналитических таблиц и ограничений
CREATE TABLEDDL задаёт структуру и базовые правила целостности данных.
CREATE TABLE users (
user_id BIGINT PRIMARY KEY,
plan VARCHAR,
created_at TIMESTAMP
);
CREATE TABLE events (
event_id BIGINT,
user_id BIGINT,
event_type VARCHAR,
event_ts TIMESTAMP,
payload JSON,
FOREIGN KEY (user_id) REFERENCES users(user_id)
);Индекс для селективных фильтров
CREATE INDEXИндексы в DuckDB полезны для точечных/селективных условий, но не всегда нужны для scan-heavy аналитики.
CREATE INDEX idx_events_user_ts
ON events (user_id, event_ts);ATTACH и создание витрины в отдельной схеме
ATTACH + CREATE SCHEMA/TABLEМожно держать raw и mart-слои в отдельных attached БД и схемах.
ATTACH 'warehouse.duckdb' AS wh;
USE wh;
CREATE SCHEMA IF NOT EXISTS mart;
CREATE TABLE mart.daily_events AS
SELECT DATE(event_ts) AS dt, event_type, count(*) AS cnt
FROM events
GROUP BY 1, 2;Связанные главы
- Database Selection Framework - Как определить, когда embedded OLAP-подход DuckDB даёт лучший баланс скорости, стоимости и простоты эксплуатации.
- ClickHouse: аналитическая СУБД и архитектура - Сравнение embedded и distributed OLAP: где достаточно локального движка, а где нужен отдельный аналитический кластер.
- PostgreSQL: история и архитектура - Паттерн OLTP + embedded analytics: когда транзакционный контур остаётся в PostgreSQL, а аналитика уходит в DuckDB.
- Как устроены системы хранения данных - Контекст по типам хранилищ и компромиссам, который помогает правильно позиционировать DuckDB внутри общего data-стека.
- ETL/ELT и архитектура data pipeline - Практика локального ELT поверх Parquet/CSV/JSON и интеграции DuckDB в batch/near-real-time пайплайны.
- YDB: distributed SQL база данных и архитектура - Разделение ролей между distributed OLTP-платформой и embedded OLAP-слоем в гибридных архитектурах.
