Recap is_incremental() + философия incremental

Этот модуль — самый сложный в курсе. Incremental models на dbt I вы видели на базовом уровне: «если данные большие, ставим materialized=‘incremental’». На production-масштабе всё сложнее: четыре разных стратегии, тонкие гарантии каждой, специфические gotchas, performance-trade-offs на миллиардах строк. Этот урок — короткий recap основ и философия, на которой строятся следующие четыре урока модуля.

Recap в одной таблице

Это базовый минимум — детали и edge cases следующих уроков предполагают эти знания.

Философия incremental: когда нужен и когда нет

Incremental не «всегда лучше table». У него есть стоимость:

Правила, когда нужен incremental:

1. Таблица большая — 10M+ строк, табличный run занимает заметное время (минуты+).
2. Дельта маленькая — на каждый run новых строк меньше 10% существующих.
3. Есть watermark — колонка типа created_at, по которой можно отличать новое от старого.
4. Хочется частых runs — каждые 15 минут или чаще.

Правила, когда НЕ нужен incremental:

1. Таблица маленькая — менее 1M строк, table run меньше 10 секунд. Overhead incremental не окупится.
2. Дельта большая — на каждый run меняется 30%+ строк. Incremental тут медленнее, чем table.
3. Нет watermark — нельзя надёжно определить, что новое. Можно делать full сравнение, но это та же table.
4. Backfill частый — если каждый месяц меняется логика, и нужно пересчитать всё, table проще.

Production-цифры

Конкретные числа из реальных проектов 2024-2026:

• Маленькая таблица (1M строк): table run на DuckDB локально — 1-2 секунды. Incremental — те же 1-2 секунды (overhead на проверку, что таблица существует). Выигрыш нулевой.
• Средняя (50M строк): table run — 30-60 секунд. Incremental (1M дельты) — 2-5 секунд. Выигрыш 10-30x.
• Большая (1B+ строк): table run — 10-30 минут на Snowflake medium warehouse, $5-15 за run. Incremental (5M дельты) — 30-60 секунд,$0.10-0.30 за run. Выигрыш 50-100x по compute, 30-50x по cost.
• Огромная (10B+ строк): table run — часы, десятки долларов. Incremental — 2-5 минут, $0.50-2. Выигрыш 100x+.

На production-цифрах incremental — единственный способ работать с большими таблицами в разумные сроки и бюджеты.

Стратегии — что покрывает этот модуль

Этот модуль (02) разберёт append, delete+insert, merge. Microbatch — отдельный модуль (03). insert_overwrite не покрываем подробно (warehouse-specific и редкий случай).

DuckDB-specific

На DuckDB поддержаны:

• append — работает.
• delete+insert — работает.
• merge — DuckDB 1.4+. На 1.3 и старее — config error. Если у вас DuckDB 1.3 (или dbt-duckdb старее 1.10.0), merge не доступен.
• microbatch — dbt-core 1.9+. Работает без unique_key (по дизайну, не баг).

В production на Snowflake/BigQuery все стратегии работают без version-ограничений.

Жизненный цикл incremental-модели

Гарантии и риски incremental

Главные риски incremental в production:

1. Дубли — append без unique_key проинсертит ту же строку дважды, если её источник прислал повторно.
2. Пропущенные строки — фильтр created_at > max(created_at) пропустит строку с late-arriving timestamp (событие случилось вчера, но пришло сегодня — фильтр отсечёт).
3. Дрейф схемы — добавление колонки в source может тихо игнорироваться incremental-моделью (есть on_schema_change параметр для управления).
4. Race conditions — два dbt run одновременно могут вставить одни и те же строки дважды.
5. Forgotten full-refresh — изменили бизнес-логику в модели, забыли запустить full-refresh — историческая часть таблицы осталась со старой логикой.

Каждый из этих рисков мы разберём в этом и следующем модулях с конкретными решениями.

Когда incremental — это плохо

Иногда команды переусердствуют с incremental:

• «Везде incremental, потому что быстрее» — на 100 маленьких моделях incremental добавляет сложность без выигрыша. Профайлинг покажет, что table вообще норм.
• «Incremental на dimension-таблице» — dim_customers обычно маленькая, и обычно полностью пересчитывается (изменилось всё, что угодно). Incremental тут — overhead.
• «Incremental без unique_key на не-append логике» — гарантированные дубли, и в первый production-инцидент это заметит downstream.

Правило: по умолчанию table или view, incremental только когда профайлинг показал, что table не выдерживает. Это контр-интуитивно для junior, но это правильная философия для middle.

Framework выбора стратегии

После того как профайлинг подтвердил «table не выдерживает», следующий вопрос — какую из четырёх стратегий выбрать. Decision tree:

В реальных проектах распределение примерно: 40% merge, 30% append (логи и события), 20% delete+insert (legacy Postgres), 10% microbatch (heavy backfills). Если у вас перекос в сторону одной стратегии — это сигнал либо технологического outlier (вся компания на Postgres), либо что команда не пробовала альтернативы.

Что дальше в этом модуле

• 02-append.mdx — append стратегия, immutable logs use case, no-dedup workflow.
• 03-delete-insert-merge.mdx — delete+insert vs merge, deep dive, когда какая.
• 04-incremental-predicates.mdx — incremental_predicates для оптимизации MERGE, DBT_INTERNAL_DEST trick.
• 05-lookback-and-late-arriving.mdx — паттерн lookback, late-arriving data.

После этого модуля вы будете уметь выбирать правильную стратегию для конкретной задачи и понимать trade-offs.

Попробуй сам

В своём проекте проверьте:

1. Сколько у вас incremental-моделей? (Скрипт: find models -name "*.sql" -exec grep -l "materialized='incremental'" {} \;)
2. Для каждой запишите: размер таблицы (rows), время table-run, время incremental-run. Если разница меньше 5x, возможно incremental не нужна.
3. Найдите incremental-модели без unique_key. Если стратегия не append — это потенциальный баг с дублями.
4. Запустите dbt run --full-refresh для одной из incremental-моделей. Засеките время. Если это > 30 минут — у вас будет проблема при backfill.