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

Это не гайд, как развернуть dbt и создать проект, а знакомство с тулом для тех, кто пока с ним не работал и хочется разобраться, что это вообще такое.

Ключевые понятия

Для начала разберем, что вообще есть в dbt — так будет проще потом рассказывать про задачи и возможности.

Project — каталог со всеми вашими SQL-запросами в виде моделей, связями между ними, тестами и документацией.

Models — это SQL-файлы которые описывают, как строятся ваши таблицы или представления в базе данных. dbt поддерживает пять видов материализаций моделей:

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

Тут надо оговориться, что dbt поддерживает и Python и дает возможность создавать Python-модели, но на них в этом материале мы останавливаться не будем.

DAG — dbt создает граф зависимостей между моделями, благодаря которым понимает, в каком порядке они должны выполняться. Можно запускать отдельные ветки графа, как upstream, так и downstream.

Выглядит граф обычно как-то так:

Macros — это шаблоны, которые можно переиспользовать в разных моделях. Например, можно сделать макрос для стандартного расчета процента или даты и потом вызывать его в любом SQL.

Создание макросов обеспечивает поддержка шаблонизатора Jinja. Кроме этой функции, он еще и позволяет добавлять циклы, переменные и операторы for/if — в общем, отлично дополняет возможности SQL.

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

Snapshots — «снимки» БД, которые позволяют отслеживать изменения данных во времени. Например, если у вас есть таблица с пользователями и их статусами, snapshot может сохранять историю изменений, чтобы потом видеть, когда и какие статусы менялись.

Зачем нужен dbt?

Без dbt аналитики часто пишут разрозненные SQL-запросы, где порядок выполнения нужно настраивать и отслеживать вручную. dbt же эти запросы сохраняет в виде моделей, фиксирует связи между ними в виде графов и помогает это все систематизировать в рамках проекта. Он не хранит и не загружает данные, а отвечает только за их обработку.

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

Это главное преимущество dbt — автоматизация выполнения запросов, которая экономит время и нервы.

Но если бы это была его единственная функция, то стандартом индустрии в области трансформации данных dbt, наверное, не стал бы. Он также может, например:

проверять качество данных — есть встроенные тесты, можно писать свои кастомные,
составлять документацию — она генерируется автоматически по мере появления новых моделей и заполнения YAML-схемы. Сразу видно, откуда берутся данные, какие тесты к каким моделям привязаны и так далее.

Бесплатный open-source или удобный SaaS?

dbt существует в двух основных версиях: dbt Core и dbt Cloud. Они используют один и тот же движок для трансформации данных, но различаются по функционалу, удобству использования и способу развертывания.

dbt Core — это полностью бесплатная open-source версия, которая устанавливается локально или на сервер/виртуальную машину. Логично, что все задачи по настройке и поддержке ложатся на пользователя — ну или тех, кто у него отвечает за IT и аналитику. Работа с кодом ведется через Git, а все команды — dbt run, dbt test, dbt docs generate — выполняются через терминал. Встроенного планировщика у него нет, и для автоматизации понадобится отдельный тул — например, Apache Airflow.

dbt Cloud — это коммерческая облачная версия, у которой есть все функции dbt Core и даже больше. У него уже есть встроенный планировщик и удобный web-интерфейс для управления проектом. И работать с командой в облаке удобнее.

Собрал в таблицу ключевые отличия:

	dbt Core	dbt Cloud
Стоимость	Бесплатно	Платно (есть trial/tiers)
Развертывание	Локально/сервер	Облако
Планировщик	Сторонний	Встроенный
UI	Нет	Да
Сложность в настройке	Высокая, нужны технические специалисты в штате	Низкая
Подходит, если	Есть люди, которые могут этим всем заниматься, важная кастомизация и не хочется платить за подписку	Нет возможности/желания возиться с настройкой и поддержкой, важны простота и возможности для командной работы.

Если резюмировать: dbt Cloud удобнее, но дороже, и когда бюджет ограничен, то можно остановиться на Core.

Как мы используем dbt и best practices

Напоследок хочу показать, как мы работаем с dbt Core на одном из наших проектов.

Заказчик — телеком из США, который долго пользовался старой и неудобной CRM, но наконец-то решил навести у себя в данных красоту. Данных там очень много, поэтому без dbt было не обойтись. Core-версию выбрали из целей экономии.

Как устроен проект?

Хранилище: BigQuery

Визуализация данных: Metabase

Трансформация: dbt, само собой

В dbt мы создаем таблицы-плейсхолдеры, чтобы к ним обращаться в моделях. При деплое они заменяются на реальные данные из датасета в BigQuery.

Код лежит на GitHub. В качестве планировщика мы используем GCP Cloud Scheduler — он каждый час запускает Cloud Run, который в свою очередь запускает dbt-модели, выполняет тесты и делает снепшоты.

Если что-то обновляем в репозитории, то GCP Cloud Build Trigger собирает Docker-образ и сохраняет его в Artifact Registry. Логи отслеживаются через GCP Cloud Monitoring.

В общем — dbt с кучей сервисов GCP сверху.

Плюс такого подхода в том, что мы автоматизируем разработку и запуск моделей вместо того, чтобы вручную запускать скрипты. В сочетании со спецификой Metabase, которая не хранит данные у себя, а использует ресурсы базы, получается почти real-time аналитика. Добавились данные в BigQuery — dbt их автоматически обработал, и они подтянулись на дашборды.

В папке core хранятся BI-модели в основном в виде таблиц, а в стейджинге большая часть моделей эфемерные и инкрементальные.

Проект достаточно большой, и от хаоса в нем спасают несколько best practices:

1. Обращение к моделям через ref {}, а к источникам через source {}. Это быстро, удобно и необходимо для создания DAG’ов и автоматического обновления документации по проекту

2. Инкрементальные модели для больших таблиц. Одна из причин, почему заказчик вообще решил переделать аналитику — это то, что старая система с его объемами данных не справлялась. Сотрудники делали огромные выгрузки на 30к строк, это все было очень долго и сопровождалось затупами и зависаниями. Инкрементальные обновления в dbt настраиваются достаточно просто и очень сильно упрощают и ускоряют работу.

3. Возможность запуска upstream/downstream. Тоже удобно для экономии ресурсов и отладки, чтобы не гонять все модели в проекте зря.

***

Вот такое краткое введение в dbt. Пишите в комментах, что еще хотели бы узнать про этот тул или особенности работы с ним, буду рад ответить.

Ну и подписывайтесь на мой канал Коля Валиотти • Дата консалтинг — я там рассказываю про свой дата-консалтинг, аналитику и технологии.

dbt 101: что нужно знать на старте и лучшие практики