9 апреля 2026 г.

dbt — что это и зачем аналитику

Что такое dbt

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

Проще говоря: dbt берёт на себя «T» в ELT — трансформацию. Вы пишете SQL, dbt делает всё остальное: определяет зависимости, запускает в правильном порядке, тестирует результат.

Почему это важно для аналитика: раньше трансформации делали data-инженеры на Python. С dbt аналитик, который знает SQL, может сам управлять логикой подготовки данных — от сырых таблиц до готовых витрин для дашбордов. Это называется «analytics engineering» — и это одна из самых востребованных специализаций.

ELT vs ETL — почему dbt стал возможен

В классическом ETL данные трансформируются до загрузки в хранилище. Нужен отдельный сервер, Python-скрипты, Airflow — инфраструктурная работа для инженеров.

В ELT данные сначала загружаются сырыми в хранилище (Fivetran, Airbyte, Stitch), а трансформируются внутри хранилища SQL-запросами. Это стало возможным с появлением мощных облачных DWH: BigQuery, Snowflake, Redshift, ClickHouse. Вычисления дешёвые, SQL быстрый — зачем усложнять?

dbt — идеальный инструмент для ELT: он не извлекает и не загружает данные, а только трансформирует то, что уже в хранилище.

Как работает dbt

Модель (Model)

Модель — SQL-файл с SELECT-запросом. dbt выполняет этот SELECT и создаёт таблицу (table) или представление (view) в хранилище.

Файл models/mart/daily_revenue.sql:

SELECT
    DATE(order_date) AS day,
    COUNT(*) AS order_count,
    SUM(amount) AS revenue,
    AVG(amount) AS avg_check
FROM {{ ref('stg_orders') }}
WHERE status = 'completed'
GROUP BY DATE(order_date)

{{ ref('stg_orders') }} — ссылка на другую модель. dbt по этим ссылкам строит граф зависимостей и запускает модели в правильном порядке: сначала stg_orders, потом daily_revenue.

ref() — ключ к автоматизации

ref() — главная функция dbt. Она делает две вещи:

  1. Определяет зависимость — dbt знает, что daily_revenue зависит от stg_orders
  2. Подставляет правильное имя таблицы — в dev-окружении это dev_schema.stg_orders, в prod — prod_schema.stg_orders

Никаких хардкодов имён таблиц. Если переименовали модель — все зависимости обновятся автоматически.

source() — подключение сырых данных

Для сырых таблиц, которые не являются моделями dbt, используется source():

-- models/staging/stg_orders.sql
SELECT
    id AS order_id,
    user_id,
    amount,
    created_at AS order_date,
    status
FROM {{ source('production', 'orders') }}
WHERE created_at >= '2025-01-01'

Sources описываются в YAML:

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

Структура dbt-проекта

my_project/
├── dbt_project.yml        # конфигурация проекта
├── models/
│   ├── staging/           # очистка сырых данных
│   │   ├── stg_orders.sql
│   │   ├── stg_users.sql
│   │   └── sources.yml
│   ├── intermediate/      # промежуточные расчёты
│   │   └── int_user_orders.sql
│   └── mart/              # готовые витрины
│       ├── daily_revenue.sql
│       └── user_ltv.sql
├── tests/                 # кастомные тесты
└── macros/                # переиспользуемые SQL-шаблоны

Три слоя — стандартная конвенция:

  • staging — один-к-одному с источниками. Минимальные преобразования: переименование колонок, приведение типов, фильтрация
  • intermediate — бизнес-логика, джойны, агрегации. Используются как строительные блоки
  • mart — готовые витрины для дашбордов и отчётов. Это то, что видит бизнес

Тесты

dbt позволяет тестировать данные — не код, а результат трансформации:

# models/mart/schema.yml
models:
  - name: daily_revenue
    columns:
      - name: day
        tests:
          - not_null
          - unique
      - name: revenue
        tests:
          - not_null

Встроенные тесты: not_null, unique, accepted_values, relationships. Можно писать кастомные — это обычные SELECT, которые должны вернуть 0 строк при успехе.

Тесты запускаются после каждого билда. Если day содержит NULL — dbt сообщит об ошибке. Это критически важно: без тестов вы не узнаете о проблемах с данными, пока менеджер не придёт с вопросом «почему дашборд показывает нули».

Зачем аналитику знать dbt

Самостоятельность. Без dbt аналитик зависит от data-инженера: «добавь колонку в витрину», «исправь логику расчёта LTV». С dbt аналитик сам меняет SQL-модель, пушит в Git, запускает билд. Цикл обратной связи — минуты, а не дни.

Версионирование. Все модели в Git. Можно посмотреть историю изменений, сделать ревью, откатить. Это культура работы с данными, которую ценят на собеседованиях.

Документация. dbt генерирует документацию автоматически: граф зависимостей, описания моделей и колонок, тесты. Новый аналитик видит, как устроено хранилище, за минуты.

Рынок. «dbt» в вакансиях аналитиков появляется всё чаще. В крупных компаниях (Яндекс, Тинькофф, Авито) аналитики уже работают с dbt или его аналогами.

dbt Cloud vs dbt Core

dbt Core dbt Cloud
Цена Бесплатно (open-source) От $100/мес
Запуск CLI, нужна инфраструктура Веб-интерфейс, SaaS
Расписание Через Airflow/cron Встроенный scheduler
IDE Свой редактор Встроенный веб-IDE
CI/CD Настраиваете сами Из коробки

Для изучения и pet-проектов — dbt Core. Для команды — dbt Cloud или Core + Airflow.

Пример: от сырых данных до витрины

Допустим, у нас есть сырые таблицы raw_orders и raw_users. Нужна витрина с LTV пользователей.

Шаг 1 — staging:

-- models/staging/stg_orders.sql
SELECT
    id AS order_id,
    user_id,
    amount,
    created_at AS order_date
FROM {{ source('production', 'raw_orders') }}
WHERE amount > 0

Шаг 2 — intermediate:

-- models/intermediate/int_user_orders.sql
SELECT
    user_id,
    COUNT(*) AS total_orders,
    SUM(amount) AS total_revenue,
    MIN(order_date) AS first_order,
    MAX(order_date) AS last_order
FROM {{ ref('stg_orders') }}
GROUP BY user_id

Шаг 3 — mart:

-- models/mart/user_ltv.sql
SELECT
    o.user_id,
    u.signup_date,
    o.total_orders,
    o.total_revenue AS ltv,
    o.first_order,
    o.last_order,
    o.last_order - u.signup_date AS lifetime_days
FROM {{ ref('int_user_orders') }} o
JOIN {{ ref('stg_users') }} u ON u.user_id = o.user_id

Три файла, чистый SQL, CTE не нужны — dbt сам управляет зависимостями.

Вопросы с собеседований

  1. Что такое dbt и какую проблему решает? — Data build tool — инструмент трансформации данных внутри хранилища через SQL. Решает проблему управления SQL-моделями: зависимости, порядок выполнения, тесты, документация. Позволяет аналитикам самостоятельно менять логику подготовки данных.

  2. Что делает функция ref()? — Ссылается на другую модель. Определяет зависимость (dbt строит граф и запускает в правильном порядке) и подставляет корректное имя таблицы в зависимости от окружения.

  3. Чем ELT отличается от ETL и при чём тут dbt? — В ETL данные трансформируются до загрузки (на отдельном сервере). В ELT — после загрузки, внутри хранилища. dbt — инструмент для «T» в ELT: трансформация SQL-запросами в хранилище.

  4. Какие тесты есть в dbt? — Встроенные: not_null, unique, accepted_values, relationships. Кастомные: SQL-запрос, который должен вернуть 0 строк. Тесты проверяют данные, а не код — это data quality проверки.

  5. Как устроена структура dbt-проекта? — Три слоя моделей: staging (очистка сырых данных), intermediate (бизнес-логика), mart (готовые витрины). Плюс sources (описание сырых таблиц), tests и macros.

FAQ

Можно ли использовать dbt без хранилища данных?

Нет. dbt выполняет SQL внутри хранилища: BigQuery, Snowflake, Redshift, PostgreSQL, ClickHouse. Без хранилища dbt нечего трансформировать. Для pet-проекта подойдёт бесплатный PostgreSQL или BigQuery sandbox.

Сложно ли освоить dbt?

Если вы знаете SQL — нет. Основная работа в dbt — писать SELECT-запросы. Специфичные концепции (ref, source, Jinja-шаблоны) осваиваются за пару дней. Официальный туториал dbt Fundamentals занимает 4-5 часов.

dbt заменяет Airflow?

Нет. dbt трансформирует данные (T в ELT), Airflow оркестрирует задачи (когда и в каком порядке запускать). Часто используются вместе: Airflow запускает dbt run по расписанию. dbt Cloud имеет встроенный scheduler, но для полноценной оркестрации (извлечение, загрузка, алерты) всё равно нужен Airflow или аналог.

Потренируйте вопросы по SQL и дата-инженерии на реальных задачах — откройте тренажёр. 1500+ вопросов, которые спрашивают на собеседованиях аналитика. Бесплатно.

Тренироваться в Telegram