dbt Fusion: strategic context, история, почему Rust

В предыдущих 11 модулях вы разбирали dbt-core — Python-движок, существующий с 2016 года. Модуль 12 — про dbt Fusion, второй официальный движок dbt на Rust. Этот урок — strategic overview: зачем dbt Labs построил второй движок, как индустрия пришла к этой точке, и почему именно Rust. Технические детали (Rust крейты, SDF Lineage Format, ADBC, divergence patterns) — в уроках 02 и 03.

Сразу зафиксируем: dbt-core продолжает поддерживаться параллельно с Fusion (релизы 1.10 → 1.11 → 1.12 за 2025-2026). Fusion не заменяет dbt-core. Это структурное решение dbt Labs — два engineering tracks с разными tradeoffs.

dbt Fusion engine: Rust-based будущее dbt (dbt I)

Strategic context: путь dbt Labs к Fusion

dbt Labs (компания, не open source проект) к 2024 году имела стратегическую проблему: revenue ramp с dbt Cloud замедлялся, потому что core differentiation между dbt Cloud и self-hosted dbt-core размывалась. Кастомеры всё чаще выбирали Airflow + dbt-core над dbt Cloud, потому что:

dbt-core open source, дает достаточно функциональности для большинства команд.
Airflow orchestration зрелый, integration ecosystem огромный.
dbt Cloud premium фичи (Studio IDE, Explorer) воспринимались как «nice to have», не «must have».

Engineering тоже упирался в потолок: Python-implementation dbt-core имел реальные ограничения:

Parsing scaling: на проектах 1000+ моделей parse phase занимает 30-60 секунд. CI lag, IDE lag, dev iteration pain.
GIL constraint: parallelism через multiprocessing работает, но имеет overhead. True parallel parsing невозможен.
No semantic layer at compile-time: dbt-core рендерит Jinja в SQL string и отправляет в warehouse. Column-level lineage, type checking, static analysis — невозможны без отдельных tools (dbt-osmosis, sqlfluff).

К 2024 году dbt Labs понимал, что без architectural rethink ни IDE experience, ни enterprise positioning не улучшатся. Внутренний Python rewrite оценили как 3-5 лет engineering — нереалистично.

SDF Labs acquisition (январь 2025)

SDF Labs — стартап 2023 года, основанный

ex-Google инженерами

. Их продукт — Rust-based SQL semantic compiler с column-level lineage, type inference, multi-dialect support. Технология строилась для standalone SaaS (SDF Cloud).

dbt Labs увидел: у SDF готова именно та технология, которая нужна для Fusion. Acquisition January 2025 закрыла engineering gap — Fusion получил готовый Rust compiler с двумя годами разработки внутри.

Это важный нюанс: Fusion не написан dbt Labs с нуля. Это integration product: SDF Compiler + dbt-style Jinja front-end + dbt project structure / artifacts compatibility. Архитектурно SDF определил core, dbt Labs построил wrapper.

Coalesce 2025: Fusion GA + Fivetran merger

Coalesce 2025 (октябрь 2025) был watershed event для dbt экосистемы:

dbt Fusion 1.0 GA: после 5 месяцев public beta.
dbt-core 1.10: одновременный release, чтобы подчеркнуть continued support.
Fivetran + dbt Labs merger announcement: компании сливаются в одну entity, focusing на end-to-end ELT платформу.

Merger меняет industry landscape: Fivetran (Extract + Load) + dbt (Transform) теперь единая компания. Стратегически это означает:

Closer Fivetran ↔ Fusion integration: ожидайте native Fivetran sources в Fusion adapter ecosystem, schema discovery через Fivetran metadata API.
Unified pricing model: post-merger packaging skews towards bundled ELT subscriptions. Standalone dbt Cloud pricing может trasform к концу 2026.
Competitive response: Snowflake (с Snowpark/Cortex), Databricks (с Lakehouse + DLT), Google (с Dataform integrated в BigQuery) ускоряют свои dbt-alternative или dbt-compatible offerings.

dbt Labs позиционирует Fusion в этом контексте как technical foundation для long-term competitive differentiation. Без Fusion dbt Labs остаётся «open source company с premium SaaS», что не масштабируется в эпоху platform consolidation.

Хронология появления Fusion

От SDF Labs до Fusion GA: ключевые точки

2023-2024: SDF Labs строит Rust SQL semantic compiler

Январь 2025: dbt Labs acquires SDF Labs

Май 2025: dbt Fusion public beta

Октябрь 2025 (Coalesce): Fusion 1.0 GA + Fivetran merger

2026: Fusion и dbt-core развиваются параллельно

Источник acquisition детали:

dbt Labs и SDF Labs blog posts

, январь 2025.

Почему Rust

Выбор Rust как языка для Fusion — не «потому что hyped». Это инженерное решение, основанное на конкретных требованиях:

Требования к Fusion engine и почему Rust

Альтернативы, которые dbt Labs рассматривал и отверг:

Go: рассматривался для simpler concurrency model. Отвергнут потому что: garbage collector latency на LSP recompile non-trivial, type system менее expressive чем Rust enum/Result. Также SDF Labs уже на Rust.
C++: production-grade performance, но безопасность и build complexity. Modern C++ можно писать safely, но team velocity заметно ниже Rust для greenfield project.
TypeScript/Node: дискуссия была про LSP-only компонент (VS Code Extension мог быть Node). Отвергнуто — single language easier maintenance, plus performance not matching Rust для compiler-heavy workload.
Python с optimizations (Cython, Mypyc, codon): incremental improvements, но не fundamental change. Не решает GIL, не решает type safety. Хорошо для libraries, не для new engine.

Wes McKinney (co-founder SDF Labs, теперь dbt Labs) высказался публично на Coalesce 2025: «Rust был obvious choice. Python великолепен для libraries и user-facing logic, Rust великолепен для infrastructure foundations. dbt-core останется Python потому что user-facing, Fusion на Rust потому что infrastructure.»

Что Fusion меняет, что остаётся

Чтобы предотвратить misunderstanding, явная карта:

Меняется

Engine language: Python → Rust.
Parsing throughput: ~27x faster для большой codebase.
Compilation total: ~2-3x faster.
Internal lineage format: manifest.json → SDF Lineage Format (SLF) с column-level tracking. manifest.json всё ещё генерируется для compatibility.
Database transport: DBAPI/ODBC Python adapters → ADBC drivers (где доступны).
Static analysis capabilities: новый layer — type checking, column resolution, dead code detection.
IDE integration: dbt Power User extension → официальный dbt VS Code Extension через Fusion LSP.

Не меняется

dbt project structure: models/, tests/, macros/, seeds/, snapshots/, analyses/ — те же.
Jinja syntax: тот же. {% set %}, {{ ref() }}, {{ config() }}, {% if %}, {% for %}.
YAML schemas: dbt_project.yml, profiles.yml, schema.yml — те же ключи и semantics.
CLI command names: dbt run, dbt test, dbt build, dbt compile, dbt parse. Subcommands те же.
Adapter API concepts: materializations, dispatch, hooks работают идентично в API contract.
Artifacts schema: manifest.json, run_results.json, catalog.json — schema-compatible с dbt-core. Tooling экосистема (dbt-osmosis, Elementary, Datafold) работает без изменений.
Warehouse execution: Snowflake/BigQuery/Postgres compute time остаётся таким же. Fusion ускоряет всё до отправки SQL, не warehouse-side.

WARNING

Что Fusion НЕ ускоряет — это критично понимать: warehouse-side time. Если ваш dbt run занимает 30 минут, из которых 28.5 минут — Snowflake compute, Fusion даст 1-2 минуты экономии в parse/compile. End-to-end speedup ~5%, не «30x». Маркетинговые числа («30x parsing») точны но относятся к parse phase only — детали в уроке 03.

Что значит Fusion для индустрии в 2026

К концу 2026 года расклад примерно такой:

dbt-core остаётся reference implementation. Apache 2.0, community-driven contributions, baseline для всей экосистемы tooling (linters, CI integrations, observability). Большинство production deployments — всё ещё dbt-core.
Fusion takes adoption в local dev и CI fast paths. ~25-30% dbt Cloud customers используют Fusion для local dev по состоянию на Q2 2026 (per dbt Labs investor updates). Production migration медленнее — compatibility validation требует месяцев тестирования.
Adapter ecosystem bifurcation. Snowflake, BigQuery, PostgreSQL, DuckDB — Fusion-native ADBC. Databricks, Redshift — в beta. Trino, ClickHouse, Synapse, SQL Server — остаются на dbt-core или работают через Fusion с PyO3 shim (без full perf benefits).
Competing platforms accelerate. Snowflake Native Analytics App с Cortex AI, Databricks DLT (Delta Live Tables) с SQL transformations, Google Dataform integrated в BigQuery. Все позиционируют как «dbt без dbt» — embedded в их warehouse offering. dbt Labs контр-стратегия: Fusion + Fivetran merger для bundled E + L + T pitch.
License question: BSL для Fusion остаётся source of community debate. Часть discourse «dbt Labs commercializes core engine», часть — «это разумная business model». dbt-core’s continued Apache 2.0 status снижает критику, но not убирает её. Долгосрочно вопрос неясен — будет ли BSL расширен, конвертируется ли в Apache 2.0 через 4 года as planned.

Для senior дата-инженера в 2026: знание обоих движков — required skill. На interview вопросы про Fusion architecture, divergence patterns, migration strategy — стандартны. Команды, мигрирующие на Fusion, требуют людей, понимающих и dbt-core internals (для debugging legacy), и Fusion (для adoption decisions).

Проверка знанийKnowledge check

CTO middle-stage data startup пишет в ваш Slack: "мы выбираем между dbt-core и Fusion для greenfield проекта. На Snowflake, ожидаем 200 моделей к концу 2026. Команда из 4 человек: 2 SQL-engineers, 1 data engineer, 1 ML engineer. Что рекомендуете и почему?"

ОтветAnswer

Это nuanced decision, который зависит от deeper context, не just project size. Я бы задал вопросы и дал structured recommendation, не chosen answer. **Step 1: Gather дополнительный контекст.** Компания greenfield, но какой стек уже есть? - Какая CI infrastructure (GitHub Actions, GitLab, Buildkite)? - Какой orchestrator planned (Airflow, Dagster, dbt Cloud Jobs)? - Является ли dbt стандартом в company, или другие teams используют разные tools? - Budget для tools / licenses? - Open source vs commercial preference (важно для legal departament reviews)? Этот контекст определяет recommendation больше, чем technical merits engine. **Step 2: Honest technical assessment.** Для 200-моделей проекта на Snowflake: Fusion benefits: - Parsing 30s → 1s. На greenfield с rapid iteration — это reasonable дев experience improvement. - Column-level lineage из коробки. Полезно для documentation, debugging dependency chains. - IDE LSP — modern dev experience, similar к TypeScript LSP, Rust-analyzer. - Если планируется dbt Studio IDE (cloud-based) — Fusion required. Fusion risks: - BSL license. Если команда юридически чувствительна к non-OSS licenses (regulated industry, government, certain enterprises) — это hard block. - Divergence edge cases. На greenfield project меньше legacy macros, риск divergence ниже, но всё ещё non-zero. - Adapter ecosystem. Snowflake fully supported — ok. - Tooling maturity. Linters (sqlfluff), observability (Elementary), CI tools — некоторые ещё caught up с Fusion semantics. dbt-core benefits: - Battle-tested, 10 years production usage. - Apache 2.0 license — clean legal. - Full adapter ecosystem coverage. - Larger Stack Overflow / GitHub knowledge base. Команда из 4 человек больше benefits от mature community когда наталкивается на edge cases. dbt-core risks: - Slower IDE experience. На 200 моделей parse ~10 секунд, тоже acceptable но less ideal. - No native column-level lineage. Требует additional tooling (dbt-osmosis, BI tool). **Step 3: Recommendation structure.** Для 200-моделей greenfield team из 4 человек я бы рекомендовал hybrid: **Production runs**: dbt-core 1.11+ или 1.12. Stability, OSS, ecosystem maturity. На 200 моделей parsing overhead 10 секунд — приемлемо. **Local development**: Fusion для members команды, которые хотят. Free для individual use under BSL. Получают instant LSP feedback, column-level lineage в IDE. Производят manifest.json который dbt-core читает в CI / production. **CI smoke paths**: Fusion для `dbt parse`, `dbt compile`, `dbt list --select state:modified+`. Эти fast paths benefit от Fusion speed. Если CI 10 minutes сокращается до 6-7 minutes, dev velocity бонус заметен. **CI production builds**: dbt-core. Stability важнее marginal speedup для actual `dbt build`. **Migration path forward**: track Fusion adoption в industry. Если к Q4 2026 / 2027 ecosystem matures, Databricks/Redshift adapters GA, observability tools full Fusion support — рассмотреть production migration. Это не decision на сейчас, это decision на 6-12 months. **Step 4: Anti-recommendations.** Я бы НЕ рекомендовал: - "Используйте только Fusion везде, потому что новое и fast." Greenfield не означает выбирать latest, оно означает выбирать right tool. Production stability ещё важна. - "Используйте только dbt-core, Fusion не trust-worthy." Это chronic conservatism. Fusion GA, production-ready для greenfield Snowflake stack. Игнорирование = lost productivity бенефиты. - "Подождите 1.5+, потом decide." Это analysis paralysis. Decision на сейчас acceptable, можно reverse в 12 months если context меняется. **Step 5: Action items для CTO.** 1. Install Fusion CLI для всех team members (free, BSL allows). Try local dev неделя. 2. Setup CI с dbt-core для production builds, Fusion для smoke checks (GitHub Actions matrix или conditional jobs). 3. Stand up monitoring (Elementary или similar) с dbt-core compatibility. 4. Reassess в Q4 2026 после первых 6 months: какой engine действительно better fit для команды на основе lived experience. **Главный урок:** Engine choice для greenfield project редко binary. Hybrid setup низкозатратен, дает best of both worlds, и сохраняет flexibility для future re-evaluation. Senior engineering — это structured decision-making с monitor-and-adjust loop, не one-time commitment на год.

Итого

Strategic context: dbt Labs построил Fusion как ответ на engineering ceiling Python dbt-core и стратегический need differentiation. Это не оптимизация, это architectural rethink.
SDF Labs acquisition (Jan 2025) дала готовый Rust SQL semantic compiler — accelerator vs greenfield rewrite.
Coalesce 2025 (Oct 2025): Fusion 1.0 GA + Fivetran merger. Industry consolidation вокруг bundled E+L+T offering.
Почему Rust: memory efficiency, parsing throughput через rayon, async-first via tokio, compile-time type safety, single binary distribution, mature ecosystem 2025, plus pre-existing SDF Labs Rust codebase.
Что меняется vs не меняется: меняется engine internals, parsing/compilation speed, internal lineage format, transport. НЕ меняется: project structure, Jinja syntax, YAML schemas, CLI commands, adapter API contract, warehouse execution time. Fusion ускоряет всё ДО warehouse, не warehouse-side.
30x parse, 2x compile, warehouse не ускоряется — детали в уроке 03 (Fusion vs core: внутренности, divergence, compatibility).
dbt-core НЕ deprecated. Apache 2.0, parallel development tracks, остаётся reference implementation. Fusion — second engine, не replacement.
Industry в 2026: bifurcation adapters, BSL debate ongoing, competing platforms accelerate (Snowflake/Databricks/Google), Fivetran merger reshapes packaging.

Следующий урок (02) — Fusion components: внутренние слои Semantic Compiler, SQL IR, multi-dialect ANTLR grammar, ADBC drivers, artifacts. Урок 03 — divergence patterns и migration mechanics.