dbt — что это и зачем¶

dbt (data build tool) — инструмент, который превращает SQL-запросы в управляемый, тестируемый и документируемый пайплайн трансформации данных. Ты пишешь SELECT — dbt создаёт таблицы и представления, запускает тесты и строит граф зависимостей.

Какую проблему решает dbt¶

Без dbt трансформации в хранилище обычно выглядят так:

• SQL-скрипты в папке, которые кто-то запускает вручную или через cron
• Нет зависимостей: непонятно, в каком порядке запускать
• Нет тестов: ошибки в данных находят аналитики через неделю
• Нет документации: новый человек не понимает, откуда что берётся

dbt решает все четыре проблемы:

Архитектура dbt-проекта¶

my_dbt_project/
├── dbt_project.yml          # Конфигурация проекта
├── models/
│   ├── staging/             # Первичная очистка сырых данных
│   │   ├── stg_orders.sql
│   │   └── stg_users.sql
│   ├── intermediate/        # Промежуточные расчёты
│   │   └── int_order_totals.sql
│   └── marts/               # Финальные витрины для аналитиков
│       └── fct_revenue.sql
├── tests/                   # Кастомные SQL-тесты
├── seeds/                   # CSV-справочники
├── snapshots/               # Историзация (SCD Type 2)
├── macros/                  # Переиспользуемые SQL-шаблоны
└── profiles.yml             # Подключение к БД (вне проекта)

Ключевые компоненты¶

Модели — SQL-файлы, каждый из которых = один SELECT. dbt превращает его в таблицу или представление:

-- models/staging/stg_orders.sql
SELECT
  id         AS order_id,
  user_id,
  status,
  created_at
FROM {{ source('raw', 'orders') }}
WHERE status != 'test'

Тесты — проверки данных, которые запускаются после каждой сборки:

# models/staging/schema.yml
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['paid', 'pending', 'cancelled']

Источники (sources) — описание сырых таблиц, которые загружаются извне:

# models/staging/sources.yml
sources:
  - name: raw
    tables:
      - name: orders
      - name: users

Snapshots — механизм историзации данных (SCD Type 2). dbt отслеживает изменения и сохраняет историю.

ref() и source() — граф зависимостей¶

Главная «магия» dbt — функция ref(). Вместо прямого имени таблицы ты пишешь:

-- models/marts/fct_revenue.sql
SELECT
  o.order_id,
  o.user_id,
  oi.product_id,
  oi.qty * oi.price AS revenue
FROM {{ ref('stg_orders') }} o
JOIN {{ ref('stg_order_items') }} oi
  ON o.order_id = oi.order_id
WHERE o.status = 'paid'

dbt автоматически:

1. Понимает, что fct_revenue зависит от stg_orders и stg_order_items
2. Запускает модели в правильном порядке
3. Подставляет реальные имена таблиц (с учётом схемы и среды)

SQL-скрипты vs dbt¶

Основные команды¶

# Установка
pip install dbt-postgres   # или dbt-bigquery, dbt-snowflake

# Создание проекта
dbt init my_project

# Проверка подключения
dbt debug

# Запуск всех моделей
dbt run

# Запуск тестов
dbt test

# Запуск моделей + тесты
dbt build

# Генерация документации
dbt docs generate
dbt docs serve

Когда dbt — правильный выбор¶

Что запомнить¶

• dbt — это T в ELT: трансформирует данные, уже загруженные в хранилище
• Каждая модель — один SQL-файл с одним SELECT
• ref() связывает модели в граф зависимостей
• Тесты (unique, not_null, accepted_values) запускаются автоматически
• Структура проекта: staging → intermediate → marts

Проверь себя¶

Что дальше?¶

Теперь, когда ты понимаешь зачем нужен dbt, разберись с моделями и материализациями — это ядро любого dbt-проекта.

Источники¶

• dbt Documentation: Introduction — официальное введение в dbt
• dbt Documentation: About dbt projects — структура проекта и конфигурация
• dbt Best Practices: How we structure our dbt projects — рекомендации по организации моделей