Среды развертывания

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

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

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

Узнайте, как управлять средами dbt

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

Подробнее о различиях между средами разработки и развертывания читайте в разделе Среды dbt.

Существует три типа сред развертывания:

Производственная: Среда для преобразования данных и построения конвейеров для производственного использования.
Промежуточная: Среда для работы с производственными инструментами с ограничением доступа к производственным данным.
Общая: Среда общего назначения для разработки развертывания.

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

Создание среды развертывания

Чтобы создать новое окружение развёртывания dbt, перейдите в Deploy → Environments, а затем нажмите Create Environment. В качестве типа окружения выберите Deployment. Этот вариант будет недоступен (подсвечен серым), если у вас уже есть окружение разработки.

Перейдите в Deploy -> Environments, чтобы создать среду развертывания

Установить как производственную среду

В dbt каждый проект может иметь одну назначенную среду развертывания, которая служит его production‑средой. Эта production‑среда критически важна для использования таких возможностей, как Catalog и межпроектные ссылки. Она выступает в роли источника истины о production‑состоянии проекта в dbt.

Установите вашу производственную среду в качестве среды по умолчанию в настройках среды

Семантический слой

Для клиентов, использующих Semantic Layer, следующий раздел настроек окружения посвящён конфигурациям Semantic Layer. В руководстве по настройке The Semantic Layer setup guide приведены самые актуальные инструкции по установке и настройке.

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

Промежуточная среда

Используйте Staging‑окружение, чтобы предоставить разработчикам доступ к workflow развертывания и инструментам, одновременно контролируя доступ к production‑данным. Staging‑окружения позволяют добиться более тонкого управления правами доступа, подключениями к хранилищу данных и изоляцией данных — в рамках одного проекта в dbt.

Git-рабочий процесс

Вы можете подойти к этому несколькими способами, но самый простой — это настроить промежуточную среду с долгоживущей веткой (например, staging), аналогичной, но отдельной от основной ветки (например, main).

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

Некоторые клиенты предпочитают подключать разработку и промежуточную среду к своей ветке main, а затем регулярно создавать ветки релизов (ежедневно или еженедельно), которые питаются в производственную среду.

Зачем использовать промежуточную среду

Основные причины использования промежуточной среды:

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

Условная конфигурация источников позволяет вам указывать на "prod" или "non-prod" исходные данные в зависимости от среды, в которой вы работаете. Например, этот источник будет указывать на <DATABASE>.sensitive_source.table_with_pii, где <DATABASE> динамически разрешается на основе переменной среды.

models/sources.yml

sources:
  - name: sensitive_source
    database: "{{ env_var('SENSITIVE_SOURCE_DATABASE') }}"
    tables:
      - name: table_with_pii

Существует ровно один источник (sensitive_source), и все downstream dbt модели выбирают из него как {{ source('sensitive_source', 'table_with_pii') }}. Код в вашем проекте и форма DAG остаются последовательными во всех средах. Настраивая это таким образом, а не дублируя источники, вы получаете некоторые важные преимущества.

Перекрестные ссылки между проектами в dbt Mesh: Предположим, у вас есть Project B, который является downstream от Project A с настроенными перекрестными ссылками между проектами в моделях. Когда разработчики работают в IDE для Project B, перекрестные ссылки будут разрешаться в промежуточную среду Project A, а не в производственную. Вы получите те же результаты с этими ссылками, когда задачи выполняются в промежуточной среде. Только производственная среда будет ссылаться на производственные данные, сохраняя данные и доступ изолированными без необходимости в отдельных проектах.

Быстрая разработка с помощью отложенного выполнения: Если у Project B также есть промежуточное развертывание, то ссылки на не построенные upstream модели в Project B будут разрешаться в эту среду, используя отложенное выполнение, а не разрешаться в модели в производственной среде. Это экономит время разработчиков и затраты на хранилище, сохраняя при этом четкое разделение сред.

Наконец, для окружения Staging предусмотрено собственное представление в Catalog, которое дает вам полную картину данных как из prod, так и из pre-prod.

Исследуйте в промежуточной среде

Создание staging‑окружения

В dbt перейдите в Deploy -> Environments, затем нажмите Create Environment. Выберите Deployment в качестве типа окружения. Эта опция будет неактивна (серой), если у вас уже есть окружение разработки.

Создайте staging‑окружение

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

Мы рекомендуем, чтобы учётные данные хранилища данных принадлежали выделенному пользователю или service principal.

Подключение для развертывания

Подключения к хранилищу данных

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

В каждом проекте может быть несколько подключений (аккаунт Snowflake, хост Redshift, проект BigQuery, хост Databricks и т. д.) одного и того же типа хранилища. Некоторые детали этого подключения (databases/schemas и т. п.) можно переопределить в этом разделе настроек окружения dbt.

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

Для всех хранилищ используйте extended attributes, чтобы переопределить отсутствующие или неактивные (подсвеченные серым) настройки.

Этот раздел не отображается, если вы используете Postgres, так как все значения берутся из подключения проекта. Используйте extended attributes, чтобы переопределить эти значения.

Учетные данные для развертывания

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

Для всех хранилищ используйте extended attributes, чтобы переопределить отсутствующие или неактивные (подсвеченные серым) настройки. Для учётных данных мы рекомендуем оборачивать extended attributes в environment variables (password: '{{ env_var(''DBT_ENV_SECRET_PASSWORD'') }}'), чтобы секретное значение не отображалось в текстовом поле и логах.

Настройки deployment credentials для Postgres

Редактируемые поля

Username: имя пользователя Postgres (скорее всего service account)
Password: пароль Postgres для указанного пользователя
Schema: целевая схема

Настройки deployment credentials для Bigquery

Редактируемые поля

Dataset: целевой датасет

Используйте extended attributes, чтобы переопределять отсутствующие или неактивные (серые) настройки. Для учётных данных мы рекомендуем оборачивать extended attributes в environment variables (password: '{{ env_var(''DBT_ENV_SECRET_PASSWORD'') }}'), чтобы не отображать значение секрета в текстовом поле и логах.

Удаление окружения

Удаление окружения автоматически удаляет связанные с ним задания (job). Если вы хотите сохранить эти задания, сначала переместите их в другое окружение.

Выполните следующие шаги, чтобы удалить окружение в dbt:

Нажмите Deploy в верхней навигационной панели, затем нажмите Environments.
Выберите окружение, которое вы хотите удалить.
В правом верхнем углу страницы нажмите Settings, затем нажмите Edit.
Прокрутите страницу вниз и нажмите Delete, чтобы удалить окружение.

Delete an environment

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

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

Нашли ошибку?

Создать GitHub Issue

Среды развертывания