Окружения dev/prod и dbt в Airflow

Где dbt заканчивает свою работу и начинается оркестратор, который решает, когда её запускать.

Оркестрация — управление расписанием и зависимостями шагов пайплайна (загрузка, dbt-трансформация, выгрузка); внутри ELT dbt отвечает за трансформацию, а оркестратор (например Airflow) — за то, когда и в каком порядке всё запускать.

Окружения dev и prod

Мы уже видели цели в profiles.yml. На практике это даёт два изолированных окружения. В dev разработчик строит модели в личной схеме, экспериментирует, может ограничить данные неделей через Jinja-условие — никому не мешая. В prod те же модели строятся в общей схеме на полных данных по расписанию. Один код, разные таргеты.

# Разработка: личная схема, можно урезать данные
dbt build --target dev

# Продакшен: общая схема, полные данные
dbt build --target prod

Зачем нужен оркестратор

dbt сам по себе не знает, когда ему запускаться и что должно произойти до него. Полный ELT-пайплайн — это цепочка: сначала Fivetran/Airbyte загрузит сырьё (E, L), потом dbt трансформирует (T), потом, может быть, что-то выгрузит результат в CRM. Эту цепочку и её расписание держит оркестратор — чаще всего Apache Airflow (ему посвящён отдельный курс на сайте).

Airflow DAG (ежедневно в 03:00):
  [1] загрузка сырья (Fivetran/Airbyte)
        |
        v
  [2] dbt build  (трансформация + тесты)
        |
        v
  [3] dbt docs generate (обновить документацию)
        |
        v
  [4] уведомление / выгрузка результата

Как запускают dbt из Airflow

Простейший способ — выполнить команду dbt как шаг (через BashOperator или специальный оператор):

# Псевдо-схема задачи Airflow (для чтения)
load_raw   = FivetranOperator(...)
dbt_build  = BashOperator(
    bash_command="cd /opt/dbt_project && dbt build --target prod"
)
load_raw >> dbt_build   # сначала загрузка, потом dbt

Для более тонкой связи есть библиотеки (например astronomer-cosmos), которые превращают каждую модель dbt в отдельную задачу Airflow, чтобы видеть прогресс по моделям и перезапускать упавшие точечно. Но идея та же: оркестратор вызывает dbt и ждёт его завершения.

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

С точки зрения Airflow dbt — это процесс, который запускают командой и чей код возврата (успех/провал) определяет, идти ли дальше по DAG оркестратора. dbt внутри себя строит свой DAG моделей и выполняет его. Получается два уровня графов: внешний (оркестратор: загрузка → dbt → выгрузка) и внутренний (dbt: staging → marts). Разделение ответственности чёткое: оркестратор отвечает за «когда и в каком порядке шаги», dbt — за «как трансформировать».

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

Запускать dbt раньше загрузки. Без зависимости в Airflow dbt построит витрины на вчерашних данных — порядок шагов задаёт оркестратор.
Считать Airflow заменой dbt (или наоборот). Это разные слои: оркестрация и трансформация, они дополняют друг друга.
Использовать run вместо build в проде-пайплайне. В оркестрации особенно важно, чтобы тесты падали до выгрузки результата.

Итоги

Окружения dev/prod — это разные таргеты одного кода: личная схема для разработки, общая для прода.
Оркестратор (Airflow) решает, когда и в каком порядке запускать шаги ELT; dbt — это шаг T.
dbt вызывают как команду (dbt build --target prod); код возврата управляет дальнейшим ходом DAG оркестратора.