Что такое dbt

Когда данные уже лежат в Snowflake, BigQuery или Redshift, начинается самое интересное — трансформация. Сырые таблицы из CRM, биллинга и кликстрима нужно превратить в чистые витрины: daily_revenue, active_users, cohort_retention. Это и есть буква T в ELT.

Раньше этим занимались десятки SQL-скриптов, разбросанных по серверам, без версионирования, тестов и документации. Скрипты ломались, никто не знал, какой запрос актуальный, а аналитик ждал две недели правки одной колонки. В 2016 году компания Fishtown Analytics выпустила инструмент, который перевернул индустрию — dbt (data build tool).

К 2026 году dbt — дефакто-стандарт трансформаций в современных data-командах. Если ты собеседуешься на junior DE и не знаешь dbt — это пробел, который нужно закрыть в первую очередь.

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

Представь типичную ситуацию до dbt:

Проблемы такого подхода:

• Нет версионирования. SQL живёт в редакторах и Google Drive, git не используется.
• Нет тестов. Никто не проверяет, что order_id уникален или что revenue >= 0.
• Нет документации. Откуда взялась колонка mrr_normalized? Никто не знает.
• Нет lineage. Если изменить stg_orders, что сломается дальше? Узнаешь, когда позвонит CFO.
• Дубли логики. Каждый аналитик пишет свой is_paying_customer, и определения расходятся.

dbt решает всё это, превращая SQL-трансформации в программный проект: модели в git, тесты как код, документация генерируется автоматически, lineage строится по графу зависимостей.

Что такое dbt по сути

dbt — это CLI-инструмент на Python, который компилирует и запускает твои SQL-модели в DWH. Сам dbt не хранит и не обрабатывает данные — он просто умно делегирует SQL в Snowflake, BigQuery, Redshift, Postgres, Databricks или другой движок.

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

my_dbt_project/
  dbt_project.yml          # конфиг проекта
  profiles.yml             # подключение к DWH (вне репо)
  models/                  # SQL-модели (главное)
    staging/
      stg_orders.sql
      stg_customers.sql
    marts/
      mart_revenue_daily.sql
  tests/                   # data tests
  macros/                  # переиспользуемая логика на Jinja
  snapshots/               # SCD2 snapshots
  seeds/                   # CSV-файлы для маленьких справочников

Каждая модель — это просто .sql файл с одним SELECT. Никаких CREATE TABLE, INSERT, MERGE — dbt сам решает, как материализовать модель: как VIEW, как TABLE, инкрементально или эфемерно.

Пример простой модели models/marts/mart_revenue_daily.sql:

{{ config(materialized='table') }}

SELECT
  date_trunc('day', order_at) AS day,
  count(*) AS orders_cnt,
  sum(amount) AS revenue
FROM {{ ref('stg_orders') }}
WHERE status = 'paid'
GROUP BY 1

Когда ты запускаешь dbt run, dbt компилирует этот шаблон в чистый SQL, оборачивает в CREATE OR REPLACE TABLE и выполняет в твоём DWH.

dbt-core vs dbt Cloud

У dbt две версии. Их часто путают на собеседованиях.

dbt-core — что компании используют чаще всего. Запускается из контейнера в Airflow или GitHub Actions, бесплатный, гибкий. Все материалы курса работают и в dbt-core.

dbt Cloud — удобный для команд, которые не хотят сами поднимать инфраструктуру. Платный сервис, но даёт веб-IDE, планировщик, мониторинг и интеграцию с git из коробки.

Что делает dbt стандартом в 2026

К 2026 году у dbt 60+ тысяч активных компаний по миру: от стартапов до Fortune 500. Несколько причин:

1. SQL как язык трансформаций. SQL знают все: аналитики, DE, DS. dbt не вводит новый язык — только улучшает SQL шаблонами Jinja.

2. Git-friendly workflow. Модели — это просто файлы. Pull request, code review, ветвление работают как с обычным кодом.

3. Инкрементальные модели. Не нужно каждый раз пересчитывать таблицу с 10 млрд строк — dbt умеет догружать только новые данные.

4. Lineage из коробки. Граф зависимостей строится автоматически из ref() — увидишь, какие модели затронет изменение stg_orders.

5. Документация генерируется автоматически. Запускаешь dbt docs generate, и получаешь сайт с описанием каждой колонки и графом lineage.

6. Огромная экосистема пакетов. dbt Hub хостит сотни open-source пакетов: dbt_utils, dbt_expectations, коннекторы к Salesforce, Stripe, Shopify.

Где dbt вписывается в стек

dbt сидит ровно посередине — между загрузкой сырых данных и потребителями. Это сердце трансформационного слоя. Если в компании есть DWH, скорее всего рядом есть dbt.

Кто работает с dbt в команде

• Analytics Engineers — главные пользователи dbt. Это новая роль, она появилась как раз благодаря dbt: аналитик с SQL и git, который строит витрины для команды.
• Data Engineers — отвечают за инфраструктуру dbt: контейнеры, Airflow, права на DWH.
• Data Analysts — читают готовые витрины, могут пушить простые модели в dbt.

Если ты junior DE — ты будешь и поднимать инфру dbt, и писать модели первое время.

Что дальше

В следующем уроке разберём конкретику: модели, функцию ref(), материализации и слои staging/intermediate/marts. Это даёт базу, чтобы написать первый рабочий dbt-проект.

Попробуй сам

Установи dbt-core локально через pip install dbt-postgres (или dbt-snowflake если есть аккаунт). Создай минимальный проект через dbt init my_project. Посмотри на структуру: где dbt_project.yml, где папка models/. Не нужно ничего запускать — просто прочувствуй, как выглядит dbt-проект изнутри. Если есть бесплатный аккаунт BigQuery — настрой подключение и запусти dbt run на одной модели.