Jason Ganz

Сегодня мы анонсировали движок dbt Fusion.

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

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

От движка на Rust до расширения VS Code, от новых адаптеров на базе Arrow до базовых технологий под лицензией Apache — мы подробно разберём, что делает каждый компонент, под какой лицензией он распространяется (о причинах см. сопутствующий пост Тристана), а также как вы можете начать использовать Fusion и принять участие уже сегодня.

TL;DR: что нужно знать​

• Привычный слой авторинга dbt остаётся без изменений, но движок исполнения под ним полностью новый.
• Новый движок называется dbt Fusion engine — он переписан с нуля на Rust на основе технологий из SDF. dbt Fusion engine существенно быстрее dbt Core и содержит встроенную технологию понимания SQL, которая станет основой следующего поколения рабочих процессов аналитической инженерии.
• dbt Fusion engine сейчас находится в бете. Вы уже можете попробовать его сегодня, если используете Snowflake — другие адаптеры начнут появляться с начала июня. Ознакомьтесь с нашим планом выхода в general availability (GA) и попробуйте quickstart.
• Чтобы использовать Fusion, не обязательно быть клиентом dbt Labs — пользователи dbt Core могут бесплатно использовать dbt Fusion engine уже сегодня в локальной среде.
• Fusion можно использовать с новым расширением dbt для VS Code, напрямую через CLI или через dbt Studio.
• Это начало новой эпохи аналитической инженерии. Чтобы увидеть, что Fusion engine позволит реализовать в течение ближайших 1–2 лет, прочитайте этот пост.

dbt — это стандарт для создания управляемых и надежных датасетов поверх структурированных данных. MCP (Model Context Protocol) демонстрирует всё больший потенциал в качестве стандарта предоставления контекста для LLM, позволяя им эффективно работать в реальных, операционных сценариях.

Сегодня мы открываем исходный код экспериментальной версии dbt MCP server. Мы ожидаем, что в ближайшие годы структурированные данные станут глубоко интегрированы в AI‑воркфлоу, а dbt будет играть ключевую роль в создании и предоставлении этих данных.

Одной из самых важных функций dbt является возможность для команд сотрудничать в создании и распространении организационных знаний.

Ранее это выглядело как работа команды в одном проекте dbt для создания набора преобразованных объектов в их платформе данных.

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

Мы все это делали: расширяли данные во время объединения, создавая дублирующиеся записи (иногда дублирующиеся в нескольких экземплярах).

Тот случай, когда исторические данные о доходах удвоились в понедельник? Классический пример расширения.

Можно ли было этого избежать? Да, очень просто: определив уникальность grain для table с помощью первичного ключа и обеспечив её с помощью теста dbt.

Итак, давайте углубимся в тему: что такое первичные ключи, какие облачные аналитические хранилища их поддерживают и как вы можете тестировать их в вашем хранилище для обеспечения уникальности.

Почему первичные ключи важны​

Мы все знаем одно из самых фундаментальных правил в данных: каждая table должна иметь primary key. Первичные ключи важны по многим причинам:

• Они гарантируют, что в вашей таблице нет дублирующихся строк
• Они помогают устанавливать связи с другими таблицами
• Они позволяют быстро определить grain таблицы (например, таблица customers с PK customer_id имеет одну строку на каждого клиента)
• Вы можете тестировать их в dbt, чтобы убедиться, что ваши данные полные и уникальные

Аналитика — это сложно. Делать аналитику правильно — еще сложнее.

Существует огромное количество факторов, которые нужно учитывать: отсутствуют ли данные? Как сделать это инсайт доступным? Почему моя база данных заблокирована? Мы вообще задаем правильные вопросы?

Усугубляет ситуацию то, что аналитика иногда может казаться одиноким занятием.

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

Так давайте все вместе возьмем на себя обязательство делиться нашими труднодобытыми знаниями друг с другом — и тем самым проложим путь для будущих поколений аналитиков.