Учебный курс по dbt (Data Build Tool)
dbt (data build tool) — это фреймворк с открытым исходным кодом для выполнения, тестирования и документирования SQL-запросов, который позволяет привнести элемент программной инженерии в процесс анализа данных. Это всё о букве T в акрониме ELT (Extract — Transform — Load).
С появлением таких производительных и масштабируемых аналитических баз данных как BigQuery, Redshift, Snowflake, исчез какой-либо смысл делать трансформации вне Хранилища Данных.
dbt не выгружает данные из источников, но предоставляет огромные возможности по работе с теми данными, которые уже загружены в Хранилище (в Internal или External Storage).
Основное назначение DBT — взять код, скомпилировать его в SQL, выполнить команды в правильной последовательности в Хранилище.
- Что на самом деле делает dbt?
- Dbt или не dbt, вот в чем вопрос
- Учебное пособие по DBT (инструмент построения данных)
- Построение многомерных хранилищ данных с помощью dbt
- Материализации
- Как мы структурируем наши проекты dbt
- Устраняем «ад зависимостей» с помощью dbt
- Использование DBT для построения архитектуры Medallion Lakehouse (Azure Databricks + Delta + DBT)
- dbt Core, Snowflake и GitHub Actions: пет-проект для дата-инженеров
dbt - это один из ключевых инструментов современной аналитики и modern data stack.
Давайте разберемся почему он завоевал любовь аналитиков и дата инженеров:
- SQL код в базе? Прощайте, представления и хранимые процедуры. dbt позволяет хранить весь аналитический код в Git и воссоздавать все таблицы одной командой.
- Запутались в обновлениях таблиц? dbt автоматически строит data lineage от источников до аналитических витрин, обеспечивая их своевременное и правильное обновление.
- Ожидание готовности данных? С dbt аналитики могут самостоятельно трансформировать данные с помощью SQL, минуя необходимость в сложных инструментах вроде Spark или Hadoop.
- Работа теряется среди таблиц? dbt создаёт интерактивный каталог данных с документацией, делая вашу работу видимой и понятной для всех участников процесса.
SQL + dbt = God Mode Data Modeling
Артемий Козырь — видео про подходы к созданию витрины корпоративных метрик. Артем рассказывает кейс решения бизнес-задачи — создания дашборда на 50 ключевых метрик для регулярной встречи топ-менеджеров.
На кейсе создания витрины корпоративных метрик рассмотрим:
— Элементы functional programming c dbt macros
— Интерактивный UX с dbt Power User + CLI
— Импорт и переиспользование кода с dbt packages
— Универсальный код и окружения с dbt adapters
Бизнес-задача: Дашборд для Weekly Business Review (WBR)
Требования к дашборду:
— Nesting: от верхнеуровневых метрик к детальным
— Набор измерений для Slice and Dice
— Формат графика для метрики
— Линии для Year over Year (abs + rel %)
— Визуализация целевых значений (targets)
— Решение «Hardcore Cube»
— Решение «Direct Runtime»
— Aggregate awareness (Looker) как оптимизация производительности
— Как отразилась смена СУБД с Amazon Redshift на Snowflake на решении?
Как всё это использовать у себя?
— Находите повторяющиеся паттерны и переиспользуйте код (DRY)
— Пишите универсальный код с dbt
— Не изобретайте велосипед - используйте packages
— Ищите баланс между материализацией и runtime queries
— Чем меньше кода, тем лучше
Кроме того, dbt предлагает тестирование качества данных, проверку соответствия данных заранее заданным условиям (data contracts), интеграцию с Airflow и многое другое, что делает его неотъемлемой частью современного аналитика.
Введение в dbt: основы моделирования данных | INZHENERKA.TECH
Тайм-коды:
00:00 Начинаем
02:04 Рассказываем об ИнженеркаТех
03:54 В чем практическая ценность dbt?
05:51 Начало Data Lake
08:35 Большие SQL скрипты
10:12 Glue Spark ETL
13:00 Решение через Data Builder
17:40 Как продать команде свое решение?
19:18 Преимущества data build tool
28:33 Анатомия проекта на дбт
30:00 Создаем проект
01:10:15 Моделирование данных с dbt
01:21:41 Проблемы с аналитикой в БД
01:27:50 Оркестрация data build tool
01:30:00 Преимущества на dbt
01:31:10 Подводные камни ди би ти
01:35:10 Симулятор data warehouse для аналитиков и инженеров данных
Построение дата платформы с помощью dbt
Интересный доклад Евгения Ермакова про построение дата платформы в toloka.ai, которая, получив независимость от Yandex, вынуждена была переезжать на новые технологии. В итоге, выбор пал на databricks, dbt, airflow и tableau. Автор рассказывает о том, почему был сделан такой выбор и как в итоге это все работает.
Основные моменты следующие:
- Сама toloka - это система для краудсорсинга, куда заказчики приходят с задачками навроде разметить данные, а с другой стороны на платформе зарегестрированы люди, которые их выполняют
- Архитектура базируются на трех китах:
-- Data lakehouse
-- Процессы в соответствии с подходом data mesh
-- Современный технологический стек
- До переезда на новые технологии ребята использовали много своего, часть из которого уже есть в opensource: YTsaurus, datalens
- После переезда выбрали новые технологии и dbt стал ядром системы, закрывая функциональность: data quality, data catalog/ data observability, batch processing (вместе со spark), orchestration (вместе с airflow)
- Изначально dbt (data building tool) нужен был в качестве удобного инструмента для transformation шага в ETL/ELT
- Интересно, что в концепции компании dbt есть мнение и относительно ролей, где помимо стандартных data engineers и data analysts появляется еще analytics engineer. В итоге, data engineers - это те, кто делают так, чтобы data платформа работала эффективно, data analysts ищут инсайты в данных и помогают их эффективно использовать, а вот analytics engineers - это ребята, что-то среднее между другими двумя + хорошо укладывается в концепцию data mesh, где нет централизованной дата-команды, а есть дата-команды по доменам
- Основой dbt-проекта является dbt model. Модель состоит из файла с описанием логики (.sql или .py файл) и файла с описанием конфигурации. В .sql файле есть запрос на формирование объекта, другие модели используются через ref() или source() + используется jinja шаблонизация. В .py файле возвращаем dataframe с рассчитанными данными, есть доступ ко всем возможностям pyspark + другие модели тоже используются через ref() или source()
- Материализацию запроса dbt берет на себя и есть разные стратегии, из которых самая интересная incremental
- Настройки хранятся в dbt_project.yaml и profiles.yaml
- dbt поддерживает большое количество баз данных, например, postgres, mysql, clickhouse, ...
- dbt - это консольная утилита, например, при запуске dbt build происходит сборка всех зависимостей между моделями, а также компиляция python/sql запросов и запись в manifest.json
- Команда dbt run запускает скомпилированные запросы, где запуск можно настроить по разному, но интересно запускать по графу
- Кстати, dbt умеет генерировать документацию командой dbt docs generate и дальше можно посмотреть на lineage данных
- Также мы можем писать тесты в том же месте, где мы описываем модели, а дальше запускать их при помощи dbt tests. Например, можем проверять unique или not null на поле, а также если хотим relations между моделями
- У dbt есть еще много возможностей, но про них стоит почитать самостоятельно:)
- Дальше автор рассказывает как сделать data mesh на уровне dbt + airflow. Автор рассматривает варианты вида:
-- Монолитный - один dbt проект на всю компанию
-- Микросервисный - отдельные dbt проекты на каждый домен
-- Layered - отдельные dbt проекты по уровням
-- Смешанный - анархия, где проекты создаются кто как хочет
Выбрали монолитный подход и получили аля монорепо под data mesh, в котором живут все. Обусловлено это было тем, что при микросервисном подходе ломались все связки между моделями (до 1.6 не могли называть модели одинаково в разных проектах + была проблема с импортом друг друга, так как это приводило к циклическим зависимостям).
Из интересного еще сделали конвертор графа исполнения dbt в airflow формат, чтобы запускать DAG из airflow.
В итоге, ребята реализовали свой подход к data mesh при помощи open source инструмнетов и вся схема выглядит достаточно стройно.,
DBT: Overview - dbt building blocks and principles;
- Connecting to DWH: profiles.yaml;
- Configuration: dbt_project.yaml;
- Launching first project;
Курс по dbt с нуля. Занятие 1. Преимущества dbt. Запускаем dbt из docker в связке с ClickHouse
План занятия:
- Что такое dbt
- Преимущества dbt
- Разворачиваем ClickHouse с помощью Docker-compose
- Наполняем ClickHouse тестовыми данными
- Упаковываем dbt-clickhouse в docker контейнер
- Инициализируем проект dbt (dbt init)
- Настраиваем проект (dbt_project.yml и profiles.yml)
- Проверяем корректность настройки (dbt debug)
- Создаем и выполняем первую dbt модель (dbt run)
Курс по dbt с нуля. Занятие 2 Особенности установки на Windows. Запуск ClickHouse в wsl 2.
Полезные материалы
- К чему стремимся, используя dbt?
- Матрица зрелости dbt-проекта
- Кейс Wheely + dbt
- Что дальше и как это использовать у себя
- Сформулируем требования
- Что нужно для запуска dbt jobs?
- Какие бывают Environments
- Критерии выбора решения для запусков
- Обзор решений: devcontainer, dbtCloud, Github Actions, Gitlab CI, Airflow / Prefect / Dagster, Argo Workflows
- Матрица оценок по критериям
- Выводы: что, в каких случаях и почему лучше использовать
- Доступны гиперссылки и .gif-анимация.
Не всем компаниям нужен DBT
Интересное обсуждение на Reddit о том, нужен ли вашей компании DBT или его внедрение - это просто следование трендам.
1. With dbt you will move fast
Если вы не следуюете DBT way в работе, то ваша команда может двигаться медленее.
Многие команды пытались внедрить традиционное ETL-мышление в dbt и ухудшали ситуацию для себя и организации.
2. dbt will improve Data Quality and Documentation
dbt дает вам возможность генерировать документацию и добавлять тесты качества данных, но в этом нет никакой магии: кто-то должен это делать. Существует много проектов, в которых практически нет тестов DQ, а документация содержит только название столбцов.
3. dbt will improve your data pipeline reliability
Есть много проектов, в которых используется dbt, но нет процесса CI/CD для тестирования и развертывания кода или нет проверки кода и правильного моделирования данных. Код-спагетти, который у вас есть, возник не потому, что вы не использовали dbt.
4. You don't need an Orchestration tool with dbt
Целью dbt является преобразование ваших данных, и точка. У вашей платформы данных есть и другие этапы, которые должны работать гармонично. Что происходит, когда загрузка данных прерывается или задерживается? Как вы уже догадались, трансформация все еще продолжается, конечные пользователи считают, что отчеты обновлены, а вы проводите весь день, борясь с очередным пожаром. Вам всегда был нужен оркестратор, и dbt не решит эту проблему.
DBT — это не волшебная пуля, но это ингредиент в рецепте вашего успеха. При правильном подходе команды достигают своей цели, но организация должна понимать, что технология сама по себе не является решением. В вашем плане цифровой трансформации должен быть поток работы по переработке процессов с выделенными ресурсами для его реализации.
- Перевод главы «Введение в dbt» из книги Unlocking dbt
На канале Дмитрия Аношина, вышло 2 офигенных видео по DBT, при этом дополнительно узнаете о "наборе джентльмена" в системе контроля версий Git, настройке CI/CD в Git Actions, основы организации хранилищ данных и кучу всего интересного.
Оставлю их тут для вас, чтобы долго не искать!
DBT Best Practices в действии
опыт проекта California Integrated Travels
Что у них сработало:
- Четкое определение объема изменений с подробными комментариями и шаблонами PR
- Автоматический отчет о влиянии на данные в каждом PR
- Тщательное QA через сравнение prod и dev данных
Почему это важно?
С ростом популярности dbt проекты становятся все масштабнее, а количество людей, работающих с данными, постоянно растет. В таких условиях поддержание качества данных и стабильности production-среды становится серьезным вызовом.
О проекте Cal-ITP:
- Почти 400 dbt моделей
- Охватывает платежи, расписания, остановки и даже переводы
- Сложная структура данных (хотя точные объемы не раскрываются)
Ключевой вывод:
правильные практики разработки и тестирования критически важны для масштабных dbt проектов.
data load tool (dlt)
data load tool (dlt) это Python библиотека с открытым исходным кодом, которая упрощает загрузку данных https://github.com/dlt-hub/dlt
- Автоматическая схема: проверка структуры данных и создание схемы для места назначения.
- Нормализация данных: согласованные и проверенные данные перед загрузкой.
- Полная интеграция: Colab, AWS Lambda, Airflow и локальные среды.
- Масштабируемость: адаптируется к растущим потребностям в данных в производстве.
- Простота обслуживания: понятная структура конвейера данных для обновлений.
- Быстрое исследование: быстрое исследование и получение информации из новых источников данных.
- Универсальное использование: подходит для несистематических исследований и создания сложных погрузочных инфраструктур.
- Начните работу за считанные секунды с помощью CLI: Мощный CLI для управления, развертывания и проверки локальных pipelines.
- Поэтапная загрузка: загружайте только новые или измененные данные и избегайте повторной загрузки старых записей.
- Открытый исходный код: бесплатно и под лицензией Apache 2.0.
SQLMesh
Раньше я думал, что это имеет отношение к Data Mesh подходу. Оказывается, это конкурент dbt. То есть, решает такие же задачи, как dbt - трансформация с помощью SQL внутри хранилища данных. (T в ELT).
Инструмент тоже open source. Некоторые вещи реализованы по другому, например у них главная фишка - это виртуальные среды. Если в dbt мы сами выбираем физическое место (схему, базу), где dbt будет создавать таблицы и вьюхи, то в SQLMesh у нас этот процесс управляется виртуальными средами. (Тут больше про envs https://tobikodata.com/virtual-data-environments.html)
Есть и другие плюшки, например встроенный CRON (ставить модели на расписание), SQL клиент в UI, CI/CD бот, аналог SDF (SQL компилятор на базе SQLglot).
У них есть интеграция для dbt/dlt, то есть вы можете легко мигрировать ваши dbt проекты на SQLMesh.
Стоит ли выбрать SQLMesh вместо dbt?
На мой взгляд, если вас заботят инженерные аспекты построения конвейеров данных (а это важно), или если дата-инженеры создают и управляют "T", то вам стоит выбрать SQLMesh.
Нужен ли вам широкий набор интеграций с различными платформами и инструментами для работы с данными и/или хотите использовать что-то с более крупным, зрелым сообществом? Тогда, возможно, стоит остановиться на dbt.
Если кратко, я бы сказал, что выбор между SQLMesh и dbt сводится к тому, стоит ли дополнительная сложность SQLMesh того для вас и вашей команды. Интеграции с другими инструментами и зрелость сообщества со временем подтянутся.
Следует отметить, что SQLMesh совместим с dbt, что означает возможность использования SQLMesh поверх существующего проекта dbt в качестве обёртки, используя функции SQLMesh, такие как виртуальные среды данных. Возможно, стоит попробовать и посмотреть, понравится ли вам SQLMesh?
Также не забывайте, что SQLMesh НЕ заставляет писать огромное количество yaml и Jinja. Некоторым нравится иметь всё в yaml, но я предпочитаю определять метаданные прямо в файлах моделей. Меньше переключений контекста - лучше для меня. Мне также никогда не нравился синтаксис Jinja. SQLMesh позволяет использовать чистый Python, что является большим плюсом.
Мое мнение: я бы не стал изучать SQLMesh, так как dbt очень популярный, работает отлично, большое сообщество, есть VC деньги на развитие продукта и есть спрос на такие скилы. SQLMesh это нишевой продукт, который больше подходит энтузиастам, которые любят плыть против течения и у них много свободного времени, чтобы внедрять такие решения. Главная цель пробовать такие нишевые продукты - быть в теме и такие insights порождают хороший диалог с нанимающим менеджером.