Data ecosystem

В апреле мы выпустили локальный 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 в 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 лет, прочитайте этот пост.

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

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

Помните, каким 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. Это было смелое (и во многом наивное) решение, но нам хотелось контролировать каждый аспект проекта. Чего мы не осознавали, так это того, насколько сложным и изматывающим окажется управление таким количеством движущихся частей.

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

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

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

Введение​

Год был 2020. Я жила в доме, где были только котята, а dbt Labs все еще называлась Fishtown Analytics. Один из корпоративных клиентов, с которым я работала, Jetblue, попросил меня помочь запускать их модели dbt каждые 2 минуты, чтобы соответствовать SLA в 5 минут.

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

Перенесемся в 2023 год. Я пишу это, пока мой огромный пес храпит рядом со мной (не волнуйтесь, коты тоже размножились). Jetblue переросла lambda views из-за ограничений производительности (представление может быть только настолько производительным), и мы находимся на очередной вехе в пути dbt к поддержке потоковой передачи. Какое время!

Сегодня мы объявляем, что теперь поддерживаем материализованные представления в dbt. Итак, что это значит?

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

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

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

Так почему же Data Vault? Вы сталкивались с проектом по созданию хранилища данных с более чем 50 источниками данных, с более чем 25 разработчиками данных, работающими на одной платформе данных, или с данными, охватывающими более 5 лет с двумя или более поколениями исходных систем? Если нет, то может быть сложно изначально понять преимущества Data Vault, и, возможно, моделирование по Кимбаллу будет лучше для вас. Но если вы находитесь в любой из перечисленных ситуаций, то эта статья для вас!

dbt Cloud — это хостинговый сервис, который многие организации используют для своих развертываний dbt. Среди прочего, он предоставляет интерфейс для создания и управления заданиями развертывания. Когда задания запускаются (например, по расписанию cron или через API), они генерируют различные артефакты, содержащие ценную метадату, связанную с проектом dbt и результатами выполнения.

dbt Cloud предоставляет REST API для управления заданиями, артефактами выполнения и другими ресурсами dbt Cloud. Инженеры по данным/аналитике часто пишут пользовательские скрипты для автоматизированных вызовов API, используя инструменты cURL или Python Requests. В некоторых случаях инженеры копируют/переписывают их между проектами, которым нужно взаимодействовать с API. Теперь у них есть куча скриптов, которые нужно поддерживать и развивать, если изменяются бизнес-требования. Если бы только существовал специальный инструмент для взаимодействия с API dbt Cloud, который абстрагировал бы сложности вызовов API за простым в использовании интерфейсом... О, подождите, он есть: dbt-cloud-cli!

Особая благодарность: Emilie Schario, Matt Winkler

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

Я люблю называть эту интероперабельность "передачей эстафеты". Как в эстафетной гонке, здесь есть четкие точки передачи и явное владение на всех этапах процесса. Но есть одна передача эстафеты, которая все еще относительно болезненна и не определена: передача между инженерами машинного обучения (ML) и аналитическими инженерами.

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

В этой статье мы исследуем реальную передачу эстафеты между ML-инженерами и аналитическими инженерами, подчеркивая, где все пошло не так.

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

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

Airflow и dbt часто рассматриваются как взаимоисключающие:

Вы либо строите SQL-трансформации, используя SQL-операторы базы данных Airflow (например, SnowflakeOperator), либо разрабатываете их в проекте dbt.

Вы либо оркестрируете модели dbt в Airflow, либо развертываете их, используя dbt Cloud.

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