Explorer, Notifications и Webhooks

Три инструмента Cloud / Studio, которые делают dbt-проект observable и операционным: Explorer (что произошло, где, кто владеет), Notifications (как узнать о проблемах), Webhooks (как интегрироваться с внешними системами).

Что такое Explorer

dbt Explorer — это web-приложение поверх dbt artifacts (manifest.json, run_results.json, catalog.json), которое автоматически обновляется после каждого Job. Если в Core вы запускали dbt docs generate и смотрели локальный dbt docs serve, то Explorer — это product’изированная версия этого опыта плюс performance / ownership / lineage cross-project.

Что показывает Explorer

Lineage Graph

Самая видимая фича Explorer. Это не просто статичный DAG — это interactive граф со следующими возможностями:

• Зум и pan по графу с сотнями моделей
• Фокус на ноде: клик на модель — затемняются все, кроме upstream и downstream данной
• Фильтры: по tag, by owner, by domain (groups), by materialization
• Cross-project lineage (если Mesh): видны ref’ы из других проектов
• Поиск моделей по имени: моментальная навигация

Полезность для middle-инженера: понимание blast radius перед изменением. Когда вы хотите изменить колонку в stg_customers, Lineage показывает всё downstream — какие marts затронутся, какие dashboards, какие ML jobs. Это превращает страшное “что я сломаю?” в количественный “47 моделей и 3 dashboards”.

Model details: ownership и metadata

Per-model страница показывает:

• Description из _models.yml
• Columns с типами и description
• Tests: какие применены, последний статус
• Refresh time: когда модель последний раз пересчитывалась
• Last run: статус + длительность
• Owner: через meta: в yml или через group ownership
• Tags: для фильтрации и категоризации

Ownership — критическая фича для команд 10+ человек. Без неё каждое падение теста превращается в “кто это написал? кто chargeable за фикс?”. С ownership через meta: { owner: '[email protected]' } алерты адресные.

Sources health

Sources в dbt — это внешние таблицы (Fivetran-loaded, Kafka-loaded, raw schemas). Source freshness в dbt — это проверка “когда last обновлены”.

Explorer Sources показывает:

• Статус freshness: ok / warn / error / not configured
• Last loaded at: timestamp последнего update
• Freshness rule из yml: freshness: { warn_after: { count: 12, period: hour }, error_after: { count: 24, period: hour } }

Без этого freshness-данные просто лежат в run_results.json и никто их не смотрит.

Tests status

Все тесты проекта в одном месте:

• Passed / Failed / Warned
• Last run timestamp
• Stored failures (если включён store_failures: true) — можно кликнуть и увидеть сами битые строки

Дрилл-даун до stored failures особенно полезен. В Core это вы запускаете dbt run-operation или ищете таблицу в schema dbt_test__audit. В Cloud — клик -> видите примеры записей.

Exposures

Exposures в dbt — это первоклассные узлы DAG, представляющие downstream-системы: dashboards, ML jobs, reports. Декларируются в yml:

exposures:
  - name: weekly_revenue_dashboard
    type: dashboard
    owner: { email: '[email protected]' }
    depends_on: [ref('mart_revenue')]

Explorer показывает их в lineage и позволяет, кликнув на exposure, увидеть upstream-модели. Это инвертирует мышление: не “какие модели у меня есть”, а “от чего зависит этот dashboard”.

Performance

Per-model страница имеет таб Performance с графиком execution time по времени. Видно тренды: модель росла линейно с данными или резко скакнула. Также видны rows processed, и (если warehouse Snowflake / BigQuery) — credits / slot-time.

Это пересекается с Cost Insights (отдельный урок 4), но в Explorer view больше про “какая модель медленнее всех” а в Cost Insights про “сколько денег”.

Job history

Хронология всех runs:

• По jobs (Production deploy, CI job)
• По времени
• С статусом и длительностью
• Кто запустил (для manual)

Полезно для post-mortem: “что произошло в 6:00 утра вчера”. Видны логи каждого step.

Notifications: email и Slack

Notifications — система alerts, встроенная в Cloud. Конфигурируется per-environment или per-job. События:

Каналы:

• Email: список адресов через запятую
• Slack: integration через Slack-app dbt Cloud, выбор канала
• Microsoft Teams: similar to Slack
• Webhooks: HTTP POST на любой URL (см. ниже)

Best practices для Notifications

Не шлите всё всем. Типичная ошибка — единый канал #data-alerts с success+failure всего. Через неделю команда mut’ит канал, потому что 95% сообщений — success. Алерты должны быть actionable.

Лучший паттерн:

• #data-alerts-critical (Slack) — только failure prod jobs
• #data-deployments — success + failure deploy jobs, low-priority
• Email — индивидуальные адреса owner’ов моделей через ownership-mapping (только для critical failures)
• PagerDuty / OpsGenie через webhook — для on-call escalation за пределами рабочих часов

Используйте severity test’ов разумно.

• severity: error (default) — Job упадёт, Notifications fail
• severity: warn — Job пройдёт, но в run_results записан warning. Notifications не fail, но в Explorer виден warning-статус.

Для критичных бизнес-правил — error. Для “может быть проблема, посмотри потом” — warn. Об этом подробнее в уроке 7 курса (Tests in depth).

Notifications в Core: как сравнивается

В Core вам нужно:

• Написать on-failure-callback Python-функцию (если используете Airflow)
• Или handle exit code в GitHub Actions и slack-action
• Или кастомный on-run-end hook в dbt_project.yml с шеллом curl на Slack webhook

Это работает, но требует поддержки. Cloud Notifications работают “из коробки” с UI-конфигурацией.

Webhooks: интеграция с любой системой

Webhooks — это HTTP POST endpoint, который Cloud вызывает при событиях Jobs. В отличие от Notifications (которые идут в email/Slack), webhooks идут на произвольный URL — для интеграции с любой системой, которая принимает HTTP.

Что Cloud шлёт в webhook

Payload — JSON со структурой:

{
  "accountId": 12345,
  "webhooksID": "wbh_abc",
  "eventId": "evt_xyz",
  "timestamp": "2026-05-19T06:42:00Z",
  "eventType": "job.run.completed",
  "data": {
    "jobId": 789,
    "jobName": "Production Deploy",
    "runId": 9876,
    "runStatus": "Success",
    "runStatusMessage": "...",
    "runHumanizedDuration": "12 minutes 4 seconds",
    "runHref": "https://cloud.getdbt.com/...",
    "environmentName": "Production",
    "branch": "main"
  }
}

Event types:

• job.run.started
• job.run.completed (любой terminal status)
• job.run.errored (только fail)
• job.run.cancelled

Webhooks подписываются на subset событий, не обязательно на всё.

Use cases для Webhooks

Типичный пример: PagerDuty escalation

Production prod-job упал. Failure-Notification идёт в Slack. Но в 3:00 ночи Slack-канал muted. Без escalation узнаем только утром — 6 часов даунтайма.

Webhook -> PagerDuty решает:

1. Cloud -> POST webhook payload на PagerDuty endpoint
2. PagerDuty создаёт incident
3. Эскалация: SMS / звонок on-call инженеру

Конфигурация webhook’а в Cloud UI:

• Name: “PagerDuty critical incidents”
• URL: https://events.pagerduty.com/v2/enqueue (PagerDuty Events API)
• Auth: shared secret в header
• Events: job.run.errored
• Filter: только Production environment

PagerDuty принимает custom JSON, нужно adapt’нуть Cloud payload через intermediate Lambda или Zapier. Большинство on-call систем имеют шаблоны для dbt Cloud webhooks.

Verification и security

Cloud подписывает каждый webhook через HMAC-SHA256. В headers идёт X-Dbt-Signature-256: <hmac>. Получатель должен verify подпись:

import hmac, hashlib

def verify_dbt_webhook(payload_bytes, header_sig, shared_secret):
    expected = hmac.new(
        shared_secret.encode(),
        payload_bytes,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(f"sha256={expected}", header_sig)

Без verification злоумышленник, узнавший URL webhook, может слать fake events. Это особенно важно если webhook триггерит дорогие действия (reverse ETL syncs, downstream production deploys).

Связка Explorer + Notifications + Webhooks: production observability

Зрелая команда использует все три инструмента в связке:

1. Explorer — daily check: что упало вчера, какие модели медленные, какие freshness violations.
2. Notifications — Slack-канал для daily awareness (success deploys = тихо, failures = алерт).
3. Webhooks:
   • -> PagerDuty для off-hours critical failures
   • -> Internal data-team dashboard для real-time статусов
   • -> Reverse ETL trigger для downstream-систем
   • -> Data catalog (Atlan/Alation) для sync metadata после deploys

Это observability-стек, который “из коробки” покрывает 90% production-нужд. На Core эквивалентный стек — это месяцы разработки.

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

1. Объяснить, что показывает Explorer (lineage, model details, sources, tests, exposures, performance, ownership, job history) и в каких ситуациях каждый раздел используется.
2. Использовать lineage view для оценки blast radius перед изменением модели.
3. Настроить Notifications: какие события куда (Slack/email), и почему не шлют всё в один канал.
4. Описать механику webhooks: payload, event types, security через HMAC verification.
5. Привести 3+ use case для webhooks и спроектировать integration с одним из них.

Попробуй сам

Если есть доступ к Cloud:

1. Откройте Explorer вашего проекта. Найдите самую центральную модель (та, от которой зависит больше всего downstream). Посмотрите её Performance trend.
2. Настройте Notifications для одного deploy job. Отправьте success в Slack, failure в email.
3. Создайте webhook на https://webhook.site (бесплатный inspect-сервис). Запустите job. Посмотрите, какой JSON приходит. Найдите HMAC signature header.

Без Cloud:

• Откройте https://docs.getdbt.com/docs/deploy/webhooks и изучите формат payload.
• В вашем Core-проекте найдите, где сейчас уведомления (если есть). Сравните с тем, что было бы в Cloud.