System Design Space
Граф знанийНастройки

Обновлено: 3 мая 2026 г. в 23:23

DuckDB: встроенная аналитическая СУБД и архитектура

средний

Встроенная аналитическая СУБД: работа внутри процесса, векторизованное выполнение, колоночное хранение, транзакции, Parquet/CSV-интеграции и локальные файловые конвейеры.

DuckDB полезен тем, что ломает привычку сразу поднимать отдельный аналитический кластер. Иногда правильный ход — выполнить аналитику прямо рядом с кодом и файлами.

В инженерной практике эта глава помогает увидеть, когда встроенная аналитика рядом с приложением, локальной средой разработки или файловым конвейером быстрее и проще централизованной инфраструктуры.

На интервью и в архитектурных обсуждениях она хорошо работает как пример зрелого ограничения: DuckDB ускоряет анализ и эксперименты, но не заменяет распределённую аналитическую платформу.

Практическая польза главы

Граница встроенной аналитики

Используйте DuckDB там, где нужна локальная аналитика рядом с приложением или рабочей средой без отдельного кластера.

Файл-ориентированные процессы

Проектируйте пайплайны на Parquet/CSV с минимальным копированием данных и прозрачной воспроизводимостью.

Переход в прод-контур

Заранее определяйте, когда локальная аналитика должна перейти в общее аналитическое хранилище.

Аргументация на интервью

Показывайте DuckDB как инструмент быстрого анализа, а не как универсальную замену распределённой аналитики.

Источник

Wikipedia: DuckDB

История проекта DuckDB и его позиционирование как встроенной аналитической СУБД.

Открыть статью

Официальный сайт

DuckDB

Официальная документация, релизы, SQL-функциональность и интеграции с экосистемой данных.

Открыть сайт

DuckDB - встроенная аналитическая СУБД с SQL-интерфейсом и векторизованным выполнением. В системном дизайне её часто используют для локальной аналитики, файловых конвейеров и работы с Parquet/CSV, когда отдельный серверный кластер только усложняет решение.

В этой главе под понимаем движок, который живёт рядом с приложением, скриптом или ноутбуком. DuckDB закрывает на локальных данных, а не пытается заменить удалённую транзакционную СУБД.

Архитектурно важны , , , , и ограничение на .

История и контекст

2019early releases

Публичный старт проекта

DuckDB выходит как открытый аналитический движок для приложений, ноутбуков и локальных сценариев без отдельного сервера.

13 февраля 2024v0.10.0

Подготовка к 1.0

Линия 0.10.x расширяет SQL-возможности и улучшает профиль производительности перед стабильной веткой 1.x.

3 июня 2024v1.0.0

Стабильный мажорный релиз

Проект фиксирует стабильную линию 1.0 с фокусом на совместимость формата хранения и боевые сценарии.

9 сентября 2024v1.1.0

Развитие 1.x ветки

Продолжаются улучшения оптимизатора, SQL-функций и интеграций с аналитической экосистемой.

27 января 2026v1.4.4 (LTS)

Стабилизация LTS-линии

LTS-ветка усиливает предсказуемость обновлений и поддержку сценариев с длинным циклом сопровождения.

Ключевые архитектурные элементы

Архитектура внутри процесса

DuckDB работает как библиотека в процессе приложения: без отдельного сервера СУБД и сетевого перехода между кодом и движком.

Векторизованное выполнение SQL

Запросы выполняются пакетами в конвейерных операторах, что ускоряет крупные аналитические сканы на одном узле.

Колоночное хранение и открытые форматы

Колоночное хранение и прямой доступ к Parquet/CSV/Arrow делают DuckDB удобным SQL-слоем поверх файлов озера данных.

Транзакции и ограничения записи

Есть транзакции и журнал предзаписи, но запись в файл базы данных рассчитана на один процесс записи.

Модель выполнения и хранения

Ниже интерактивный разбор модели DuckDB: встраиваемый режим, векторизованное выполнение, устройство хранения, транзакционность и ограничения конкурентной записи.

Модель выполнения и хранения DuckDB

DuckDB совмещает работу внутри процесса, векторизованное выполнение и колоночное хранение, поэтому закрывает аналитические сценарии без отдельного серверного кластера.

Почему DuckDB — это отдельный класс аналитической СУБД

  • Движок работает внутри процесса приложения, что снижает операционную нагрузку для локальной аналитики.
  • Векторизованное выполнение и колоночное хранение оптимизируют крупные аналитические сканы.
  • Есть транзакции, журнал WAL и контрольные точки, но конкурентная запись ориентирована на один процесс записи.
  • DuckDB напрямую работает с Parquet/CSV/Arrow и подходит для встроенной файловой аналитики.

Работа внутри процесса

DuckDB запускается как библиотека внутри приложения (Python/R/CLI/BI), без отдельного серверного процесса СУБД.

Ключевые элементы

Встроенная библиотекаОдин файл БД или памятьЛокальная и периферийная аналитика

Типичные сценарии

  • Аналитика в ноутбуках
  • Локальный BI
  • Обработка данных рядом с приложением

Пример

import duckdb
con = duckdb.connect('warehouse.duckdb')

Архитектура DuckDB по слоям

Схема показывает общий контур DuckDB: клиентское встраивание, SQL-слой и оптимизатор, конвейер векторизованного выполнения, подсистему хранения и интеграции с экосистемой.

Клиенты и встраивание
Python/R/JS APICLI и shellBI/ноутбукиВстраивание в процесс
переход слоя
SQL и оптимизатор
Разбор и привязкаЛогический оптимизаторФизический планФильтры и соединения
переход слоя
Векторизованное выполнение
DataChunk + VectorКонвейерные операторыПараллельные сканыSIMD-пакеты
переход слоя
Хранение и ввод-вывод
Группы строкСжатиеWAL + контрольные точкиЧтение Parquet/CSV/JSON
переход слоя
Транзакции и надёжность
MVCCИзоляция снимкаОдин процесс записиТранзакции ACID
переход слоя
Расширения и экосистема
Фреймворк расширенийArrow/Pandas/PolarsUDF/UDAFLakehouse-сценарии

Системная роль

Встроенная аналитикаБез отдельного сервераЛокальные ELT-процессы

Профиль производительности

Векторизованное выполнениеКолоночные сканыБыстрая работа с Parquet

Компромиссы эксплуатации

Один процесс записиНе распределённая OLTP-СУБДСильна в аналитике

Пути записи и чтения через компоненты

Диаграмма объединяет путь записи и путь чтения: от SQL-команды клиента через оптимизатор и векторизованное выполнение до сохранения данных или возврата аналитического результата.

Пути записи и чтения

Интерактивный разбор прохождения DuckDB-команд через планирование SQL, векторизованное выполнение и слой хранения.

1
Команда клиента
INSERT COPY CTAS
2
Разбор и оптимизация
logical -> physical
3
Векторизованное выполнение
DataChunk конвейер
4
Транзакция и WAL
ACID + контрольная точка
5
Колоночное хранение
группы строк
Путь записи: команда проходит разбор и оптимизацию, выполняется пакетами, фиксируется через журнал WAL и попадает в колоночное хранение.

Путь записи

  1. DuckDB оптимизирован под массовую запись (`COPY`, пакетный `INSERT`, `CTAS`) в одном процессе.
  2. План записи проходит оптимизацию и исполняется векторизованными операторами пакетами.
  3. Транзакции, журнал WAL и `CHECKPOINT` обеспечивают сохранность в постоянном режиме хранения.
  4. Схемы с индексами и ограничениями повышают целостность, но могут замедлить массовую загрузку.

Когда выбирать DuckDB

Хорошо подходит

  • Встроенная аналитика в приложении, ноутбуке и локальных BI-инструментах.
  • Локальные конвейеры извлечения, загрузки и преобразования поверх Parquet/CSV/JSON без отдельного кластера.
  • Проектирование признаков и разовая аналитика рядом с Python/Pandas/Polars.
  • Офлайн- и периферийные сценарии, где важны простая доставка и низкая операционная нагрузка.

Стоит избегать

  • Многопользовательский транзакционный сервис с интенсивной записью из разных процессов или узлов.
  • Требование к распределённому кластеру с автоматическим переключением на резерв и горизонтальным масштабированием хранилища.
  • Системы, которым нужны блокировки на уровне строк и длинные конкурентные транзакции.
  • Сценарии, где нужен постоянный удалённый endpoint СУБД для множества независимых сервисов.

Практика: DDL и DML

Ниже примеры SQL-операций в DuckDB: DDL для схемы и индексов, DML для приёма данных, преобразований и аналитических запросов.

Примеры DDL и DML в DuckDB

DDL описывает схему и индексы, DML управляет загрузкой и аналитическими запросами.

DuckDB использует классический SQL DDL: таблицы, ограничения, индексы, схемы и ATTACH для работы с несколькими файлами БД.

Создание аналитических таблиц и ограничений

CREATE TABLE

DDL задаёт структуру и базовые правила целостности данных.

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 полезны для точечных и селективных условий, но не всегда нужны для крупных аналитических сканов.

CREATE INDEX idx_events_user_ts
ON events (user_id, event_ts);

ATTACH и создание витрины в отдельной схеме

ATTACH + CREATE SCHEMA/TABLE

Можно держать сырые данные и витрины в отдельных подключённых БД и схемах.

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;

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки