Теперь dbt Cloud включает в себя набор новых функций, которые позволяют настраивать точные и уникальные подключения к платформам данных на уровне окружения и пользователя. Это позволяет создавать более сложные конфигурации, такие как подключение проекта к нескольким учетным записям хранилищ, полноценная поддержка стейджинговых окружений и пользовательские переопределения для конкретных версий dbt. Это дает разработчикам dbt Cloud необходимые функции для решения более сложных задач, таких как рабочие процессы Write-Audit-Publish (WAP) и безопасное тестирование обновлений версий dbt. Хотя вы все еще настраиваете подключение по умолчанию на уровне проекта и для каждого разработчика, теперь у вас есть инструменты для более продвинутой и безопасной работы. Вскоре dbt Cloud пойдет еще дальше, позволяя устанавливать несколько подключений глобально и повторно использовать их с помощью глобальных подключений.

В Lunar большинство наших dbt моделей берут данные из событийно-ориентированной архитектуры. Например, у нас есть следующие модели для папки activity_based_interest в нашем слое загрузки:

• activity_based_interest_activated.sql
• activity_based_interest_deactivated.sql
• activity_based_interest_updated.sql
• downgrade_interest_level_for_user.sql
• set_inactive_interest_rate_after_july_1st_in_bec_for_user.sql
• set_inactive_interest_rate_from_july_1st_in_bec_for_user.sql
• set_interest_levels_from_june_1st_in_bec_for_user.sql

Это приводит к тому, что многие одинаковые колонки (например, account_id) существуют в разных моделях, в разных слоях. Это означает, что я в итоге:

1. Пишу/копирую одну и ту же документацию снова и снова
2. На полпути понимаю, что могу улучшить формулировку, чтобы сделать ее более понятной, и возвращаюсь, чтобы обновить файлы .yml, которые уже сделал
3. Понимаю, что сделал синтаксическую ошибку в своем файле .yml, поэтому возвращаюсь и исправляю ее
4. Понимаю, что колонки определены по-разному с использованием разных формулировок в других папках нашего проекта dbt
5. Переосмысливаю свой выбор карьеры и молюсь, чтобы большая языковая модель украла мою работу
6. Задумываюсь, есть ли лучший способ генерировать документацию, используемую в разных моделях

Много лет, работая в области данных и аналитической инженерии, я ценил ежедневное общение в небольшом офисе с талантливыми людьми, использующими различные инструменты — от аналитиков, работающих с SQL и Excel, до дата-сайентистов, работающих с Python. Я всегда чувствовал, что у нас есть много возможностей для совместной работы, но изолированные данные и инструменты делали это гораздо сложнее. Разнообразие наших инструментов и языков делало потенциал для сотрудничества еще более интересным, поскольку у нас могли быть люди с разными областями экспертизы, каждый из которых вносил бы свой уникальный вклад в проект. Но с логистической точки зрения это просто не могло быть реализовано в масштабируемом виде.

Поэтому я не могу быть более взволнован возможностями полиглотности dbt, которые появились в dbt Core 1.3. Этот релиз приносит библиотеки датафреймов Python, которые важны для дата-сайентистов, и позволяет использовать Python общего назначения, но при этом использует общую базу данных для чтения и записи наборов данных. Аналитические инженеры и дата-сайентисты сильнее вместе, и я не могу дождаться, чтобы работать бок о бок в одном репозитории со всеми моими друзьями-дата-сайентистами.

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

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

Мы также предоставим вам интеллектуальные ресурсы для сравнения:

• различных реализаций датафреймов в разных платформах данных
• датафреймы против SQL

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

На основе нашего раннего опыта, мы рекомендуем вам:

✅ Делайте: Используйте Python, когда он лучше подходит для задачи — обучение моделей, использование предсказательных моделей, матричные операции, исследовательский анализ данных (EDA), пакеты Python, которые могут помочь с комплексными трансформациями, и другие случаи, когда Python является более естественным решением для проблемы, которую вы пытаетесь решить.

❌ Не делайте: Используйте Python там, где решение на SQL столь же прямолинейно. Хотя чисто Python проект dbt возможен, мы ожидаем, что наиболее значимые проекты будут смесью SQL и Python.

Примечание редактора - этот пост предполагает знание разработки dbt пакетов. Для введения в dbt пакеты ознакомьтесь с So You Want to Build a dbt Package.

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

Я люблю dbt пакеты, потому что они упрощают расширение функциональности dbt и создание повторно используемых аналитических ресурсов. Еще лучше, мы можем находить и делиться dbt пакетами, разработанными другими, находя отличные пакеты на dbt hub. Однако разработка сложных dbt макросов может быть затруднительной, потому что dbt на базе Jinja2 не обладает некоторыми функциями, которые вы ожидаете в разработке программного обеспечения, такими как модульное тестирование.

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

Если вам нужно было предоставить доступ к модели dbt с 2019 года по сегодняшний день, есть большая вероятность, что вы наткнулись на пост "Точные операторы grant, которые мы используем в проекте dbt" на Discourse. В нем объяснялись варианты для покрытия двух дополнительных возможностей:

1. запрос отношений через привилегию "select"
2. использование схемы, в которой находятся эти отношения, через привилегию "usage"

❓ Для кого это: Это для опытных пользователей dbt Cloud, которые хотят расширить свои знания об API dbt с помощью интерактивной коллекции Postman. Мы рекомендуем углубляться в это только после того, как у вас будет прочное знание dbt + dbt Cloud. У вас есть несколько вариантов для изучения коллекции:

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

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

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

Непрерывная интеграция (CI) настраивает систему для тестирования каждого pull request перед слиянием. Непрерывное развертывание (CD) развертывает каждое одобренное изменение в производственной среде. "Упрощенный CI" означает запуск/тестирование только измененного кода, тем самым экономя вычислительные ресурсы. Вкратце, CI/CD автоматизирует тестирование и развертывание dbt конвейеров.

dbt Cloud, популярный метод развертывания dbt, поддерживает CI/CD на основе GitHub и Gitlab из коробки. Он не поддерживает Bitbucket, AWS CodeCommit/CodeDeploy или другие сервисы, но даже если вы привязаны к неподдерживаемой платформе, не стоит отчаиваться.

Хотя в этой статье используется Bitbucket Pipelines в качестве вычислительного сервиса и Bitbucket Downloads в качестве сервиса хранения, эта статья должна служить шаблоном для создания dbt-основанного упрощенного CI/CD где угодно. Идея всегда одна и та же:

[Мы бы хотели иметь] кривую зрелости для реализации dbt от начала до конца для каждой версии dbt .... Сейчас в dbt так много функций, но было бы здорово понять, "какой минимальный набор функций/компонентов dbt должен быть в базовой реализации dbt?... а что является дополнительным бонусом?" -Will Weld на dbt Community Slack

Один из вопросов, который мы слышим снова и снова, - как выглядит прогресс через различные стадии зрелости в проекте dbt?

Когда Уилл задал этот вопрос в Slack, я задумался о том, что потребуется для создания структуры зрелости проекта dbt.

Без команды для их запуска, модели и тесты dbt просто занимают место в репозитории Git.

Конкретные команды dbt, которые вы запускаете в производственной среде, являются центром управления вашим проектом. Они формируют структуру, определяющую стандарты качества и свежести данных вашей команды.

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

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

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

Причина проста: пакеты, как неотъемлемая часть dbt, следуют нашему принципу создания аналитическими инженерами и для них. Их легко установить, они доступны, и в конце концов, это просто SQL (с добавлением git и jinja). Вы можете либо поделиться своим пакетом с сообществом, либо использовать его среди своих команд в вашей организации.

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

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

После двух лет помощи компаниям с численностью сотрудников от 20 до 10 000+ в реализации dbt и dbt Cloud, ниже я постараюсь ответить на вопрос: "Должен ли у меня быть один репозиторий для моего dbt проекта или несколько?" Альтернативное название: "Быть или не быть монорепозиторию, вот в чем вопрос!"

Прежде чем я углублюсь в то, как это создать, я должен сказать следующее. Вам, вероятно, это не нужно. Я, вместе с моими коллегами из Fishtown, провел бесчисленные часы, работая с клиентами, которые запрашивают потоковые данные почти в реальном времени. Однако, когда мы начинаем углубляться в проект, часто оказывается, что такой случай использования отсутствует. Существует множество причин, по которым потоковая передача данных почти в реальном времени не подходит. Две ключевые из них:

1. Исходные данные не обновляются достаточно часто.
2. Конечные пользователи не смотрят на данные достаточно часто.

Поэтому, когда поступает запрос на моделирование почти в реальном времени, я (и вы тоже!) должен быть скептичен.

Если вы используете dbt более года, ваш проект устарел. Это естественно.

Появились новые функции. Изменяются хранилища данных. Обновляются лучшие практики. За последний год я и другие члены команды Fishtown Analytics (теперь dbt Labs!) провели семь аудитов для клиентов, которые использовали dbt минимум 2 месяца.