ClickHouse и dbt: что реально даёт связка и где она трётся

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

Факты — из анонса ClickHouse (16 сентября 2026), README адаптера ClickHouse/dbt-clickhouse и документации. Разбор мой.

Что именно вышло

Путаница в заголовках возникает потому, что речь сразу о трёх разных вещах:

То есть работающий адаптер существует пятый год. Новое — поддержка нового поколения dbt и появление ClickHouse в управляемой платформе, куда пока пускают по заявке.

Зачем это нужно

Коротко для тех, кто с dbt не работал. dbt превращает построение витрин в инженерную дисциплину: SQL-модели лежат в git, зависимости между ними выводятся автоматически, к данным пишутся тесты, документация генерируется из кода.

Без него типичная аналитическая обвязка ClickHouse — это набор скриптов, поднимающих материализованные представления, и устный договор о том, в каком порядке их запускать. С dbt это превращается в граф зависимостей с проверками.

Что поддерживает адаптер:

• материализации: table, view, incremental, microbatch, materialized view, dictionary, ephemeral;
• экспериментально — distributed-варианты таблиц и инкрементальных моделей;
• seeds, sources, snapshots, контракты, тесты (включая модульные), генерация документации.

Самое ценное: настройки ClickHouse прямо в модели

Вот что делает адаптер не формальной галочкой, а рабочим инструментом. В части 5 серии про ClickHouse я разбирал, что производительность определяется схемой: порядком сортировки, партиционированием, кодеками, TTL. Всё это объявляется в самой модели:

{{ config(
    materialized='table',
    engine='MergeTree',
    order_by=['event_type', 'user_id', 'ts'],
    partition_by='toYYYYMM(ts)',
    ttl='ts + INTERVAL 1 YEAR DELETE'
) }}

select
    event_type,
    user_id,
    ts,
    amount
from {{ ref('raw_events') }}

Поддерживаются и настройки на уровне колонок (кодеки, TTL), и табличные (индексы пропуска, проекции).

Практический смысл: решения, определяющие скорость запросов, лежат в git рядом с SQL, проходят ревью и воспроизводятся при пересоздании. Не «кто-то когда-то выбрал ORDER BY в консоли», а строчка в коде с историей изменений.

Где связка трётся

Честная часть. dbt родом из мира хранилищ, где UPDATE и DELETE дёшевы. В ClickHouse это не так.

Инкрементальные модели — главная точка трения. Классический сценарий dbt: пересчитать только новые данные и обновить существующие строки по ключу. Стратегия delete+insert реализует это удалением и повторной вставкой — а в ClickHouse удаление превращается в мутацию, то есть переписывание целых кусков данных. На больших таблицах это дорого и долго (см. часть 5).

Отсюда практические выводы:

• append там, где это возможно. ClickHouse устроен как append-only хранилище, и модель, которая только дописывает, работает с ним в одну сторону, а не против.
• Дедупликацию отдавайте движку. ReplacingMergeTree схлопывает дубли при слиянии — это дешевле, чем удалять их запросом. Помните только, что схлопывание происходит когда-нибудь, а не сразу.
• Микробатчи вместо частых мелких прогонов. Каждый запуск модели — это вставка; частые мелкие вставки ведут к too many parts (часть 6). Лучше реже и крупнее.
• Есть настройка use_lw_deletes, переключающая поведение на лёгкие удаления, — но и они не бесплатны, а лишь дешевле полноценных мутаций.

Второе ограничение: интеграции каталогов (например, Iceberg), появившиеся в dbt 1.10, адаптером нативно пока не поддерживаются — есть обходные пути.

Насколько это готово

Цифры из анонса, и они говорят сами за себя:

• адаптер v2 проходит 81% полного набора интеграционных тестов dbt;
• из тестов, применимых к ClickHouse Cloud, — 92%;
• прямо сказано: не готово для продакшена, бета-тестирование только на dev и staging;
• паритет по возможностям с адаптером v1 ещё достигается.

Формулировка «не для прода» здесь не ритуальная оговорка. Если вы строите витрины сейчас — берите v1-адаптер, он GA и живёт пятый год. К v2 стоит присматриваться и тестировать на стенде, а доступ к платформе запрашивать, если управляемый вариант вам действительно нужен.

Кому стоит смотреть

Да, если у вас уже есть ClickHouse и набор скриптов, поднимающих витрины: dbt заменит их графом зависимостей с тестами, а настройки схемы переедут в git.

Да, если команда уже работает с dbt на другом хранилище — переиспользуете и инструменты, и привычки.

Не спешите, если у вас пара материализованных представлений, которые никто не трогает месяцами. dbt — это ещё один инструмент в конвейере со своей кривой обучения, и ради двух витрин он не окупится.

И главное, что стоит держать в голове при переходе: не переносите привычки из Snowflake или BigQuery механически. Там UPDATE — обычная операция, здесь — дорогая. Модели, спроектированные как append-only, будут работать в разы быстрее тех, что построены вокруг обновления строк.