В прошлом уроке мы разобрали, что такое dbt Cloud в целом. Теперь — конкретно по компонентам, с которыми ты будешь работать каждый день: IDE, Jobs, Explorer.

Cloud IDE — браузерная разработка

Cloud IDE — это полноценная IDE в браузере: дерево файлов, редактор с подсветкой Jinja, terminal, preview результатов, git-интеграция. Заменяет связку «VS Code + локальный venv + dbt CLI».

Что умеет Cloud IDE сверху над обычным VS Code

1. Autocomplete для ref() и source() — печатаешь {{ ref(' и видишь dropdown со всеми моделями проекта. Снижает опечатки.

2. Inline compile — кнопка Compile в редакторе мгновенно показывает финальный SQL без dbt compile в терминале.

3. Preview tab — кнопка Preview выполняет SELECT * FROM (модель) LIMIT 100 и показывает результаты в табличке справа. Эквивалент dbt show, но удобнее.

4. Lineage tab — для открытой модели показывает её локальный DAG: upstream и downstream.

5. Git inline — внизу слева текущая ветка. Клик -> commit, push, create PR. Не выходя из IDE.

Cloud IDE limitations

• Нет твоих расширений VS Code (sqlfluff-LSP, etc.) — только встроенные.
• Не работает офлайн — это веб-приложение.
• Не поддерживает DuckDB — только облачные warehouses.
• Кеш браузера иногда показывает старые версии файлов после git pull.

Для тех, кто привык к локальному VS Code с custom-конфигом — Cloud IDE может казаться ограниченной. Для junior, который только начал — это удобно: ничего не настраиваешь, всё уже работает.

Jobs — scheduler в UI

Jobs — это встроенный планировщик. Ты определяешь:

• Что запускать (dbt build --select tag:nightly)
• Когда (cron expression или triggers)
• На каком target (prod, staging)
• Какие нотификации

Анатомия Job

В UI Job выглядит как:

Name: Production Nightly Build
Environment: prod
Commands:
  - dbt source freshness
  - dbt build --select +tag:nightly
Schedule: 0 2 * * *  (каждый день в 02:00 UTC)
Triggers:
  - on schedule
  - on PR merge to main
Notifications:
  - Slack #data-alerts on failure
  - Email [email protected] on success+failure

Когда наступает 02:00 UTC:

1. Cloud orchestrator берёт твой git-репо (последний commit main)
2. Запускает контейнер с dbt-core нужной версии
3. Выполняет команды последовательно
4. Шлёт логи в Cloud (видимые в UI)
5. Шлёт нотификации по конфигу
6. Сохраняет run_results.json и manifest.json как production-baseline

После Job можно:

• Открыть UI и увидеть статус (success/failure)
• Посмотреть terminal-вывод
• Скачать manifest.json (для slim CI)
• Перезапустить (равнозначно dbt retry)

Типичные Jobs в production

1. Production Nightly — dbt source freshness && dbt build. В 2:00 каждой ночью. Алерт в Slack.

2. Hourly Incremental — dbt build --select config.materialized:incremental tag:hourly. Каждый час 00:15.

3. CI Check (PR) — триггер «on PR open / update». Запускает dbt build --select state:modified+ --state ./prod-manifest. Slim CI.

4. Documentation Refresh — dbt docs generate. Раз в день, обновляет каталог в Explorer.

5. Source Freshness Check — dbt source freshness. Каждый час, мониторит ingestion-пайплайны.

В крупных компаниях Jobs насчитывают десятки. Менеджмент через UI делает их доступными любому аналитику.

Alternatives: Airflow / Dagster / Prefect

Если у компании уже есть Airflow (или Dagster, или Prefect), Jobs становятся дубликатом. В этом случае dbt запускают через Airflow-operator (dbt-airflow, astronomer-cosmos), который даёт более тонкий контроль.

Сравнение:

Junior это полезно знать, чтобы понимать выбор архитектуры в новой компании. На собеседованиях спросят: «У вас в Cloud Jobs или Airflow?» — это сразу подсказка, какого размера команда.

Explorer — lineage UI

Explorer — это главный потребительский интерфейс dbt-проекта для не-разработчиков (PM, аналитики бизнеса, data governance).

[Explorer Home]
  ├─ Project: jaffle_shop
  ├─ 200 models, 8 sources, 50 tests
  ├─ Last build: 2 hours ago, 198 success / 2 fail
  └─ Quick links: lineage, models list, search

Главное окно — lineage graph: интерактивный DAG. Можно zoom-in/out, кликать на узлы, фильтровать по тегам и группам.

Что Explorer умеет

1. Полный DAG — все sources, models, snapshots, tests. С линиями между ними.

2. Click on model — открывается панель:

   • Description модели
   • Колонки и их типы (из catalog.json)
   • Tests (passing/failing)
   • Recent runs: timing, статусы
   • Upstream/downstream
   • Compiled SQL

3. Search — по имени, тегу, тегу владельца, domain.

4. Filters:

   • По tag/group/domain
   • По типу (model/test/source/exposure)
   • По статусу последнего run (success/failure)

5. Compare versions (платно) — посмотреть diff модели между двумя commit’ами с lineage-эффектом.

Зачем это нужно

Сценарии:

• PM спрашивает: «У нас в дешборде customer_count показывает 1500, а в SQL-запросе 1480 — какая правда?» -> открыли Explorer, нашли модель customers, увидели, что она зависит от stg_customers через filter where deleted_at is null. Дешборд использует deleted_at, SQL-запрос — нет. Объяснили разницу.

• Аналитик меняет staging: «Если я добавлю колонку customer_segment в stg_customers, какие маркетинг-модели затронутся?» -> Explorer, найти stg_customers, посмотреть downstream -> видно: 12 маркетинг-моделей. План работы понятен.

• Compliance: «Какие модели содержат PII-данные? Какие из них используются в публичных дешбордах?» -> Explorer, filter по tag:pii, посмотреть exposures.

• Onboarding нового аналитика: «Покажи мне, как у нас данные текут от raw к finance dashboard» -> Explorer, lineage от source jaffle.orders до exposure monthly_revenue_dashboard. Стрелки на 5 моделях, понятно сразу.

Альтернатива: dbt docs serve

В dbt-core open-source есть бесплатная альтернатива — dbt docs generate && dbt docs serve. Запускает локальный веб-сервер с тем же lineage-графом и каталогом колонок.

Сравнение:

Для команды до 5 человек обычно хватает dbt docs serve, поднятый на корпоративном веб-сервере или в IDE. Для команд 10+ Explorer окупается удобством для non-engineering ролей.

Что junior должен освоить из Cloud в первую неделю

Если попал в компанию с Cloud:

1. Cloud IDE workflow: открыть файл -> отредактировать -> Compile -> Preview -> commit -> push -> create PR. Это базовый цикл.

2. Поиск в Explorer: найти модель по имени, посмотреть её lineage, прочитать description, увидеть status.

3. Чтение Job runs: открыть последний Production Nightly run, найти причину провала в terminal output, найти упавшую модель.

4. Trigger manual run: запустить Job вручную через UI («Run Now»). Часто нужно после фикса, чтобы не ждать ночи.

5. Branch и PR workflow: создать ветку в IDE, сделать изменения, открыть PR, посмотреть CI check.

Всё это интуитивно после dbt-core CLI — те же команды, только в браузере.

Попробуй сам

В free Developer tier:

1. Открой Cloud IDE, сделай в models/marts/customers.sql любое изменение (например, добавь колонку created_year = year(created_at)).

2. Нажми Compile — увидь финальный SQL. Нажми Preview — увидь первые строки результата.

3. Commit изменения через UI, push, открой PR через интерфейс.

4. Создай Job: «dbt build --select customers». Запусти Run Now. Открой run в UI, посмотри terminal output.

5. Открой Explorer, найди модель customers, посмотри её lineage, перейди в upstream-модель stg_jaffle__customers.

Чек-лист

• Cloud IDE = браузерный VS Code для dbt. Autocomplete ref/source, кнопки Compile/Run/Preview/Test.
• Cloud IDE limitations: нет твоих расширений, не работает офлайн, не поддерживает DuckDB.
• Jobs = scheduler в UI. cron + triggers + notifications в одном месте.
• Jobs alternatives: Airflow (большие команды с DevOps), Dagster, Prefect.
• Explorer = интерактивный lineage граф + каталог моделей. Для non-engineering ролей (PM, business).
• Explorer vs dbt docs serve: первый управляемый и с run history, второй бесплатный и локальный.
• Junior workflow в первую неделю: IDE для разработки, Jobs для запуска, Explorer для навигации.