Настройка отложенного разрешения ссылок в dbt State
По умолчанию dbt State использует вашу производственную среду для отложенного разрешения ссылок. Настройка требуется только в том случае, если вы хотите изменить это поведение:
-
dbt platform: Чтобы использовать для отложенного разрешения ссылок среду, отличную от среды по умолчанию (например, staging), добавьте
defer-env-idв блокdbt-cloudвdbt_project.yml. Подробнее см. в разделе Настройка dbt platform CLI.dbt_project.ymldbt-cloud:
project-id: <your-project-id>
defer-env-id: <your-environment-id>примечаниеdefer-env-idиспользует манифест. Если задать этот параметр, селекторыstate:*на основе dbt State будут отключены. Дополнительную информацию см. в требованиях в соответствующем разделе. -
Самостоятельно управляемые развертывания: Если у вас нет доступа к манифесту производственной среды или среды развертывания, можно задать
defer_to_targetвprofiles.ymlдля автоматического отложенного разрешения ссылок по мере возможности. Обратите внимание, что у этого подхода есть известные ограничения; см. раздел Ограничения dbt State при работе без манифеста.profiles.ymlmy_project:
outputs:
uat:
type: snowflake
# ... connection settings
defer_to_target: stagingВ самостоятельно управляемых развертываниях можно использовать селекторы
state:*на основе dbt State, которые сравнивают каждый узел с его собственным последним выполнением, а не сmanifest.jsonотдельного задания. Чтобы использовать эту возможность, подключите проект к dbt platform.
Также можно передать --state или --defer-state, чтобы явно указать dbt State конкретный файл manifest.json.
Если вы переопределили макросы generate_*_name(), используя значения времени выполнения (например, переменные окружения, пути к файлам или даты), предоставьте файл manifest.json, чтобы dbt State мог корректно определять расположение объектов. Без этого файла расположение объектов определяется по вашим макросам и целевой конфигурации профиля, что в таких случаях может приводить к ошибкам. См. раздел Ограничения dbt State при работе без манифеста.
Селекторы state:* на основе dbt State Бета-версия
Когда dbt State включен, селекторы state:* могут использовать dbt State как источник сравнения вместо отдельного файла manifest.json из последнего запуска задания. Каждый узел (модели, снимки, seed-файлы и тесты) сравнивается со своим собственным последним выполнением в среде defer_to_target (по умолчанию: prod), поэтому узел выбирается как измененный только в том случае, если изменилась его собственная логика, независимо от того, какое задание выполняло его последним.
Эта возможность предназначена для самостоятельно управляемых развертываний: вы самостоятельно организуете запуски dbt (например, с помощью Airflow или GitHub Actions), а не используете задания dbt platform. При этом для работы с dbt State по-прежнему требуется аутентификация в dbt platform с использованием project-id.
Предварительные требования
- Для вашего проекта включен dbt State.
- В блоке
dbt-cloudвdbt_project.ymlзаданproject-id:
dbt-cloud:
project-id: <your-project-id>
При оркестрации с помощью dbt platform каждое задание создает manifest.json, поэтому dbt State использует его для сравнений state:* вместо истории выполнения отдельных узлов.
Укажите проект или организацию
Если у вас несколько проектов или организаций, использующих dbt State, настройте блок dbt-cloud в dbt_project.yml, чтобы dbt State знал, какой проект или какую организацию использовать:
-
Для пользователей dbt platform с несколькими проектами: Добавьте
project-id, чтобы указать, какой проект должен использовать dbt State.dbt_project.ymldbt-cloud:
project-id: <your-project-id> -
Для самостоятельно управляемых развертываний с несколькими организациями dbt State: Добавьте
state-org-id, чтобы указать, какую организацию должен использовать dbt State.dbt_project.ymldbt-cloud:
state-org-id: <your-org-id>