Конфигурации моделей
Связанная документация
Доступные конфигурации
Конфигурации, специфичные для модели
Конфигурации, специфичные для ресурса, применимы только к одному типу ресурса dbt, а не к нескольким типам ресурсов. Вы можете определить эти настройки в файле проекта (dbt_project.yml
), в файле свойств (models/properties.yml
для моделей, аналогично для других ресурсов) или внутри файла ресурса, используя макрос {{ config() }}
.
Следующие конфигурации, специфичные для ресурса, доступны только для Models:
- Файл проекта
- Файл свойств
- Блок конфигурации
models:
<resource-path>:
+materialized: <materialization_name>
+sql_header: <string>
+on_configuration_change: apply | continue | fail #только для материализованных представлений на поддерживаемых адаптерах
+unique_key: <column_name_or_expression>
version: 2
models:
- name: [<model-name>]
config:
materialized: <materialization_name>
sql_header: <string>
on_configuration_change: apply | continue | fail #только для материализованных представлений на поддерживаемых адаптерах
unique_key: <column_name_or_expression>
{{ config(
materialized="<materialization_name>",
sql_header="<string>"
on_configuration_change: apply | continue | fail #только для материализованных представлений на поддерживаемых адаптерах
unique_key='column_name_or_expression'
) }}
Общие конфигурации
Общие конфигурации предоставляют более широкие операционные настройки, применимые к нескольким типам ресурсов. Как и конфигурации, специфичные для ресурсов, они также могут быть заданы в файле проекта, файлах свойств или в файлах, специфичных для ресурсов.
- Файл проекта
- Файл свойств
- Блок конфигурации
Конфигурации, специфичные для хранилища
- Конфигурации BigQuery
- Конфигурации Redshift
- Конфигурации Snowflake
- Конфигурации Databricks
- Конфигурации Spark
Конфигурирование моделей
Конфигурации моделей применяются иерархически. Вы можете настраивать модели как в установленном пакете, так и в вашем проекте dbt следующими способами, перечисленными в порядке приоритета:
- Используя макрос Jinja
config()
внутри модели. - Используя
config
свойство ресурса в файле.yml
. - Из файла проекта
dbt_project.yml
, под ключомmodels:
. В этом случае модель, вложенная глубже всего, будет иметь наивысший приоритет.
Наиболее специфичная конфигурация всегда имеет приоритет. В файле проекта, например, конфигурации, примененные к подкаталогу marketing
, будут иметь приоритет над конфигурациями, примененными ко всему проекту jaffle_shop
. Чтобы применить конфигурацию к модели или каталогу моделей, определите путь ресурса как вложенные ключи словаря.
Конфигурации моделей в вашем корневом проекте dbt имеют высший приоритет по сравнению с конфигурациями в установленных пакетах. Это позволяет вам переопределять конфигурации установленных пакетов, предоставляя больше контроля над вашими запусками dbt.
Пример
Конфигурирование каталогов моделей в dbt_project.yml
Чтобы настроить модели в вашем файле dbt_project.yml
, используйте опцию конфигурации models:
. Убедитесь, что вы указали пространство имен для ваших конфигураций в вашем проекте (показано ниже):
name: dbt_labs
models:
# Убедитесь, что вы указали пространство имен для конфигураций моделей в вашем проекте
dbt_labs:
# Это настраивает модели, найденные в models/events/
events:
+enabled: true
+materialized: view
# Это настраивает модели, найденные в models/events/base
# Эти модели будут эфемерными, так как конфигурация выше будет переопределена
base:
+materialized: ephemeral
...
Применение конфигураций только к одной модели
Некоторые типы конфигураций специфичны для конкретной модели. В этих случаях размещение конфигураций в файле dbt_project.yml
может быть неудобным. Вместо этого вы можете указать эти конфигурации в начале файла модели .sql
или в его индивидуальных YAML-свойствах.
{{
config(
materialized = "table",
sort = 'event_time',
dist = 'event_id'
)
}}
select * from ...
version: 2
models:
- name: base_events
config:
materialized: table
sort: event_time
dist: event_id