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

В проекте «Гонца» уже десяток моделей. В каждой витрине первой строкой стоит {{ config(materialized='table') }}. Теперь Отто просит перенести витрины в отдельную схему, чтобы дашборды не видели черновики. Править каждый файл долго, и одну витрину обязательно забудешь. Настройки, общие для целой папки, живут в одном месте: в файле dbt_project.yml.

Правила внутреннего распорядка

В офисе есть общие правила: «в переговорных не едят», «в серверной температура 18 градусов». Их не пишут на каждой двери. Висит один лист у входа, а на отдельной двери табличка только там, где правило другое: «в этой переговорной можно с кофе».

dbt_project.yml это лист у входа. Правило для папки действует на все модели в ней, а config() внутри модели это табличка на конкретной двери: она сильнее общего правила.

Конфиг по папкам

Конфиг моделей лежит в разделе models, дальше имя проекта и папки внутри models/:

name: gonets
version: "1.0.0"
profile: gonets

models:
  gonets:
    staging:
      +materialized: view
    intermediate:
      +materialized: ephemeral
    marts:
      +materialized: table
      +schema: marts
      +tags: ["daily"]

Плюс перед ключом говорит dbt: это настройка, а не имя вложенной папки. Без плюса dbt тоже поймёт materialized: view, но с плюсом не перепутать настройку с папкой, которая случайно называется так же.

Кто главнее: config() в самой модели сильнее YAML рядом с моделью, YAML сильнее dbt_project.yml, а более глубокая папка сильнее верхней. Поэтому можно написать общее правило для всех моделей и переопределить его для одной папки.

Теги

Тег это ярлык на модели. Сам по себе он ничего не меняет в базе, зато по нему можно выбрать модели для запуска: dbt run -s tag:daily соберёт только помеченные. Теги, в отличие от материализации, складываются: тег папки и тег из config() модели достанутся ей оба.

Обычно тегами помечают частоту или потребителя: daily, hourly, finance. Ночной DAG «Гонца» сможет собирать то, что нужно к утру, а почасовые модели гонять отдельно.