dbt vs альтернативы

В data-стеке 2026 года вокруг dbt существует с десяток смежных инструментов, которые часто путают между собой. Этот урок отвечает на четыре практических вопроса:

1. Чем dbt отличается от чистого SQL в скриптах?
2. Чем dbt отличается от Spark / Databricks?
3. Чем dbt отличается от Airflow / Dagster?
4. Где границы, и когда использовать каждый инструмент?

Понимание этих границ снимает 90% путаницы про «зачем нам dbt, если у нас уже Airflow».

dbt vs raw SQL в скриптах

Базовый кейс: команда без dbt пишет трансформации как набор .sql-файлов, которые запускаются по очереди через bash-скрипт или crontab.

#!/bin/bash
# build_models.sh
psql -f stg_orders.sql
psql -f stg_customers.sql
psql -f int_orders_with_customers.sql
psql -f mart_orders.sql

Это работает на 5 моделях. На 50 — становится больно. На 500 — невозможно. Вот что отвалится:

dbt решает все шесть проблем сразу:

Когда чистый SQL ещё годится: один аналитик, 5-10 моделей, нет команды. Как только модели начинают зависеть друг от друга и команда растёт — dbt окупается за неделю.

dbt vs Spark / Databricks

Spark и Databricks (managed Spark + storage + workspace) — это движки распределённой обработки данных. Они умеют то, что warehouse не умеют:

• Прочитать 10 ТБ из S3 в Parquet и пересчитать
• Запустить ML-модель inference на DataFrame
• Стриминг через Spark Structured Streaming
• Numerical computations на NumPy/pandas-уровне (с PySpark)

dbt и Spark пересекаются в одной плоскости: трансформация данных. Но они работают по-разному:

Важный сценарий где они работают вместе: data engineer на Spark делает heavy lifting — читает миллиарды событий из Kafka, делает дедупликацию и обогащение, грузит в bronze/silver слой warehouse. Дальше analytics engineer на dbt делает gold-слой: бизнес-моделирование, тесты, marts для BI.

[Kafka / S3 events] -> [Spark — bronze/silver] -> [warehouse: silver tables]
                                                       ↓ (dbt берёт отсюда)
                                                [warehouse: dbt staging -> marts]
                                                       ↓
                                                  [BI / Tableau]

dbt поддерживает Python-модели на адаптерах Databricks/Snowpark/BigQuery/dbt-duckdb. Это не «dbt становится Spark» — это «dbt позволяет один шаг в графе сделать на Python там, где SQL не подходит». Например, посчитать косинусное расстояние между эмбеддингами.

dbt vs Airflow / Dagster

Это самая частая путаница, потому что Airflow и Dagster тоже работают с DAG — но на другом уровне абстракции.

Airflow (и его аналоги Dagster, Prefect, Luigi, Mage) — это оркестратор. Он отвечает на вопрос: «в каком порядке и когда запускать задачи?». Каждая задача в Airflow — это произвольный код: shell-команда, Python-функция, BashOperator, KubernetesPodOperator.

dbt — это трансформер. Он отвечает на вопрос: «как трансформировать SQL-модели внутри warehouse и в каком порядке?». Все ноды dbt-DAG — это SQL-модели в warehouse.

Иначе говоря: внутри одного Airflow task запускается команда dbt run, и она внутри себя строит и исполняет dbt-DAG из 200 моделей. Для Airflow это один task. Для dbt это полный граф.

dbt НЕ заменяет Airflow. Если в production только dbt — нет шедулера. dbt-проект запускают извне: cron, Airflow, Dagster, GitHub Actions, dbt Cloud.

Airflow НЕ заменяет dbt. Если в production только Airflow — каждый SQL-таск пишется как BashOperator с inline SQL, без DAG между SQL-моделями, без тестов, без документации. Это «чистый SQL в скриптах» из предыдущего раздела, только с шедулером.

Связки в production:

• Airflow + dbt-core: классика. Airflow запускает dbt run --select tag:hourly каждый час. Используется в большинстве компаний с собственной инфраструктурой.
• Dagster + dbt-core: Dagster имеет нативную интеграцию через dagster-dbt, которая разворачивает dbt-DAG как Dagster assets. Каждая модель — отдельный Dagster asset. Лучшая observability, но требует больше инфраструктуры.
• dbt Cloud Jobs: managed-вариант, dbt Labs сами шедулят. Дешёво для маленьких команд, дорого для больших.
• Astronomer Cosmos (open-source): обёртка для Airflow, которая разворачивает dbt-DAG как Airflow tasks вместо одного big task. Каждая модель видна в Airflow UI.

Когда что выбирать

Условный матричный гид:

Что НЕ заменяет dbt

Чтобы закрыть тему: dbt не покрывает:

• Loading (raw данные -> warehouse): Fivetran, Airbyte, Singer, custom Python
• Orchestration верхне-уровневого пайплайна: Airflow, Dagster, Prefect
• Streaming: Spark Streaming, Flink, Kafka Streams
• ML serving: Sagemaker, Vertex AI, MLflow
• BI / dashboards: Tableau, Looker, Metabase, Mode
• Catalog / governance: DataHub, Atlan, Collibra (хотя dbt manifest часто кормит их)
• Storage: object storage (S3) / warehouse storage — это отдельный layer

dbt — это узко-специализированный SQL-трансформер с DAG и тестами. Его сила — в фокусе. Не пытайтесь делать через dbt то, чего он не должен делать; и не пытайтесь заменить им оркестратор или BI-инструмент.

Попробуй сам

Нарисуйте на бумаге архитектуру типичной data-platform средней компании:

1. Source-системы: Stripe API, Salesforce, application Postgres, Mixpanel events
2. Loading: какой инструмент? (Подсказка: Fivetran/Airbyte)
3. Warehouse: какой? (Snowflake / BigQuery)
4. Трансформации: какой инструмент? (dbt)
5. Оркестрация: какой инструмент? (Airflow / Dagster / dbt Cloud)
6. BI: какой инструмент? (Tableau / Looker)

Нарисуйте, где каждый из них живёт, и какие стрелки между ними. Это пятиминутное упражнение покажет, что dbt — это один слой в десятислойном стеке, а не «универсальный инструмент данных».