Путь к GA: как движок dbt Fusion проходит путь от беты к продакшену

Сегодня мы объявили, что движок dbt Fusion доступен в бета-версии.

• Если Fusion уже работает с вашим проектом — отлично! Вас ждёт много приятного 😄
• Если это ваш первый день с dbt — добро пожаловать! Начинайте сразу с Fusion — вас тоже ждёт приятный опыт.

Сегодня — Launch Day, первый день новой эры: Эпохи Fusion. Мы ожидаем, что многие команды с существующими проектами столкнутся как минимум с одной проблемой, которая помешает использовать движок dbt Fusion в продакшене. И это нормально!

Мы активно работаем над тем, чтобы разблокировать всё больше команд, и берём на себя обязательство, что к моменту достижения Fusion статуса General Availability:

• Мы будем поддерживать Snowflake, Databricks, BigQuery, Redshift — а также, вероятно, Athena, Postgres, Spark и Trino — с новым паттерном адаптеров Fusion.
• Мы покроем (практически) весь функционал dbt Core. Некоторые вещи сложно или нецелесообразно воспроизводить вне Python, а некоторые используются настолько редко, что мы будем реагировать на них по мере необходимости. При этом многие существующие поведения dbt Core будут улучшены за счёт уникальных возможностей движка dbt Fusion — таких как скорость и глубокое понимание SQL. Вы увидите обсуждения этого в соответствующих GitHub issues, на многие из которых мы ссылаемся ниже.
• Репозиторий с открытым исходным кодом dbt-fusion будет содержать больше функциональности, чем доступно в dbt Core сегодня. (Подробнее об этом здесь.)
• Опыт разработчика станет ещё быстрее и интуитивнее.

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

В ближайшие недели мы будем очень быстро добавлять функциональность. В частности, следите за поддержкой Databricks, BigQuery и Redshift (именно в таком порядке) в ближайшее время.

Самые популярные пакеты dbt Labs (dbt_utils, audit_helper, dbt_external_tables, dbt_project_evaluator) уже совместимы с Fusion. Некоторые сторонние пакеты могут не работать «из коробки», но мы планируем сотрудничать с их мейнтейнерами, чтобы подготовить и адаптировать их под Fusion.

Так когда же Fusion станет GA? Мы нацелены на достижение полного функционального паритета позже в этом году, но также надеемся подойти к этому асимптотически — то есть многие существующие пользователи dbt смогут начать переход на Fusion значительно раньше.

В течение бета-периода вы можете столкнуться с неожиданными (и ожидаемыми) проблемами при попытке запустить ваш проект на Fusion. Пожалуйста, сообщайте о любых проблемах в репозитории dbt-fusion или в Slack в канале #dbt-fusion-engine, и мы постараемся как можно быстрее вас разблокировать.

Могу ли я использовать Fusion для своего dbt-проекта уже сегодня?

Возможно! Первый и самый важный вопрос: «Поддерживается ли ваш адаптер?» (Если нет — немного терпения, мы работаем очень быстро.) Если да, то всё зависит от конкретного набора возможностей, которые вы используете в своём dbt-проекте.

Вы можете начать использовать Fusion сразу, может потребоваться внести (в основном автоматические) изменения в проект для устранения депрекейтов, либо ваш проект пока вообще не сможет быть распарсен:

Состояние	Описание	Обходное решение	Кем устраняется
Unblocked	Вы можете перейти на движок dbt Fusion без изменений в проекте
Soft blocked	Проект успешно парсится, но использует ещё не реализованный функционал	Не вызывать неподдерживаемые функции или не собирать неподдерживаемые модели	dbt Labs
Hard blocked by deprecations	Проект содержит функциональность, объявленную устаревшей в dbt Core v1.10	Устранить депрекейты с помощью скрипта dbt-autofix или workflow в dbt Studio	Вы
Hard blocked by known parse issues	Проект содержит Python-модели или использует пока не поддерживаемый адаптер	Временно удалить Python-модели	dbt Labs
Hard blocked by unknown parse issues	Вероятно, проект делает что-то нетривиальное с Jinja	Создать issue, при необходимости изменить затронутый код	Вы и dbt Labs

Loading table...

Мы постоянно убираем блокирующие факторы для перехода на Fusion на протяжении всего бета-периода и в преддверии более широкого релиза. Далее в этом посте мы подробнее разберём четыре ключевых критерия, обозначенных выше:

• Покрытие адаптеров
• Покрытие функциональности
• Публикация кода с открытым доступом к исходникам
• Улучшения developer experience

Требование для GA: покрытие адаптеров

Databricks, BigQuery и Redshift

Адаптеры dbt Fusion теперь основаны на стандарте ADBC — современном высокопроизводительном Apache‑проекте, оптимизированном для колоночных аналитических баз данных.

dbt Labs разработала новые ADBC‑совместимые драйверы (а также вспомогательный фреймворк XDBC), дополняющие уже существующий и стабильный драйвер Snowflake.

Целевые сроки релиза: мы ожидаем добавить поддержку Databricks, BigQuery и Redshift (именно в таком порядке) в ближайшие недели.

Там, где это возможно, адаптеры Fusion будут поддерживать те же методы аутентификации и конфигурации подключений/учётных данных, что и адаптеры dbt Core. Мы также получили чёткую обратную связь от клиентов платформы dbt, тестировавших Fusion CLI в бете: мы хотим, чтобы Fusion CLI мог использовать настройки подключений (config/creds) из платформы для локальных запусков (tracking issue).

Athena, Postgres, Spark и Trino

Мы планируем поддержать эти адаптеры позже в этом году, до достижения GA. Актуальные сроки смотрите в tracking issues для каждого адаптера: Trino, Athena, Spark и Postgres.

Кастомные адаптеры

Короткий ответ: новый формат адаптеров Fusion потенциально можно расширить для поддержки сторонней разработки адаптеров сообществом, но это не входит в ближайшую дорожную карту до GA (tracking issue).

Длинный ответ: Fusion теперь загружает необходимые драйверы (часть стека адаптера) по требованию. Такая динамическая линковка требует, чтобы драйверы были подписаны dbt Labs, а значит, нам нужно выстроить систему проверки вкладов в виде новых драйверов и обеспечения их безопасности.

В качестве временного решения: если вы хотите мигрировать поддерживаемый проект на движок dbt Fusion, но у вас есть зависимость от другого проекта с кастомным адаптером, вы можете использовать Hybrid project, чтобы dbt Core выполнял неподдерживаемую часть пайплайна и публиковал артефакты для downstream‑проектов.

Требование для GA: покрытие функциональности

Покрытие функциональности включает как обеспечение корректной работы задокументированных возможностей, так и (по возможности) поддержку недокументированных «случайных» фич.

В большинстве случаев, даже если ваш проект использует ещё не реализованную возможность, вы всё равно можете попробовать Fusion. Пока проект успешно парсится, вы просто можете пропустить неподдерживаемые модели.

Известные нереализованные возможности

Python‑модели

Python‑модели — единственное исключение из совета «просто пропустите их». В настоящее время движок dbt Fusion не поддерживает парсинг Python‑моделей, а значит, не может извлекать ref или config из таких файлов. Чтобы избежать потенциальной сборки моделей вне порядка DAG, мы решили пока полностью не поддерживать Python‑модели. Они вернутся — подробности в issue.

Широта поддержки материализаций

На сегодняшний день мы поддерживаем самые распространённые материализации: table, view, incremental, ephemeral для моделей, а также материализации, лежащие в основе snapshots, seeds и tests. Другие нативные стратегии (такие как microbatch incremental models, iceberg tables, materialized views/dynamic tables или stored test failures), а также кастомные материализации находятся в дорожной карте — сроки смотрите в соответствующих issues.

Важно повторить: даже если у вас есть модели, зависящие от пока неподдерживаемых стратегий материализации, вы всё равно можете попробовать движок dbt Fusion для остальной части проекта. Остальной DAG будет собираться как обычно, но неподдерживаемые стратегии приведут к ошибке, если они попадают в область выполнения dbt build или dbt run.

Чтобы исключить такие узлы, используйте команды вроде:

• dbt build --exclude config.materialized:my_custom_mat
• dbt build --exclude config.incremental_strategy:microbatch

Другие распространённые возможности

Знали ли вы, что у dbt задокументировано более 400 возможностей? Doug знает — ему пришлось занести их все в базу Notion.

Fusion уже поддерживает около двух третей из них, и у нас есть план для остальных. Следить за прогрессом можно в репозитории dbt-fusion, где заведены issues для отслеживания оставшихся поведений. Там же есть примерный набор майлстоунов, но их порядок может меняться по мере того, как всё больше команд начинают использовать Fusion и делиться обратной связью.

Среди наиболее релевантных:

• Exposures
• Новая стабильная система логирования
• Новый локальный опыт работы с документацией, который заменит dbt-docs (!)
• Programmatic invocations
• Model governance (contracts, constraints, access, deprecation_date)
• Набор CLI‑команд вроде dbt clone, state:modified.subselector, --empty, …

Важно отметить, что решение не обязательно означает идентичное поведение. Например:

• Многие из этих возможностей пока не реализованы, потому что движок Fusion открывает новые возможности — прежде всего глубокое понимание SQL, — которые мы хотим использовать для более качественного опыта. Прямой перенос старой реализации не имел бы смысла.
• Другие (например, события и система логирования) тесно связаны с Python‑основой dbt Core — их стоит переосмыслить, а не стремиться к 100% точному соответствию.

Ниже приведён срез на текущий момент того, как мы планируем закрывать оставшийся объём работ. В качестве источника истины используйте страницу issues репозитория:

Примерный путь движка dbt Fusion к GA

Неожиданные нереализованные возможности

Знали ли вы, что у dbt есть ещё и огромное количество недокументированных возможностей? С марта мы валидируем парсер нового движка на проектах, оркестрируемых платформой dbt, что уже выявило сотни расхождений в поведении и распространённых багов парсинга.

Но мы также понимаем, что существует длинный «хвост» поведений, которые проявятся только в реальных проектах, и самый эффективный способ разобраться с ними — работать напрямую с пользователями.

Эта работа будет идти параллельно с расширением поддержки функциональности. Когда вы начнёте использовать движок Fusion, пожалуйста, открывайте issue, если столкнётесь с неожиданной ошибкой, и по возможности прикладывайте минимальный проект для воспроизведения — это поможет нам быстрее всё исправить.

Требование для GA: исходно доступный код dbt-fusion лучше, чем dbt-core, для большинства сценариев

К моменту GA репозиторий dbt-fusion будет содержать необходимые (и полностью доступные в исходниках) компоненты для сборки рабочего движка для подавляющего большинства проектов dbt Core — и при этом более быстрого. Это означает, что у вас всегда будет возможность скомпилировать, использовать и модифицировать сам код без необходимости доступа к бинарнику, предоставляемому dbt Labs (хотя мы считаем, что в большинстве случаев вы предпочтёте именно бинарник — по причинам, описанным в посте Components of the dbt Fusion engine).

На данный момент мы уже выложили код, необходимый для самостоятельной сборки dbt‑бинарника, который умеет выполнять dbt deps и dbt parse. В течение бета‑периода мы продолжим готовить и публиковать код для остальных команд — для тех, кто хочет просматривать, дорабатывать или использовать его в собственных целях.

Помимо кода, необходимого для полноценного dbt‑бинарника, мы также обязались открыть исходники нескольких базовых библиотечных компонентов (таких как dbt-jinja, dbt-serde-yaml и грамматики, необходимые для высокопроизводительного SQL‑парсера). Подробности — в посте Components of the dbt Fusion engine.

Некоторые поведения, работавшие в dbt Core, не будут иметь прямого аналога в новой кодовой базе. Самые очевидные примеры — те, что зависели от особенностей Python: произвольные колбэки на EventManager (его больше нет), экспериментальная система плагинов (динамическая загрузка бинарников в Rust устроена совершенно иначе и требует подписания), или dbt‑templater в SQLFluff (который использовал внутренние механизмы dbt Core, выходящие за рамки публичных интерфейсов — хотя мы планируем сделать собственный быстрый линтер).

Требование для GA: DX на высоте

Больше скорости

Запуски на базе движка dbt Fusion уже заметно быстрее, чем те же самые команды в dbt Core, но нам есть куда расти. Мы знаем, что остаётся много «низко висящих фруктов», и к моменту GA ожидаем, что такие задачи, как полная компиляция проекта, будут выполняться как минимум вдвое быстрее для многих проектов.

Если вы занимаетесь бенчмаркингом, нас особенно интересуют ситуации, когда Fusion «зависает» на одном файле на пару секунд. Также имейте в виду:

• Запись очень больших manifest‑файлов медленная при любом подходе. Попробуйте использовать --no-write-json. Мы обсуждаем, имеет ли смысл делать урезанный manifest по умолчанию. Что вы думаете?
• Команда dbt compile в Fusion выполняет больше работы, чем в dbt Core, поскольку включает полную SQL‑валидацию. Чтобы сравнить только этап рендеринга SQL (аналог compile в dbt Core), можно попробовать отключить статический анализ с помощью флага --static-analysis off.

В качестве примера возможного уровня оптимизации обратите внимание на инкрементальную перекомпиляцию, используемую для предоставления обратной связи в реальном времени в расширении VS Code.

Более информативный вывод в консоли

При подготовке бета‑релиза мы намеренно сделали вывод Fusion CLI максимально подробным — он показывает всё, что происходит, из‑за чего ошибки и предупреждения могут теряться среди статусных сообщений. Мы уже начали наводить порядок и даже подумываем о прогресс‑барах. В любом случае цель одна: вы должны видеть строки логов, требующие внимания, и не намного больше.

Ваши идеи

Что кажется неудобным при работе с dbt Fusion? Расскажите нам! Если у вас есть чёткое понимание, что именно не так и как должно быть, смело создавайте GitHub issue. Дополнительный плюс — минимальный проект для воспроизведения.

Если же вам нужно сначала обсудить идею, мы активно следим за каналами #dbt-fusion-engine (для общих обсуждений) и #dbt-fusion-engine-migration (для детального разбора конкретных багов) в Slack.

До тех пор, пока Fusion не станет GA, мы будем приоритизировать достижение паритета с существующими возможностями фреймворка, а не добавление новых. После GA мы подумаем, стоит ли переносить существующие feature requests из репозитория dbt-core в dbt-fusion — или в какое‑то третье место. Следите за новостями.

Как следить за прогрессом

Путь Fusion к GA — это усилие всего сообщества. Мы хотим слышать вас, работать с вами, получать идеи и обратную связь. Будь то баг‑репорт, идея для новой возможности или более общие мысли — мы открыты к диалогу.

• В Slack мы доступны в каналах #dbt-fusion-engine и #dbt-fusion-engine-migration
• GitHub‑репозиторий: https://github.com/dbt-labs/dbt-fusion
• В июне по всему миру проходит несколько десятков митапов dbt World Circuit: https://www.meetup.com/pro/dbt/. (Jeremy будет выступать в Париже, Марселе и Бостоне — приходите пообщаться!)
• Мы будем регулярно проводить office hours с участием представителей команд Developer Experience, Engineering и Product. Даты будут анонсироваться в канале #dbt-fusion-engine.