Максимальная настройка: Конфигурирование уникальных подключений в dbt Cloud

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

Первая новая функция, которую мы рассмотрим, называется расширенные атрибуты.

Выбор профиля

Расширенные атрибуты — это функция, которая приносит гибкость конфигурации profiles.yml из dbt Core в dbt Cloud. До выпуска функции расширенных атрибутов вы настраивали подключение на уровне проекта и в основном оставались с ним. Вы могли разрабатывать и оркестрировать в разных схемах, чтобы держать разработку подальше от производства, или настраивать стейджинговый слой с помощью ручных обходных путей, но за пределами этого задачи становились более сложными. Заимствуя гибкость profiles.yml, которая позволяет настраивать столько уникальных подключений, сколько вам нужно, теперь вы можете делать то же самое с инструментами безопасности и оркестрации в dbt Cloud.

Как работают расширенные атрибуты

Опция Расширенные атрибуты доступна в виде текстового поля на странице Настройки окружения, где вы можете вводить конфигурации типа profiles.yml. При разработке в dbt Cloud IDE, dbt Cloud CLI или оркестрации выполнения заданий, dbt Cloud будет анализировать предоставленный YAML для расширенных атрибутов и объединять его с вашими базовыми настройками подключения проекта. Если атрибут существует в другом источнике (обычно это будут настройки подключения вашего проекта или конфигурации задания), он заменит его значение, включая переопределение любых пользовательских переменных окружения. Если атрибут не существует, он добавит атрибут в конфигурацию подключения. Вы можете ознакомиться с документацией для более конкретных деталей, но теперь, когда у вас есть общее представление, давайте рассмотрим несколько примеров, чтобы понять, почему это так здорово.

Несколько учетных записей для сред разработки и производства

Наиболее актуальный случай использования для пользователей dbt Cloud — это возможность использовать разные подключения учетных записей для разных команд или этапов разработки в их конвейерах. Рассмотрим команду, у которой есть типичная настройка dev, staging, production (известная как рабочий процесс WAP): разработка для активной работы с небольшими наборами данных, стейджинг для продвижения и проверки изменений на клонированных производственных данных и производство для окончательного развернутого кода, который питает BI-инструменты. Для этой гипотетической команды это, однако, отдельные учетные записи в их платформе данных с собственными наборами RBAC и другими настройками. Это идеальный случай использования для расширенных атрибутов. Давайте посмотрим, как эта команда может настроить это для компании, использующей несколько учетных записей BigQuery, проектов и наборов данных (проекты и наборы данных аналогичны базам данных и схемам на других платформах, таких как Snowflake) для разделения dev, staging и prod:

Текстовое поле расширенных атрибутов внизу настроек окружения.

Разработка

account: 123dev
project: dev
dataset: dbt_winnie
method: oauth
threads: 1

Стейджинг

account: 123dev
project: staging
dataset: main
method: service-account-json
threads: 16

Производство

account: 456prod
project: analytics
dataset: main
method: service-account-json
threads: 16

С этой настройкой у нас есть отдельная учетная запись для разработки, использующая индивидуальные наборы данных для каждого разработчика (с одним потоком, чтобы журналы сборки разработки было легче читать), подключенная через OAuth; и общий проект staging с набором данных по умолчанию main для стейджинговой среды, который строится только через учетную запись службы GCP через dbt Cloud. В этом проекте мы можем настроить разрешения IAM, чтобы разрешить сборку в стейджинговую схему только из заданий, использующих стейджинговую среду.

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

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

Весь мир — сцена

Ранее мы упоминали о стейджинговых средах в обсуждении расширенных атрибутов, но давайте углубимся в то, как dbt Cloud теперь поддерживает их на полноценном уровне. Теперь у вас есть возможность при настройке окружения выбрать Разработка, Производство или Стейджинг. Когда вы настраиваете окружение как стейджинговое, вы разблокируете новые возможности, в первую очередь возможность откладывать работу на это окружение для разработки. Это полностью позволяет реализовать правильный поток Write-Audit-Publish, где разработка строится и продвигается в стейджинг перед слиянием в производственную ветку, когда релизы были протестированы.

Все, что вам нужно сделать, это настроить окружение как стейджинговое и включить опцию Откладывать на стейджинг/производство в dbt Cloud IDE. Это будет отдавать предпочтение стейджинговой среде перед производственной, если у вас она настроена.

Настройка окружения как стейджингового типа.

Переключатель для включения откладывания на стейджинговую или производственную среду.

Обновление по кривой

Наконец, давайте рассмотрим более специализированный случай использования. Представьте, что у нас есть "тигровая команда" (состоящая из единственного аналитического инженера по имени Дэйв), которой поручено обновление с версии dbt 1.6 до нового Трека последнего выпуска, чтобы воспользоваться новыми функциями и улучшениями производительности. Мы хотим, чтобы остальная часть команды данных оставалась продуктивной в dbt 1.6 на данный момент, позволяя Дэйву обновляться и работать с Latest (и лучшим) dbt.

Среда разработки

По умолчанию среда разработки настроена на версию 1.6:

Среды разработки настроены на v1.6 по умолчанию.

Настройки подключения для разработки

Настройки подключения для разработки Дэйва:

Переопределение среды разработки Дэйва.

Специальный запуск

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

Я призываю вас опробовать эти новые функции, создав стейджинговую среду, настроив уникальные подключения, которые вам нужны для ее активации в вашей организации, и увидев, как это может сделать вашу команду данных более эффективной и безопасной. Как всегда, если вам нужна помощь или у вас есть вопросы, Форум сообщества dbt и Slack здесь, чтобы поддержать вас. Удачного моделирования!