Что такое dbt в инженерии данных? Руководство по архитектуре

dbt (data build tool) — это не оркестратор пайплайнов и не хранилище, а слой трансформации, который превращает сырые загруженные таблицы в протестированные, документированные модели с контролем версий с помощью SQL и компилятора. Большинство команд неверно оценивают его место, прикручивая его к Airflow или относясь к нему как к ПО для ETL, а затем удивляются, почему ломается lineage (происхождение данных).

Вот что на самом деле делает dbt, какое место он занимает в стеке ELT и как определить, нужен ли он в вашем стеке.

В ELT-пайплайне сырые данные сначала попадают в хранилище; затем dbt компилирует SQL и логику Jinja в направленный ациклический граф (DAG) моделей, которые хранилище выполняет нативно.

Извлечение (extract) и загрузка (load) остаются за такими инструментами, как Fivetran; dbt отвечает за трансформацию (transform), и команды используют его для превращения ad-hoc SQL-кода в модели с контролем версий, которые можно читать, тестировать и переиспользовать.

Если вы взвешиваете, стоит ли создавать этот слой трансформации собственными силами, или вам нужна экспертная поддержка в области инженерии данных для правильной реализации, решения по настройке быстро накапливаются.

dbt появился в 2016 году как проект с открытым исходным кодом в Fishtown Analytics — компании, которая позже стала dbt Labs, — и с тех пор стал стандартным слоем трансформации для ELT-пайплайнов, работающих в современных облачных хранилищах.

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

Если вы предпочитаете привлечь внешнюю экспертизу для подобной миграции, наше руководство по оценке партнера по инженерии данных подробно описывает критерии отбора и ведущих вендоров.

Где dbt располагается в ELT-пайплайне?

dbt находится на этапе трансформации (transform) в ELT (extract, load, transform), после того как сырые данные попадают в хранилище, и перед тем, как они поступают в BI-инструменты или задачи reverse-ETL. Он никогда не касается извлечения или загрузки; эта граница — наиболее часто неправильно понимаемая часть настройки.

Fivetran (или Airbyte, Stitch) извлекает записи из исходных систем и загружает их в неизменном виде в Snowflake, BigQuery или Redshift. dbt берет управление на себя, компилируя SQL и логику Jinja в DAG, который хранилище выполняет как модели, проводя сырые таблицы через уровни staging (промежуточный), intermediate (согласующий) и marts (витрины), которые команды могут читать и переиспользовать.

Airflow (или Dagster, Prefect) находится над ними обоими, планируя задачу загрузки, а затем запуская выполнение dbt, как только новые данные поступают. dbt ничего не планирует самостоятельно; dbt Cloud и движок Fusion добавляют нативное планирование, но Airflow остается стандартным оркестратором для команд, которые уже используют многоинструментальные пайплайны.

Теперь обе стороны находятся под управлением одной компании: Fivetran и dbt Labs объявили о своем слиянии в октябре 2025 года, и completed it on June 1, 2026. dbt Core остается с открытым исходным кодом, а извлечение-загрузка и трансформация по-прежнему остаются раздельными этапами в пайплайне.

На практике эта схема выглядит следующим образом: Airflow инициирует синхронизацию Fivetran, а затем вызывает dbt build для того же хранилища, поэтому трансформация запускается как зависимость загрузки, а не по отдельному расписанию cron, которое может сработать до прибытия данных.

Ошибётесь в иерархии слоев — и lineage сломается. dbt может считывать сырые таблицы Fivetran, но не может обнаружить сбой задания загрузки, произошедший без выдачи ошибки, поэтому им требуется раздельный мониторинг, а не одно общее оповещение.

Для чего используется dbt? Пример рабочего процесса

dbt — это слой, который превращает сырые таблицы в хранилище данных в чистые, протестированные модели, к которым аналитик данных может делать запросы без необходимости заново выводить бизнес-логику каждый раз. Стандартная структура представляет собой многоуровневую модель staging-to-marts: модели staging приводят сырые загруженные исходные таблицы к типизированным столбцам с переименованными именами; модели intermediate выполняют джойны и дедупликацию; модели marts агрегируют все в таблицы, которые действительно читают BI-инструменты.

Типичный запуск выглядит следующим образом: исходная таблица попадает в Snowflake или BigQuery, staging-модель оборачивает ее в вызов ref, intermediate-модель объединяет три staging-модели по общему ключу, а mart-модель сводит результат в таблицу выручки по когортам (revenue-by-cohort).

dbt run компилирует Jinja и SQL в нативный для хранилища код и выполняет его в порядке DAG, поэтому ни одна модель не запускается раньше своей восходящей зависимости.

Тесты схемы и данных выполняются вместе с каждой сборкой, поэтому сломанный внешний ключ или неожиданный null обнаруживаются на этапе CI до того, как они попадут в витрину, а не после того, как сломается дашборд.

Это важно, потому что попадание некачественных данных к стейкхолдерам — главная забота в этой области: согласно отчету dbt Labs State of Analytics Engineering за 2026 год, 71% специалистов по работе с данными заявили, что обеспокоены этим, а доверие к данным было названо наиболее приоритетной целью (83%) (PR Newswire).

Используете ли вы dbt Core, платформу dbt или новый движок Fusion, это меняет мониторинг заданий, глубину наблюдаемости и стоимость одного запуска, но лежащая в основе логика staging-to-marts остается идентичной для всех трех вариантов.

Что такое модель dbt?

Модель dbt — это отдельный файл .sql, содержащий инструкцию SELECT, один узел в направленном ациклическом графе (DAG), который dbt компилирует и запускает в порядке зависимостей. В самом файле нет инструкций INSERT или CREATE TABLE. Компилятор Jinja-to-SQL в dbt справляется с этим, разворачивая вызовы ref, макросы и блоки config в нативный для хранилища SQL перед передачей его в среду выполнения.

Функция ref делает DAG возможным. Вместо жесткого кодирования имени нисходящей таблицы модель вызывает ref('stg_orders'), и dbt разрешает это имя в правильную схему, отслеживает его как ребро зависимости и генерирует граф происхождения, который вы видите в документации dbt. Сломайте ref — и DAG не скомпилируется, что позволит перехватить сломанный пайплайн до того, как он попадет в production.

Материализация определяет, как модель попадает в хранилище данных: view вычисляет данные при каждом чтении, table полностью перестраивается при каждом запуске, incremental дописывает или объединяет только новые строки. Перенос большой модели фактов с table на incremental обычно дает наибольшее сокращение времени выполнения в проекте, поскольку хранилище перестает повторно сканировать историю, которую оно уже обработало.

Вот как на практике выглядит небольшая инкрементальная модель:

Два вызова ref() создают ребра DAG, config() задает материализацию, а блок is_incremental() ограничивает каждый запуск только новыми заказами. dbt компилирует все это в чистый SQL для вашего хранилища.

Хорошие инкрементальные модели остаются идемпотентными: их повторный запуск после частичного сбоя выдает тот же набор результатов, а не дубликаты, именно поэтому макрос is_incremental и надежный unique_key имеют большее значение, чем большинство команд изначально предполагают.

Как dbt компилирует и выполняет SQL (механика Jinja)

dbt отделяет компиляцию от выполнения: компилятор преобразует шаблоны Jinja и макросы в чистый SQL, а среда выполнения отправляет этот SQL в хранилище для выполнения. Понимание этого двухэтапного процесса объясняет, почему код dbt совсем не похож на то, что выполняется на самом деле.

Когда вы вызываете dbt run, dbt сначала анализирует каждую модель, разворачивая вызовы ref, циклы {% for %} и макросы в нативный для хранилища SQL. Макросы работают как повторно используемые функции: напишите макрос конвертации валют один раз, вызывайте его в двадцати моделях, и изменение логики распространится везде при следующей сборке. Это тот же самый DAG, который определяет порядок выполнения, поэтому компиляция и разрешение зависимостей происходят за один проход.

Только после компиляции dbt передает SQL для выполнения в Snowflake, BigQuery или другое хранилище, отслеживая вычислительные ресурсы независимо от этапа компиляции. Это разделение важно для контроля затрат: компиляция — это практически бесплатная нагрузка на CPU, но каждая выполненная модель потребляет ресурсы хранилища, поэтому перегруженные макросы или ненужные полные обновления (full-refreshes) отражаются в вашем счете, а не в логах сборки.

Движок Fusion engine от dbt Labs, запущенный в мае 2025 года и созданный на основе технологий, полученных при приобретении SDF Labs в январе 2025 года, переписан на Rust для ускорения парсинга в крупных проектах. Это значительный сдвиг для команд, работающих с тысячами моделей, где компиляция на базе Python в dbt Core становится «узким местом».

Как dbt строит lineage данных с помощью DAG

dbt автоматически строит направленный ациклический граф (DAG) на основе каждого вызова ref в коде ваших моделей, определяя, какие таблицы считываются из каких вышестоящих моделей, еще до запуска первого запроса. Нет необходимости поддерживать отдельный инструмент для lineage: граф зависимостей является побочным продуктом написания SQL в стиле dbt.

Каждый раз, когда модель ссылается на другую с помощью ref('stg_orders') вместо жестко закодированного имени таблицы, dbt записывает ребро в графе.

При компиляции проекта dbt (Core или Fusion) разрешает полный DAG, упорядочивает выполнение так, чтобы вышестоящие модели завершались первыми, и полностью блокирует циклические ссылки — отсюда и название «ациклический».

Именно поэтому многоуровневая архитектура от staging до marts работает так чисто: модели marts никогда не собираются раньше staging-моделей, от которых они зависят.

Результат виден в продакшене. Когда одна staging-модель ломается, DAG позволяет перезапустить только её и зависящие от неё marts (например, с помощью команды dbt build --select stg_orders+), а не всё ночное задание целиком.

Команды также получают визуальный граф lineage в платформе dbt и на сайте документации dbt с открытым исходным кодом, который превращает этот граф зависимостей в нечто понятное даже для тех, кто не является инженером.

dbt Core против dbt Cloud против Fusion engine

dbt Core, dbt Cloud (переименованная в the dbt platform в 2025 году) и более новый Fusion engine различаются тем, где выполняются компиляция и оркестрация, и это разделение влияет на совокупную стоимость владения (TCO) больше, чем любая прейскурантная цена.

Fusion engine заменяет Python-движок dbt Core на движок, написанный на Rust, созданный для более быстрого парсинга больших DAG. Он появился до слияния с Fivetran: он стал результатом приобретения dbt Labs компании SDF Labs.

Разрыв, который действительно имеет значение, обычно заключается не в ценах Core и Cloud, а в том, хочет ли ваша команда самостоятельно заниматься мониторингом заданий и инструментами lineage или готова их купить.

dbt Core позволяет экономить на вычислительных ресурсах, но перекладывает планирование, оповещения и контроль доступа на существующий стек вашей платформенной команды. dbt Cloud включает мониторинг заданий, историю запусков и отслеживание использования в сам продукт, что отражается в виде отдельной статьи расходов, а не счета за хранилище.

Для команд, стандартизирующих многоуровневую архитектуру моделей от staging до marts в десятках пайплайнов, именно эти операционные накладные расходы являются реальным критерием для сравнения, а не цена по прайс-листу.

Как dbt работает с тестированием и документацией

dbt рассматривает тесты схемы и данных как скомпилированный SQL, который выполняется в вашем хранилище при каждой сборке, останавливая пайплайн до того, как «плохие» данные попадут в дашборд. Тест схемы проверяет структуру: not_null, unique, связи между моделями staging и marts. Тест данных — это произвольный SQL, проверяющий бизнес-правило, например, что выручка никогда не бывает отрицательной, что помогает поддерживать качество данных во всем аналитическом пайплайне.

И те, и другие компилируются через тот же движок Jinja-to-SQL, что и ваши модели, поэтому тесты хранятся в системе контроля версий рядом с логикой трансформации, которую они защищают, а не в отдельном QA-инструменте.

Тест relationships для соединения orders-to-customers — классический пример: он обнаруживает «осиротевшие» внешние ключи, которые процедурный пайплайн пропустил бы без предупреждения.

Документация генерируется таким же образом. Запуск dbt docs generate считывает ваши YAML-описания и SQL моделей, а затем создает сайт с возможностью поиска и графом lineage на уровне моделей для всего DAG, чтобы любой мог проследить метрику до исходных таблиц, не спрашивая автора.

Собственная документация dbt Labs рекомендует сочетать общие тесты (на уровне схемы) с единичными тестами (пользовательский SQL), а не полагаться на какой-то один тип.

dbt со Snowflake, BigQuery и менеджером пакетов

dbt подключается к Snowflake и BigQuery через адаптеры, которые компилируют один и тот же SQL с шаблонами Jinja в нативный диалект каждого хранилища, поэтому модель, написанная один раз, работает без изменений на любом движке. Это важно для команд, использующих несколько хранилищ после слияния или поэтапной миграции: логику трансформации не нужно переписывать, достаточно сменить адаптер.

Выбор хранилища действительно меняет поведение вычислений, за чем стоит следить. Snowflake выставляет счета за время работы виртуального хранилища, поэтому инкрементальная модель с плохо настроенным фильтром is_incremental может сканировать гораздо больше данных, чем при полном обновлении. Биллинг BigQuery на основе слотов вознаграждает за аналогичную дисциплину через отсечение партиций (partition pruning) в том же предложении фильтра.

Самое большое практическое преимущество dbt перед конкурирующими инструментами трансформации — это экосистема пакетов. dbt Package Hub распространяет переиспользуемые макросы и модели: dbt_utils для суррогатных ключей и дат, dbt_expectations для статистических тестов, которые команда устанавливает одной командой dbt deps вместо написания с нуля. Пакеты объявляются в файле packages.yml в корне проекта:

Фиксация диапазона версий делает обновления осознанными, а не случайными. Именно здесь сообщество open-source, а не только dbt Labs, расширяет логику DAG на разные хранилища.

dbt против Airflow против Dagster: нужны ли они оба?

dbt отвечает за логику трансформации, а не за планирование. Airflow и Dagster находятся на уровень выше, запуская команду dbt run (или dbt build) вместе с заданиями по загрузке данных, синхронизацией reverse-ETL и последующими аналитическими задачами. Большинству команд, использующих dbt в продакшене, нужен один из них.

Различие проявляется в самом DAG. DAG в dbt отображает lineage между SQL-моделями внутри хранилища: модель A передает данные в модель B через ref. DAG в Airflow отображает зависимости задач между системами: загрузка Fivetran, затем запуск dbt, затем оповещение в Slack.

Dagster идет дальше, рассматривая модели dbt как нативные программно-определяемые активы (software-defined assets), поэтому его представление lineage объединяет оркестрацию и трансформацию в один граф вместо двух отдельных, которые командам приходится согласовывать вручную.

Стоимость здесь тоже имеет значение: dbt Core плюс самохостируемый оркестратор дешевле в эксплуатации, но требует времени инженеров; управляемая платформа dbt меняет это время на подписку.

FAQ: dbt в инженерии данных

Что означает аббревиатура DBT?

dbt расшифровывается как data build tool — проект с открытым исходным кодом, запущенный в Fishtown Analytics в 2016 году и теперь поддерживаемый dbt Labs, которая является частью Fivetran после слияния в июне 2026 года. Он компилирует SQL и Jinja-шаблоны в нативные запросы хранилища и выполняет их как DAG. Команды по работе с данными используют это название как для CLI, так и для компании и сообщества dbt вокруг него.

Для чего dbt используется в инженерии данных?

dbt используется для преобразования необработанных, уже загруженных данных в протестированные и документированные модели, которые могут напрямую считываться аналитическими инструментами и BI-системами. Команды один раз пишут логику SQL SELECT, а dbt берет на себя управление зависимостями, отслеживание происхождения данных (lineage) и материализацию. Это заменяет разрозненные скрипты трансформации, хаотично распределенные по хранилищу. По мере роста организаций эти рабочие процессы трансформации становятся частью более широких практик проектирования данных, которые предприятия должны освоить для масштабирования.

Что такое модель dbt в проектировании данных?

Модель dbt — это .sql-файл, содержащий оператор SELECT, который dbt компилирует и материализует в виде таблицы или представления. Функция ref связывает модели между собой, автоматически выстраивая граф происхождения данных. Именно такая структура от промежуточных этапов (staging) до витрин данных (marts) делает крупные конвейеры поддерживаемыми как код.

Является ли dbt инструментом ETL?

Нет, dbt не является ETL-инструментом: он отвечает только за этап трансформации в ELT, а не за извлечение или загрузку. Fivetran, Airbyte или собственный конвейер сначала перемещают данные в хранилище. Затем dbt выполняет SQL-логику, которая формирует из них пригодные для использования модели. Команды, сравнивающие специализированные инструменты ETL-конвейеров для первого этапа, часто рассматривают такие варианты, как Matillion и Alteryx.

dbt Core против dbt Cloud: что выбрать?

dbt Core — это бесплатная версия с самостоятельным хостингом; dbt Cloud (теперь платформа dbt) добавляет управляемый планировщик, мониторинг заданий и IDE в браузере за плату за каждое рабочее место. Выбирайте Core, если вы уже используете Airflow или Dagster и хотите снизить общие затраты. Выбирайте Cloud, если вам нужна встроенная наблюдаемость без дополнительной инфраструктуры.

Как dbt работает с Snowflake или BigQuery?

dbt подключается через адаптер хранилища, компилируя SQL с шаблонами Jinja в нативный синтаксис и перенося все операции объединения (join) и агрегации на вычислительные мощности Snowflake или BigQuery. Инкрементальные модели сканируют только новые строки, сокращая время выполнения и затраты. Оплата за вычисления остается на стороне хранилища, а не dbt.

dbt против Airflow: нужны ли они оба?

Большинству производственных сред нужны оба инструмента: dbt отвечает за логику трансформации и отслеживание происхождения данных, в то время как Airflow или Dagster отвечают за планирование и оркестрацию между системами. Типичный DAG запускает dbt run после завершения задания по загрузке данных. Отказ от оркестратора возможен только для небольших конвейеров, запускаемых вручную.