dbt_project.yml: конфигурация и теги

Один файл задаёт правила для всего проекта — от материализаций до тегов.

dbt_project.yml — корневой файл конфигурации проекта: имя, профиль, пути к папкам и настройки моделей (материализации, теги, схемы), применяемые иерархически по дереву папок.

Зачем централизованная конфигурация

Прописывать {{ config(materialized='table') }} в каждой витрине утомительно и легко забыть. Логично сказать один раз: «всё в папке marts — это таблицы, всё в staging — представления». Это и делают настройки в dbt_project.yml: они применяются скопом к папкам.

Структура файла

name: 'my_analytics'
version: '1.0.0'
profile: 'my_analytics'        # связь с profiles.yml

model-paths: ["models"]
seed-paths: ["seeds"]
snapshot-paths: ["snapshots"]

models:
  my_analytics:
    staging:
      +materialized: view        # вся папка staging — представления
      +schema: staging
    intermediate:
      +materialized: ephemeral   # промежуточные — встраиваемые
    marts:
      +materialized: table       # витрины — таблицы
      +tags: ['mart']

Префикс + отличает конфигурацию от имени папки/модели. Настройка применяется ко всему поддереву.

Иерархия: общее и частное

Настройки наследуются от папки к подпапке к модели, и более конкретная побеждает. Можно задать материализацию для всей marts, но переопределить её в одной модели через config():

-- models/marts/heavy_report.sql
{{ config(materialized='incremental') }}  -- перебивает table из dbt_project.yml
select ...
УровеньПриоритет
config() в самой моделиВысший
Настройка подпапки в dbt_project.ymlСредний
Настройка верхней папки/проектаНизший

Теги: группировка моделей

Тег — это метка, по которой потом можно выбирать модели для запуска. Удобно помечать «ежедневные», «тяжёлые», «принадлежащие команде финансов»:

# Запустить только модели с тегом mart
dbt run --select tag:mart

# Запустить ежедневные модели
dbt run --select tag:daily

Как работает под капотом

При старте dbt читает dbt_project.yml, разворачивает дерево папок и присваивает каждой модели итоговую конфигурацию, накладывая настройки от общих к частным и завершая config() внутри файла. Эти настройки попадают в manifest.json и определяют, как именно будет построена модель и под какими тегами она доступна для выборки. Так один файл управляет поведением сотен моделей без правки каждой.

Частые ошибки

  • Забыть + перед конфигурацией. Без префикса dbt примет materialized за имя подпапки.
  • Дублировать config в каждой модели. Общие правила выносят в dbt_project.yml по папкам.
  • Несовпадение profile. Значение в dbt_project.yml должно совпадать с ключом в profiles.yml.

Итоги

  • dbt_project.yml задаёт материализации, схемы и теги скопом по папкам через префикс +.
  • Настройки иерархичны: config() в модели перебивает настройку папки.
  • Теги группируют модели для выборочного запуска (--select tag:...).
Проверьте себя
1. Что задаёт настройка +materialized: table в папке marts внутри dbt_project.yml?
AИмя подпапки
BМатериализацию table для всех моделей в этой папке и её подпапках
CТег модели
DСхему хранилища
2. Что победит, если config() в модели и настройка папки задают разную материализацию?
AНастройка папки
Bconfig() внутри самой модели (более конкретный уровень)
CСлучайный выбор
DЗапуск упадёт с ошибкой