В апреле мы выпустили локальный dbt MCP (Model Context Protocol) server как open source‑проект для подключения AI‑агентов и LLM к доверенным dbt‑ассетам с прямым, управляемым доступом. dbt MCP server предоставляет универсальный, открытый стандарт для соединения AI‑систем с вашим структурированным контекстом, что позволяет сохранять точность, управляемость и надежность агентов. Подробнее — в разделе About dbt Model Context Protocol.

С момента релиза локального dbt MCP server сообщество dbt применяло его самыми разными способами, включая агентную разговорную аналитику, исследование дата‑каталога и рефакторинг dbt‑проектов. Однако одним из ключевых отзывов от AI‑инженеров стало то, что локальный dbt MCP server сложно развертывать и хостить для мультиарендных (multi‑tenant) нагрузок, из‑за чего становится трудно строить приложения поверх dbt MCP server.

Именно поэтому мы рады представить новый способ интеграции с dbt MCP — remote dbt MCP server. Remote dbt MCP server не требует установки зависимостей или запуска dbt MCP server в вашей инфраструктуре, что делает разработку и запуск агентов проще, чем когда‑либо. Он доступен уже сегодня в public beta для пользователей с тарифами dbt Starter, Enterprise или Enterprise+, и готов к использованию для создания AI‑приложений.

Введение в dbt и BigFrames​

dbt: Фреймворк для трансформации данных в современных аналитических хранилищах с использованием модульного SQL или Python. dbt позволяет аналитическим командам совместно и эффективно разрабатывать аналитический код, применяя лучшие практики программной инженерии — такие как контроль версий, модульность, переносимость, CI/CD, тестирование и документация. Подробнее см. What is dbt?

BigQuery DataFrames (BigFrames): Open-source Python-библиотека от Google. BigFrames масштабирует обработку данных на Python, транслируя распространённые API из мира data science (pandas и scikit-learn) в SQL-запросы BigQuery.

Подробнее можно узнать в официальном руководстве BigFrames и в публичном репозитории BigFrames на GitHub.

Комбинируя dbt и BigFrames через адаптер dbt-bigquery (далее — «dbt-BigFrames»), вы получаете:

• Модульное моделирование на SQL и Python в dbt, управление зависимостями с помощью dbt.ref(), конфигурацию окружений и тестирование данных. При использовании облачной платформы dbt также доступны планирование и мониторинг джобов.
• Возможность BigFrames выполнять сложные Python-трансформации (включая машинное обучение) непосредственно в BigQuery.

dbt-BigFrames использует службу выполнения ноутбуков Colab Enterprise в проекте GCP для запуска Python-моделей. Эти ноутбуки исполняют код BigFrames, который затем переводится в SQL для BigQuery.

Привет, сообщество!

Меня зовут Бруно, и, возможно, вы видели мои посты про dbt в LinkedIn. Если нет — давайте познакомимся. Я начал работать с dbt более 3 лет назад. В то время я только осваивал этот инструмент и, чтобы лучше в нём разобраться, начал создавать материалы, которые помогали мне учиться. Один из них — шпаргалка по dbt — и стал отправной точкой моего пути в сообществе.

От этой шпаргалки я перешёл к созданию самых разных материалов, участию и активному взаимодействию с сообществом, и в итоге дважды получил награду dbt community award. Я очень благодарен за это и по-настоящему горжусь.

С момента приобретения SDF Labs компанией dbt Labs я ждал дня, когда мы увидим результат слияния этих двух компаний. Спойлер: это dbt Fusion engine — и он оказался даже лучше, чем я ожидал.

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

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

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

От движка на Rust до расширения VS Code, от новых адаптеров на базе Arrow до базовых технологий под лицензией Apache — мы подробно разберём, что делает каждый компонент, под какой лицензией он распространяется (о причинах см. сопутствующий пост Тристана), а также как вы можете начать использовать 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 сегодня. (Подробнее об этом здесь.)
• Опыт разработчика станет ещё быстрее и интуитивнее.

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

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 лет, прочитайте этот пост.

Революция AI уже здесь — но готовы ли мы?
По всему миру ажиотаж вокруг AI трудно не заметить. Повсеместно обсуждают большие языковые модели, агентные workflow и то, как AI изменит каждую отрасль. Однако реальных примеров использования AI в продакшене по‑прежнему немного.

Одной из ключевых проблем, мешающих переводу AI‑кейсов в продакшен, является отсутствие возможности систематически и управляемо оценивать корректность ответов AI. Переход от прототипов к продакшену требует строгой оценки, и у большинства организаций нет фреймворка, который гарантировал бы, что AI‑результаты остаются качественными, надёжными и пригодными для принятия решений.

Введение​

Построение масштабируемых дата-пайплайнов в быстрорастущем финтехе часто похоже на починку велосипеда на ходу. Нужно постоянно поставлять инсайты, даже когда объёмы данных взрывообразно растут. В Kuda (нигерийском необанке) мы столкнулись с этой проблемой по мере стремительного роста пользовательской базы. Классический пакетный ETL (полная пересборка таблиц при каждом запуске) начал давать сбои: пайплайны выполнялись часами, а расходы резко выросли. Нам нужно было поддерживать актуальность данных, не перерабатывая всё целиком. Решением стало использование incremental models в dbt, которые обрабатывают только новые или изменённые записи. Это радикально сократило время выполнения и снизило затраты в BigQuery, позволив нам эффективно масштабироваться.

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

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

Как администратор dbt Cloud, вы только что перешли на dbt Cloud с тарифом Enterprise plan — поздравляем! dbt Cloud предлагает множество возможностей, таких как CI/CD, Orchestration, dbt Explorer, dbt Semantic Layer, dbt Mesh, Visual Editor, dbt Copilot и многое другое. Но с чего начать?

Мы настоятельно рекомендуем, начиная внедрение функциональности dbt Cloud, в первую очередь настроить Single Sign-On (SSO) и Role-Based Access Control (RBAC). Этот базовый шаг позволяет вашей организации защитить пайплайны данных, упростить онбординг пользователей в dbt Cloud и оптимизировать затраты в долгосрочной перспективе.

Привет! Мы — Кристин и Кэрол, Resident Architects в dbt Labs. Наша повседневная работа связана с тем, чтобы помогать командам достигать как технических, так и бизнес-ориентированных целей. Работая с самым разным кругом клиентов — от небольших стартапов до крупных корпораций — мы накопили ценный опыт в сопровождении команд при внедрении архитектуры, которая решает их ключевые болевые точки.

Информация, которой мы собираемся поделиться, основана не только на нашем опыте — мы регулярно сотрудничаем с другими экспертами, такими как Taylor Dunlap и Steve Dowling, которые внесли значительный вклад в формирование этих рекомендаций. Их работа заключается в том, чтобы быть критически важным мостом для команд между реализацией и бизнес-результатами, в конечном итоге помогая выработать целостное техническое видение через выявление проблем и решений.

Зачем мы здесь?
Мы помогаем командам с архитектурой dbt, которая включает в себя инструменты, процессы и конфигурации, используемые для начала разработки и деплоя с dbt. За кулисами происходит множество решений, направленных на стандартизацию этих составляющих — и во многом они определяются тем, каким мы хотим видеть процесс разработки. Стремление к идеальному workflow часто приводит к тому, что команды застревают в бесконечном планировании и обсуждениях, что замедляет или даже полностью останавливает разработку. Если вам это знакомо, мы надеемся, что наши рекомендации помогут вам чувствовать себя увереннее и начать разблокировать разработку — даже если пока не всё до конца продумано!

Помните, каким dbt ощущался, когда у вас был небольшой проект? Вы нажимали Enter — и всё начинало происходить практически мгновенно. Мы возвращаем это ощущение.

Совет по бенчмаркингу: всегда старайтесь получать данные, которые достаточно хороши, чтобы вам не пришлось делать по ним статистику

После серии подробных разборов, посвящённых внутреннему устройству понимания SQL, давайте немного поговорим о скорости. А именно — об одном из самых раздражающих замедлений по мере роста проекта: парсинге проекта.

Если после запуска dbt вы ждёте несколько секунд или даже минут, прежде чем что-то начнёт происходить, — это потому, что парсинг ещё не завершён. Но в демо SDF от Лукаса на вебинаре в прошлом месяце такого длительного ожидания не было. Почему?

Вы когда‑нибудь задумывались, что на самом деле происходит в базе данных, когда вы отправляете туда (идеальный, эффективный, полный инсайтов) SQL‑запрос?

Ладно, скорее всего — нет 😅. Как бы то ни было, в dbt Labs мы очень много говорим об инструментах SQL Comprehension после приобретения SDF Labs и считаем, что сообществу тоже будет полезно участвовать в этом разговоре. Недавно мы опубликовали пост в блоге о разных уровнях инструментов SQL Comprehension. Если вы его читали, то могли столкнуться с несколькими новыми терминами, с которыми раньше были не очень знакомы.

В этом посте мы подробнее разберём технологии, лежащие в основе инструментов SQL Comprehension. Надеемся, что в итоге у вас появится более глубокое понимание — и уважение — к той непростой работе, которую выполняет компьютер, превращая ваши SQL‑запросы в прикладные бизнес‑инсайты!

С тех пор как dbt Labs на прошлой неделе приобрела SDF Labs, я с головой погрузился в их технологии, пытаясь во всём разобраться. Главным, что я знал на входе, было: «SDF понимает SQL». Фраза короткая и ёмкая, но детали за ней — по-настоящему захватывающие.

Чтобы следующий этап развития Analytics Engineering оказался таким же трансформирующим, как и предыдущий, dbt должен выйти за рамки строкового препроцессора и начать полноценно понимать SQL. Впервые именно SDF предоставляет технологии, которые делают это возможным. Сегодня мы подробно разберёмся, что вообще означает «понимание SQL» и почему это так важно для того, что нас ждёт дальше.

Когда мы с женой делали ремонт дома, мы решили взять на себя роль owner-builder. Это было смелое (и во многом наивное) решение, но нам хотелось контролировать каждый аспект проекта. Чего мы не осознавали, так это того, насколько сложным и изматывающим окажется управление таким количеством движущихся частей.

Моя жена размышляет о нашей вменяемости

Нам приходилось координировать множество элементов:

• Архитекторов, которые проектировали планировку, интерьер и экстерьер.
• Архитектурные планы, описывающие, как должен выглядеть дом.
• Строителей, которые воплощали эти планы в жизнь.
• Инспекторов, муниципальные органы и энергоаудиторов, которые проверяли соответствие требованиям и стандартам.

👋 Приветствуем, dbt’еры! Это Фейт и Джерри, и мы снова здесь, чтобы предложить тактические советы о том, где разместить тесты в вашем конвейере.

В нашем первом посте о совершенствовании лучших практик тестирования мы разработали приоритетный список проблем с качеством данных. Мы также задокументировали первые шаги по отладке каждой проблемы. Этот пост поможет вам определить, где конкретные тесты должны находиться в вашем конвейере данных.

Обратите внимание, что мы строим это руководство на основе того, как мы структурируем данные в dbt Labs. Вы можете использовать другой подход к моделированию — это нормально! Примените наши рекомендации к форме ваших данных и дайте нам знать в комментариях, какие изменения вы внесли.

Сначала вот наши мнения о том, где должны находиться конкретные тесты:

• Тесты источников должны касаться проблем с качеством данных, которые можно исправить. См. вставку ниже для пояснения, что мы имеем в виду под "исправимыми".
• Тесты на этапе подготовки должны быть ориентированы на бизнес-аномалии, специфичные для отдельных таблиц, такие как допустимые диапазоны или обеспечение последовательных значений. В дополнение к этим тестам, ваш слой подготовки должен очищать любые null, дубликаты или выбросы, которые вы не можете исправить в вашей системе источника. Обычно вам не нужно тестировать ваши усилия по очистке.
• Тесты промежуточного и витринного слоев должны быть ориентированы на бизнес-аномалии, возникающие в результате объединений или вычислений. Вы также можете рассмотреть возможность добавления дополнительных тестов на первичный ключ и отсутствие null в столбцах, где особенно важно защитить зернистость.

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

В этом блоге мы рассмотрим план определения качества данных. Это будет выглядеть следующим образом:

• выявление проблем гигиены данных
• выявление проблем аномалий, ориентированных на бизнес
• выявление проблем аномалий, ориентированных на статистику

После того как мы определим качество данных, мы перейдем к приоритизации этих проблем. Мы будем:

• обдумывать каждую проблему с точки зрения широты воздействия
• решать, должна ли каждая проблема иметь уровень ошибки или предупреждения

На прошлой неделе, летя домой в Детройт и работая над этой статьей в самолете, я впервые увидел недавно соединенную палубу Международного моста Горди Хоу, который пересекает реку Детройт и соединяет США и Канаду. Этот образ запомнился, потому что, в некотором смысле, хранилище признаков является мостом между чистыми, согласованными наборами данных и моделями машинного обучения, которые зависят от этих данных. Но более интересным, чем сам мост, является огромный процесс координации, необходимый для его строительства. Это строительное усилие, как мне кажется, может научить нас многому о процессах и необходимости хранилищ признаков в машинном обучении (ML).

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

Если вы не следите за новостями в индустрии данных, вы могли пропустить недавний ажиотаж вокруг открытого формата таблиц под названием Apache Iceberg™. Это один из многих открытых форматов таблиц, таких как Delta Lake, Hudi и Hive. Эти форматы меняют способ хранения данных и доступа к метаданным. Они во многом революционны.

Но я должна быть честной: меня это не волнует. Но не по тем причинам, которые вы могли бы подумать.

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

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

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