Cloud IDE / Studio и Jobs

В этом уроке разбираем, как устроены два главных компонента Cloud / Studio — IDE и Jobs. Это то, что вы будете видеть и трогать каждый день, если ваша команда переходит с Core на Cloud.

Environments в Studio

Перед тем как обсуждать IDE и Jobs, нужно понять модель environments. В Cloud environment — это именованная конфигурация подключения к warehouse + dbt-параметров. Типичный набор для production-команды:

Environment определяет:

• Warehouse connection (URL, credentials через Secrets)
• Default schema / database
• dbt version (1.10 / 1.11 / Fusion)
• Default branch (для deploy)
• Whether to use defer

Это аналог profiles.yml в Core, только с UI и встроенным secrets management.

Studio IDE: что в нём есть

Главные фичи IDE для middle-инженера

Автокомплит. Когда вы пишете {{ ref('') }}, Studio предлагает список моделей из проекта. Когда пишете SELECT col FROM, и target — {{ ref('stg_customers') }}, Studio знает колонки из manifest.json и предлагает их. Это снимает 30-50% опечаток.

Compile preview live. Сохранили файл — справа сразу видите скомпилированный SQL. Это критично, когда вы пишете сложные Jinja-макросы или используете dispatch — сразу видите, какой ветке dispatch’а попали, что развернулось из for-цикла.

Lineage view встроен. Когда вы открываете модель, в верхнем углу есть кнопка “Lineage”. Открывает mini-DAG: upstream + downstream. Полезно для понимания blast radius перед изменением.

Git встроен. Branching, commits, PR создаются прямо в IDE. Для junior это снижает порог входа (не нужно учить git CLI). Для middle часто избыточно — VSCode + терминал быстрее.

Чего в Studio IDE нет

• Расширений: вы не поставите свой LSP или линтер. Что есть — то есть.
• Кастомных тем / горячих клавиш beyond basic.
• Offline режима: нет интернета — нет работы.
• Multi-cursor editing на уровне зрелых IDE (хотя базовое есть).

Для разработчиков, привыкших к VSCode / Neovim — Studio чувствуется ограниченным. Для аналитиков без локального dev-окружения — отличный вход.

Defer to production toggle

Defer — одна из самых полезных фич Cloud для team-workflow. Идея: когда вы делаете изменения в одной модели, не пересобирать всё upstream — пользоваться production-схемами для зависимостей.

Как defer работает технически

Когда вы делаете dbt run --defer --select +my_model+, dbt:

1. Компилирует все модели в селекторе как обычно.
2. Но ref() резолвится не в вашу dev-схему, а в production-схему (которая указана в manifest.json от prod-deploy).
3. Если ref()ит модель, которой нет в вашем dev-окружении, dbt берёт её из prod.

В Core defer требует ручной выкладки manifest.json после каждого prod-deploy: вы пишете в S3 или храните в git, потом запускаете dbt run --defer --state path/to/prod_manifest --select state:modified+.

В Cloud / Studio есть toggle “Defer to production” в Development environment. Включили — Studio автоматически использует manifest от последнего успешного prod-deploy job для defer. Никаких manual S3 sync. Это и есть главная ценность Cloud в context’е defer: автоматизация state-management.

Защита от случайной перезаписи prod

Defer резолвит ref() в prod-схему только для чтения. Когда вы делаете dbt run --select my_model, target.schema будет ваш dev (например, pr_lev_123). Никаких записей в prod schemas не идёт. Это безопасный режим.

Что может пойти не так: если в вашем dev-проекте generate_schema_name написан так, что для модели возвращает то же имя что в prod — defer не спасёт от перезаписи. Это редкий случай, но в Multi-environment модуле мы разберём защиту от него.

Jobs: что это и какие бывают

Job в Cloud — это именованная конфигурация запуска dbt-команд по расписанию или триггеру. Типизация по назначению:

Deploy jobs

Регулярные запуски dbt build на production. Конфигурация:

• Environment: Production
• Commands: dbt build --select tag:daily (или специфичные команды)
• Schedule: cron 0 6 * * * (каждый день в 6:00 UTC)
• Targets: prod
• Notifications: Slack #data-alerts при fail/cancel

Это замена Airflow для большинства простых случаев. Без сложных межсистемных зависимостей (Fivetran + dbt + reverse ETL) Jobs хватает.

CI jobs

Запускаются на pull request: validate что изменённые модели и их downstream работают. Конфигурация:

• Environment: CI
• Commands: dbt build --select state:modified+ --defer --state ./prod_state (defer берёт manifest от prod)
• Trigger: webhook от GitHub (PR opened / synchronized)
• Notifications: статус в PR (через GitHub integration)

CI jobs используют Slim CI паттерн: только модели, которые изменились в PR (state:modified) + их downstream (+). Это в разы быстрее, чем dbt build всего проекта.

Triggered jobs

Запускаются не по расписанию, а по событию:

• API call: POST /jobs/{job_id}/run (из Airflow / Dagster / кастомного оркестратора)
• Webhook: внешняя система триггерит (например, Fivetran sync finished -> dbt build)
• Manual: кнопка “Run now” в UI

Это полезно когда расписание не подходит — например, dbt должен запуститься “когда Fivetran закончит” а не “в 6:00”.

Анатомия Job: пошаговая конфигурация

Возьмём пример: production deploy job для команды e-commerce аналитики.

Commands в Job

Это не одна команда, а список команд, выполняющихся последовательно. Типичная prod-конфигурация:

1. dbt source freshness
2. dbt seed
3. dbt run --select state:modified+ --defer --state ./prod_state
4. dbt test --select state:modified+ --defer --state ./prod_state
5. dbt docs generate

Каждая команда — отдельный step. Если шаг fail, по умолчанию весь job помечается как failed, но последующие шаги всё равно выполняются (это можно изменить настройкой “continue on error”).

Альтернативный подход — одна команда dbt build. dbt build объединяет run + test + snapshot + seed в одну DAG-обходку: для каждой модели сначала run, потом test, и если test fail — downstream не запускается. Это семантически правильнее, но менее гибко с точки зрения step-уровневой конфигурации.

Schedule и Triggers

Schedule — cron-выражение. Cloud валидирует синтаксис в UI: показывает следующие N запусков, помогает не ошибиться.

Triggers — события, которые запускают job помимо schedule:

• Continuous trigger (Cloud Team+): запускать сразу после успешного завершения другого job (chain jobs)
• Webhook trigger: внешний POST на endpoint Cloud запускает job. Подписываете Fivetran webhook, dbt запускается после успешной синхронизации
• Manual trigger: API call или кнопка в UI

Можно комбинировать: schedule + webhook + manual.

Notifications

Конфигурация per-event:

• On Success: список emails / Slack каналов
• On Failure: список emails / Slack каналов
• On Cancellation: список (job был отменён вручную или job-dependency cancel’нулась)

Webhooks отдельная категория — туда уходят все события для интеграций с внешними системами (PagerDuty, OpsGenie, кастомные дашборды). Подробнее в уроке 3 этого модуля.

Practical workflow: команда из 5 человек

Чтобы связать всё вместе, разберём типичный workflow команды из 5 analytics-инженеров на Cloud:

1. Devs работают в Studio или VSCode, defer-to-production включен. Изменения в feature branches.
2. На каждый PR срабатывает CI job (dbt build --select state:modified+ --defer). 5-15 минут на средний PR.
3. PR review — code review SQL, проверка lineage view в Explorer (urok 3).
4. Merge в main триггерит deploy job (опционально, или просто ждём schedule).
5. Production deploy job в 6:00 UTC: dbt source freshness -> dbt build.
6. Notifications: Slack-канал #data-alerts получает уведомления о failures.
7. Explorer показывает последние runs, performance, freshness — для observability.

Это — стандартный mature workflow для команд 3-15 человек. Размеры команды больше 15 обычно переходят на dbt Mesh с несколькими проектами.

Сравнение: то же самое в Core

Чтобы понимать ценность Cloud, важно представлять, что нужно собрать руками на Core для эквивалентного результата.

Что важно понимать: всё это можно собрать на Core. Вопрос — стоимость engineering-time. Команды с DevOps это собирают за 1-2 спринта; команды без DevOps — никогда не доходят до production-grade.

Что middle-инженер должен уметь

1. Объяснить, что такое environment в Cloud и почему он отличается от profiles.yml в Core (UI vs file, secrets management, version control).
2. Назвать 5+ возможностей Studio IDE и осознанно решать, переходить ли с VSCode.
3. Описать механику defer to production: что резолвится в prod, что в dev, как это автоматизировано в Cloud.
4. Сконфигурировать deploy job: commands, schedule, notifications, run config.
5. Объяснить разницу между deploy job и CI job, и какие commands в каждом типичны.
6. Назвать эквиваленты Cloud-фич на Core (для аргументации, когда платить).

Попробуй сам

Если у вас есть доступ к Cloud Developer free tier:

1. Создайте Development environment с подключением к Postgres (или любому support’ed warehouse).
2. Создайте простой проект из 2-3 моделей.
3. Включите “Defer to production” toggle (даже без prod-job — Cloud просто скажет “no manifest available”, но настройка будет видна).
4. Создайте deploy job с командой dbt build и cron 0 6 * * *.
5. Запустите job вручную, посмотрите Logs panel.

Не обязательно платить — для feel’а Cloud достаточно Developer tier.

Если Cloud недоступен — пересмотрите свой Core-проект и составьте список: что бы вам пришлось собрать, если бы вы переходили на эквивалентную Cloud-конфигурацию? Сколько часов на сборку?