Table of Contents

Введение в dbt

В 2006 году британский математик и предприниматель в области анализа данных Клайв Хамби ввел фразу:

«Данные — это новая нефть»,

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

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

Именно это привлекает нас, авторов этой книги, в dbt. Одним из ключевых навыков любого специалиста по данным является умение писать SQL, и dbt делает этот навык центральным. Хотя dbt — относительно новый инструмент, для тех, кто уверенно работает с SQL, порог вхождения минимален. Эта глава является введением ко всей книге. Мы расскажем, что такое dbt, для кого он предназначен, как он вписывается в вашу систему работы с данными и многое другое. Также мы дадим обзор продукта и познакомим с основными терминами, которые будут использоваться далее.

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

Что такое dbt?

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

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

Важно понимать, что dbt — это только инструмент для преобразования данных. Он не занимается перемещением данных между системами. В рамках архитектур ETL (Extract-Transform-Load) или ELT (Extract-Load-Transform) dbt отвечает исключительно за этап преобразования. Для построения полноценного конвейера ETL/ELT потребуется комбинировать dbt с другими инструментами, такими как Fivetran, Airflow или Meltano.

Основные ограничения и особенности dbt:

dbt не содержит механизмов для вычислений. Все вычисления выполняются с использованием ресурсов хранилища данных, к которому он подключается.
Каждый создаваемый в dbt модуль (за исключением моделей на Python) является SQL-запросом. Даже если используются шаблоны Jinja, итоговый код всегда компилируется в SQL.
dbt автоматически создает объекты базы данных (таблицы, представления и т. д.), избавляя вас от необходимости делать это вручную.

История создания dbt

dbt был создан в 2016 году компанией под названием Fishtown Analytics, которая в 2020 году была переименована в dbt Labs.

Fishtown Analytics, консалтинговая компания в области аналитики, расположенная в районе Фиштаун в Филадельфии, была основана с целью помощи компаниям с финансированием серий A и B в реализации продвинутой аналитики. Основной задачей компании было улучшение методов работы аналитиков данных. Основатели верили, что анализ данных должен напоминать подходы, применяемые в разработке программного обеспечения, и стремились найти подходящее решение. Поскольку в данной области существовал пробел, они создали dbt, чтобы восполнить его.

Интересно, что изначально dbt был открыт исходным решением, добавляющим базовые возможности трансформации в Stitch, но видение для этого инструмента оказалось значительно шире. Fishtown Analytics (до переименования) разработала платную версию инструмента под названием Sinter, которая предоставляла пользователям дополнительные возможности, включая планирование задач, ведение журналов, оповещения и многое другое. В 2019 году этот инструмент был переименован в dbt Cloud, и его функциональность значительно выросла, превратившись в то, чем он является сегодня.

Существуют две основные версии инструмента: dbt Core и dbt Cloud, которые подробно рассматриваются в этой книге.

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

В dbt Cloud доступны макросы и другие функции, которые можно изменять, влияя на поведение инструмента по умолчанию. Однако вы не сможете изменять все, как это возможно в dbt Core. Некоторые элементы dbt Cloud, такие как интегрированная среда разработки (IDE), планирование задач, и управление заданиями, не являются открытыми. Эти аспекты рассматриваются кратко в этой главе и более подробно в главе 2.

Несколько важных аспектов dbt, которые необходимо понять на раннем этапе:

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

Во-первых, dbt не содержит вычислительных мощностей для выполнения запросов.

Все запросы и преобразования dbt выполняются с использованием вычислительных мощностей вашего хранилища данных. Например, если вы используете AWS Redshift в качестве хранилища данных, dbt будет использовать вычислительный кластер AWS Redshift для создания моделей. У dbt нет собственной вычислительной инфраструктуры для обработки данных, и в обозримом будущем это вряд ли изменится.

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

Во-вторых, каждая модель, созданная в dbt, компилируется в SQL-запрос, который затем выполняется в хранилище.

Исключением являются Python-модели, о которых мы подробно поговорим в главе 4. dbt добавляет Jinja в ваш SQL-код, что делает его более мощным и эффективным. Однако вся работа dbt в конечном итоге сводится к SQL-коду.

Важно понимать, что все модели в dbt пишутся в виде SQL-запросов SELECT.
Это может потребовать времени на привыкание, если вы привыкли использовать команды манипулирования данными (DML), такие как UPDATE, INSERT, MERGE или DELETE. Однако компилятор dbt автоматически добавляет необходимый шаблонный код DML или DDL (языка определения данных), чтобы управлять объектами базы данных.

Наконец, dbt берет на себя создание объектов базы данных в вашем хранилище.

Если вы ранее работали с хранилищами данных, вы, возможно, привыкли предварительно создавать схемы объектов перед их преобразованием, но теперь это больше не требуется. Хотя такая возможность существует, это считается плохой практикой. Мы рекомендуем использовать dbt для создания объектов. Вы можете управлять такими аспектами, как типы данных, через код с помощью команд, таких как CAST.

Инженер-аналитик

Если вы долго работаете с dbt, то неизбежно столкнетесь с термином «Инженер-аналитик» (Analytics Engineering). Это понятие было введено командой dbt для обозначения того, чем занимаются пользователи dbt. Инженеры-аналитики представляют собой сочетание традиционного инженера данных (Data Engineer) и аналитика данных (Data Analyst). Они предоставляют бизнес-пользователям доступ к обработанным и структурированным наборам данных, упрощая потребление данных.

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

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

Инженер данных (Data Engineer)

Создание пользовательских интеграций данных.
Управление оркестрацией всей конвейерной обработки данных.
Разработка и развертывание конечных точек для моделей машинного обучения.
Построение и поддержание платформы данных.
Оптимизация производительности хранилищ данных.

Инженер-аналитик (Analytics Engineer)

Предоставление чистых и преобразованных данных, готовых для анализа.
Применение лучших практик разработки программного обеспечения к аналитическому коду (например, контроль версий, тестирование, CI/CD).
Поддержка документации данных и определений.
Обучение пользователей использованию инструментов визуализации данных.

Аналитик данных (Data Analyst)

Глубокий анализ для ответа на специфические бизнес-вопросы.
Работа с бизнес-пользователями для понимания их требований к данным.
Разработка и развертывание конечных точек для моделей машинного обучения.
Создание отчетов и информационных панелей.
Разовый (ad-hoc) анализ данных.

Новая роль или хорошая маркетинговая стратегия?

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

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

Инженерия аналитики берет аспекты, традиционно связанные с обеими ролями, и объединяет их. Компании (особенно с небольшими командами) занимаются этим десятилетиями, но dbt предоставляет платформу, которая делает этот процесс более эффективным.

Мы не считаем это чем-то отрицательным. Новый титул получил огромную популярность, увеличил осведомленность о бренде и дал пользователям dbt возможность объединяться. Это здорово!

Почему dbt ориентирован на аналитиков данных

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

Мы полностью поддерживаем эту идею, но также хотим отметить, что dbt является отличным инструментом для инженеров данных. Однако это не всегда получает должное внимание с точки зрения маркетинга.

dbt как инструмент для инженеров данных

Скорее всего, причина кроется в финансовой модели, а не в удобстве использования продукта. dbt Labs зарабатывает на подписке на dbt Cloud. Большинство инженеров данных комфортно работают с dbt Core, который является бесплатным и с открытым исходным кодом (и многие его используют). В то же время аналитики данных, вероятно, менее заинтересованы в управлении развертыванием dbt Core.

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

Примечание: dbt — это не только инструмент для аналитиков данных, но и великолепный инструмент для инженеров данных.

Роль dbt в современной архитектуре данных

Прежде чем понять роль dbt, важно осознать значимость ELT (extract-load-transform, извлечение-загрузка-преобразование). Мы исключаем ETL (extract-transform-load, извлечение-преобразование-загрузка), поскольку большинство облачных архитектур не используют этот подход, хотя приведенные далее утверждения актуальны и для него. ELT стал популярным в проектировании хранилищ данных благодаря мощным современным аналитическим базам данных. Такие облачные хранилища данных, как Snowflake, Synapse, Databricks и BigQuery, обладают высокой скоростью, масштабируемостью и способны выполнять преобразования данных на уровне базы данных. Это особенно верно в контексте разделения хранения и вычислений, характерного для Snowflake и архитектуры Lakehouse.

Одной из главных причин популярности ELT в облачных сервисах является задержка в сети и время, необходимое для передачи данных. Хотя современные сетевые скорости высоки и продолжают расти, объемы данных также увеличиваются. Если вы работаете с большими объемами данных, передаваемых через Интернет, это все равно может занять значительное время. Поэтому важно загружать данные только один раз.

Для упрощения рассмотрим пример: предположим, у нас есть 10 таблиц общим объемом 100 ГБ, которые нужно передать с локального сервера базы данных в AWS S3. Это займет 5 часов. Если добавить преобразования в этот процесс (настройка ETL) и обнаружить ошибку, придется повторять весь процесс заново. Или, если спустя месяц изменятся требования к использованию этих данных, придется снова загружать данные, включая новый объем, накопленный за этот период. Если таких источников данных становится больше, вы быстро начнете тратить массу времени.

В случае загрузки сырых данных (ELT) данные загружаются только один раз. Да, вы фактически храните дополнительную копию исходных данных, и преобразование при загрузке могло бы уменьшить объем, но хранение в облаке настолько дешево, что для большинства это не проблема. Когда сырые данные уже загружены, работать с ними становится намного быстрее. Если допущена ошибка, вы легко можете ее исправить или даже начать все сначала, что экономит массу времени. Более того, при запуске новых проектов, которые также будут использовать эти данные, не придется снова их загружать, что сокращает общий объем хранения и время.

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

Рассмотрим высокоуровневые шаги, связанные с архитектурой ELT в хранилище данных, и то, как dbt справляется с этим. На рисунке 1-2 представлена диаграмма типичных элементов, встречающихся в процессе создания хранилища данных. Независимо от того, используете ли вы dbt для преобразований, эти аспекты стоит учитывать при работе с любым выбранным инструментом.

Рисунок 1-2. Высокоуровневые этапы проектирования хранилища данных на основе ELT

1. Определение и настройка загрузчика данных

Первый шаг при создании ELT-хранилища данных — это выбор и настройка загрузчика данных. Загрузчик отвечает за разработку конвейеров загрузки данных из исходных систем в ваше хранилище. Этот инструмент может быть любым, который вы выберете. Как уже упоминалось, dbt используется исключительно для преобразования данных, поэтому эта часть процесса выходит за рамки его применения. Однако правильный выбор загрузчика данных — важный этап перед началом работы с dbt. Если вы не знаете, с чего начать, рекомендуется обратиться к поставщику вашего хранилища данных за рекомендациями. Некоторые инструменты загрузки данных отлично интегрируются с определенными платформами и предоставляют дополнительные преимущества, в то время как другие могут быть несовместимы.

Облачные провайдеры, такие как Azure, AWS и Google Cloud, предлагают собственные решения (например, Azure Data Factory, AWS Glue, Google Cloud Data Fusion), но не забывайте о сторонних инструментах, таких как Fivetran, которые предоставляют нативные коннекторы и значительно упрощают процесс загрузки данных. Главное — провести тщательный анализ, поскольку выбор инструмента может повлиять на успех проекта.

2. Загрузка необработанных данных

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

Если вы используете dbt для преобразования данных, важно, чтобы сырые данные находились в той же системе, где будут производиться преобразования. Например, если данные сначала загружаются в озеро данных, а dbt нацелен на AWS Redshift, вам нужно будет предварительно загрузить данные в Redshift перед их использованием. Мы рекомендуем рассмотреть архитектуры озер и платформы вроде Snowflake, которые позволяют загружать данные напрямую с преимуществами разделения хранения и вычислений.

3. Снимок (snapshot) данных

После загрузки необработанных данных следующий шаг — создание их снимков (snapshot). Это не следует путать с функцией снимков в dbt. Цель этого шага — защитить необработанные данные от изменений, так как любая ошибка может привести к необходимости повторной загрузки или к потере исторических данных. Снимки создаются путем выборки нужных данных из сырых объектов/таблиц для дальнейшей работы.

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

4. Преобразование данных в соответствии с моделью данных

На этом этапе данные нормализуются/денормализуются, очищаются и моделируются для аналитики, машинного обучения и других задач. Этот шаг включает преобразование данных из различных систем (например, транзакционных) в оптимизированный формат для отчетности и аналитики. Это основная задача dbt. Конкретные преобразования зависят от структуры вашей модели данных, о которой будет рассказано в следующем разделе главы.

5. Тестирование данных

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

6. Развертывание

Код не должен разрабатываться напрямую в производственной среде. Для безопасного и быстрого переноса протестированного кода между средами часто применяются DevOps-подходы, такие как CI/CD (непрерывная интеграция/развертывание). Например, Azure DevOps может использоваться в Azure, а dbt Cloud позволяет управлять этим процессом из одного инструмента. В десятой главе описано, как выполнять CI в dbt Cloud и GitHub Actions для пользователей dbt Core.

7. Документация

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

8. Использование инженерных практик

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

9. Подача данных конечным пользователям

После завершения всех преобразований данные становятся доступными для бизнес-пользователей или других команд (анализ данных, построение отчетов, машинное обучение).

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

Моделирование данных

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

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

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

Прежде чем начать, определите, действительно ли вам нужно хранилище данных. В некоторых случаях оно может быть не нужно, поэтому важно обдумать это заранее. Вот несколько вопросов, ответив «да» на которые, вы можете понять, что хранилище данных вам все-таки нужно:

Необходимо ли иметь единую версию истины для ваших данных?
Будут ли различные отделы использовать эти данные?
Нужно ли анализировать данные из разных источников?
Требуется ли сохранять исторические данные и анализировать метрики на определенный момент времени?
Есть ли у вас большой объем данных, требующий преобразования?
Выполняете ли вы много сложных запросов на регулярной основе?

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

Частые ошибки при использовании dbt

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

Например:

Дублирование работы.
Создание нескольких версий данных (размывание истины).
Неэффективные запросы.
Сложности с передачей знаний новым членам команды.

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

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

В этой книге мы не будем подробно разбирать выбор подхода, но приведем список наиболее распространенных методов моделирования данных:

Data Vault: использует hubs (центры), links (ссылки) и satellites (спутники) для хранения данных.
Dimensional Modeling: использует факты и измерения для хранения данных.
Одна большая таблица (One Big Table): денормализованные данные, все значения хранятся в одной таблице.
Реляционная модель (Relational): данные хранятся в нормализованном виде.
Стандартные модели данных (Common Data Models): открытые и поддерживаемые сообществом модели, используемые в определенных отраслях.

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

Навыки, необходимые для работы с dbt

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

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

Ниже приведен список ключевых технических навыков, которые полезно иметь перед началом работы с dbt. Однако не все они равнозначны по важности, и многие из них можно освоить по мере работы:

SQL (основной навык)
Jinja (шаблонный язык для Python-разработчиков)
YAML (конфигурационные и описательные файлы)
Python (в зависимости от сценария использования)
Моделирование данных
Контроль версий (Source Control)

В следующих разделах описаны каждый из этих навыков и их роль в работе с dbt, а также оценка важности предварительного опыта по шкале от 1 до 5.

Навык #1: SQL

Основной навык, необходимый для эффективной работы с dbt, — это умение писать запросы на языке SQL (Structured Query Language). Для работы с dbt достаточно уметь писать простые запросы SELECT — это базовый уровень, который многие осваивают в начале изучения SQL.

Однако продвинутые знания SQL позволят вам быть более эффективным разработчиком. Простых SELECT-запросов может хватить на начальном этапе, но в дальнейшем вам, скорее всего, потребуется использовать более сложные запросы. Например, мы рекомендуем изучить CTE (Common Table Expressions) и оконные функции (Window Functions), чтобы повысить уровень владения SQL.

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

Примечание: Умение писать SELECT-запросы на SQL — основной технический навык, необходимый для начала работы с dbt. Остальные навыки можно развить со временем или они не критичны для большинства сценариев.

Оценка опыта: 4/5. dbt не требует продвинутых знаний SQL, но базовые знания обязательны. Если SQL — это что-то совершенно новое для вас, возможно, стоит рассмотреть другие инструменты.

Навык #2: Jinja

Следующий важный навык — это Jinja. Jinja — это шаблонный язык, используемый в Python, который позволяет выполнять сложные операции, трудновыполнимые только средствами SQL. Если вы ранее не работали с Python, Jinja может быть для вас новым инструментом.

Однако пугаться не стоит — основные команды Jinja легко изучить, и dbt хорошо адаптирован для новичков. Есть несколько ключевых команд Jinja, которые важно знать, а остальное можно освоить по мере работы.

В dbt Jinja помогает SQL-разработчикам создавать динамичные запросы. Мы посвятили изучению Jinja отдельную главу (глава 6). Хотя этот навык важен для полного использования возможностей dbt, вы можете успешно выполнять проекты, используя лишь базовые элементы Jinja.

Оценка опыта: 2/5. Опыт работы с Jinja или Python полезен, но не обязателен. Базовые команды легко освоить, а продвинутые возможности могут потребовать некоторого обучения.

Навык #3: YAML

Знание YAML полезно для работы с dbt, поскольку этот формат используется для описания конфигураций и свойств проекта. Опыт работы с YAML не является обязательным, но он поможет вам быстрее освоиться.

YAML отличается простотой и читаемостью, поэтому даже если вы никогда с ним не работали, вы сможете быстро его освоить. Мы рассмотрим основы YAML в этой книге, чтобы помочь вам начать.

Оценка опыта: 2/5. Опыт работы с YAML полезен, но базовые знания можно быстро получить даже без предварительного опыта.

Навык #4: Python

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

Поддержка Python в dbt позволяет создавать пользовательские скрипты и плагины, которые дополняют возможности SQL. Однако dbt Labs уточняют, что Python не предназначен для замены SQL, а лишь закрывает его пробелы.

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

Оценка опыта: 1/5 для большинства пользователей. Если вы знаете, что вам потребуется Python, эта оценка будет выше.

Навык #5: Моделирование данных

Знание основ моделирования данных и наличие плана — важный навык для работы с dbt. Ранее в этой главе мы упоминали, что многие пользователи dbt пренебрегают этим аспектом, что может привести к проблемам.

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

Оценка опыта: 1/5, если в команде есть опытные специалисты. 4/5, если вы сами проектируете и внедряете модели.

Навык #6: Контроль версий (Source Control)

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

В dbt контроль версий используется для отслеживания изменений в моделях, данных, снимках (snapshots) и тестах. Это также позволяет откатывать изменения при необходимости.

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

Оценка опыта: 2/5. Базовые знания контроля версий полезны, и любой опыт в этой области легко переносится на работу с dbt.

Преимущества dbt

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

Специализация на трансформации данных и аналитике

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

Ориентирован на пользователей SQL

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

Открытый код и активное сообщество

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

Совместная работа

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

Гибкость

dbt может работать с различными источниками данных и целевыми базами данных, что делает его хорошим выбором для организаций, которым необходимо интегрировать данные из нескольких систем и источников.

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

Подключение к вашей базе данных

Как упоминалось ранее, dbt не имеет собственного вычислительного ядра и полагается на вычислительные мощности хранилища данных или базы данных, к которым он подключается. Если целевая платформа для dbt не настроена, вы не сможете выполнять никакие задачи. dbt можно настроить для работы с различными SQL-совместимыми базами данных, хранилищами данных, озерами данных, движками запросов и аналитическими платформами. Однако уровень поддержки зависит от конкретного подключения. Все подключения делятся на четыре категории: поддерживаемые dbt Labs, поддерживаемые поставщиками, поддерживаемые сообществом и ещё не реализованные. На рисунке 1-3 показаны текущие поддерживаемые соединители. Обратите внимание, что этот список может измениться, поэтому рекомендуется проверять официальную документацию dbt для получения актуальной информации.

1. Поддерживаемые dbt Labs

Эти адаптеры разрабатываются и поддерживаются dbt Labs и на данный момент являются единственными, которые поддерживаются в dbt Cloud. В текущий список входят: PostgreSQL, Redshift, Snowflake, BigQuery, Apache Spark, Starburst и Trino. Ожидается, что этот список будет расширяться. Если вы планируете использовать dbt Cloud и не видите свою платформу в списке официально поддерживаемых, мы рекомендуем проверить последнюю документацию dbt Labs или обратиться в службу поддержки, чтобы узнать, планируется ли добавление вашего инструмента.

2. Поддерживаемые поставщиками

Эти адаптеры разрабатываются и поддерживаются самими поставщиками продуктов, которые также предоставляют техническую поддержку. Как правило, это стабильные соединители с уже значительным количеством пользователей. Для их использования необходимо работать с dbt Core. На данный момент в этот список входят такие платформы, как: ClickHouse, Databricks, Cloudera Impala, Firebolt, Oracle, Trino, MindsDB, SingleStore, TiDB, Rockset, Starburst, Teradata и другие.

3. Поддерживаемые сообществом

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

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

4. Ещё не реализованные адаптеры

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

dbt Cloud vs. dbt Core

Существует два основных способа использования dbt: бесплатная версия с открытым исходным кодом под названием dbt Core и корпоративный продукт dbt Cloud.

dbt Core

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

Однако стоит отметить, что dbt Core не имеет собственных вычислительных ресурсов. Для планирования и выполнения задач dbt потребуется использовать сторонний сервис. Настройка dbt Core будет рассмотрена в главе 2. На рисунке 1-4 показан пример проекта dbt Core в популярной IDE Visual Studio Code (VS Code).

dbt Cloud

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

Браузерная IDE (с хостингом вычислительных мощностей)
Планировщик задач (с хостингом вычислительных мощностей)
Логирование и оповещения
Интеграция с GitHub и GitLab
Хостинг документации
Только адаптеры, поддерживаемые dbt Labs

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

Одним из главных отличий между dbt Core и dbt Cloud является способ их развертывания и использования:

dbt Core устанавливается и запускается локально,
dbt Cloud работает через веб-интерфейс.

Однако в dbt Cloud разрабатываются новые функции, которые позволят пользователям использовать собственную IDE, например, Visual Studio Code.

Хотя dbt Cloud проще в настройке и использовании, он может быть менее гибким в плане интеграции с другими инструментами или системами. Однако команда dbt Labs активно выпускает новые функции, чтобы улучшить возможности интеграции dbt Cloud с продуктами сторонних разработчиков.

Еще одно различие между dbt Core и dbt Cloud — это модель ценообразования.

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

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

Как выбрать?

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

Структура проекта

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

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

Эти функции мы рассмотрим в последующих разделах:

analyses
dbt_packages
logs
macros
models
seeds
snapshots
target
tests

На рисунке 1-6 представлен пример проекта в dbt Cloud. Однако структура будет практически идентична, если вы используете dbt Core через предпочитаемую IDE, например, VS Code.
Общий обзор

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

Папка №1: Analyses

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

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

Папка №2: dbt_packages

Каждый проект dbt включает файл packages.yml, который используется для добавления других open-source проектов в ваш проект. Эти пакеты могут значительно облегчить вашу работу, позволяя использовать разработки других разработчиков вместо создания всего с нуля.

Это похоже на использование pip для установки пакетов в среде Python. Существуют пакеты, которые содержат макросы (функции) для упрощения сложных преобразований SQL, а также пакеты для определенных наборов данных, которые уже включают модели для работы с ними.

Папка dbt_packages — это место, где эти пакеты материализуются в вашем проекте. Чтобы подключить пакет, нужно добавить его в packages.yml, а затем выполнить команду dbt deps. После этого модели из подключенного пакета станут доступны в вашем проекте.

Мы подробно рассмотрим настройку пакетов в главе 6, но также будем упоминать важные пакеты на протяжении всей книги. Рекомендуем ознакомиться с доступными пакетами через GitHub, Slack-сообщество dbt или на hub.getdbt.com.

Папка №3: Logs

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

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

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

Папка №4: Macros

Macros — это участки кода, которые можно повторно использовать в вашем проекте. Они аналогичны функциям в других языках программирования и пишутся с использованием Jinja. На самом деле, Jinja чаще всего используется именно в макросах. Поэтому темы Jinja и макросов объединены в одной главе, которая рассматривается в главе 6.

Папка №5: Models

Папка Models — основное место для выполнения преобразований данных в вашем проекте dbt. Это та часть, где вы будете проводить большую часть времени.

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

Стратегия организации этой папки важна для эффективной работы. В следующей главе мы обсудим рекомендуемую структуру, а в главе 4 углубимся в детали.

Папка №6: Seeds

Seed — это папка, где хранятся данные, которые загружаются в целевую базу данных перед выполнением моделей dbt.

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

Тема seed-файлов рассматривается подробно в главе 3.

Папка №7: Snapshots

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

Снимки — это копии данных из исходной базы данных на определенный момент времени. Они используются для отслеживания изменений данных и обеспечения актуальности моделей. Снимки напоминают медленно изменяющееся измерение второго типа (Type-2 Slowly Changing Dimension) с полями valid_from и valid_to, что позволяет сохранять историю записей.

Тема снимков рассматривается в главе 5.

Папка №8: Target

Target — это папка, которая выполняет несколько функций, но основные из них:

Хранение файлов метаданных.
Хранение скомпилированного SQL.

С каждым выполнением команды dbt создается один или несколько артефактов, которые сохраняются в этой папке. Эти артефакты включают файлы JSON:

manifest.json: содержит метаданные о конфигурации dbt, связях узлов и документации. Этот файл генерируется dbt автоматически и используется для создания документации и сравнения состояния проекта.
run_results.json: содержит результаты выполнения команд dbt. Часто используется для создания журналов в базе данных и мониторинга задач.
catalog.json и index.html: используются для создания сайта документации.

Кроме этих файлов, в папке Target есть два подпапки:

Compiled: хранит скомпилированные SQL-файлы, где Jinja-код заменен на «чистый» SQL. Эти файлы представляют собой SELECT-запросы без операций DDL или DML.
Run: здесь хранятся SQL-запросы, отправляемые в платформу данных, включая весь необходимый DDL и DML для создания объектов базы данных.

Важно отметить, что папка Target не используется для хранения seed-данных или снимков. Она предназначена исключительно для хранения результатов выполнения моделей и скомпилированного SQL.

Папка №9: Tests

Папка Tests используется для хранения тестов. Файлы тестов содержат SQL-запросы, которые проверяют точность и целостность результатов ваших моделей.

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

Эта тема рассматривается в главе 8, где подробно описываются встроенные тесты, кастомные тесты и тесты, входящие в состав open-source пакетов dbt.

Поддерживаемые типы файлов

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

.sql
Это наиболее распространённое расширение файлов, используемое для хранения SQL-скриптов.

.yml/.yaml
Используется для конфигурационных файлов в формате YAML. В dbt такие файлы определяют структуру вашей модели данных, а также зависимости и преобразования.

.csv
Используется для хранения данных в формате CSV (comma-separated values). dbt может использовать такие файлы как исходные данные (seed) для ваших моделей.

.py
Это расширение для Python-скриптов. dbt позволяет писать на Python для выполнения сложных преобразований данных или расширения функциональности dbt.

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

Это основные типы файлов, которые поддерживаются dbt на данный момент. В будущем могут появляться дополнительные возможности работы с другими форматами. Вы можете расширить функциональность dbt Core, написав собственный код или воспользовавшись сторонними библиотеками. Однако это потребует дополнительной настройки.

Для большинства пользователей достаточно будет создавать файлы с расширениями .sql и .yml.

Типы моделей

Работа с моделями в dbt — это основная часть вашего времени. Модели — это SQL-запросы, определённые в файлах с расширением .sql или модели на Python, которые выполняют преобразования данных.

В dbt есть четыре способа создания модели (материализации):

Table
View
Ephemeral
Incremental

1. Table

Таблицы — это объекты базы данных, в которых данные записываются на диск. Каждая команда dbt полностью пересоздаёт таблицу и перезагружает данные.

2. View

Представления (Views) — это объекты базы данных, которые хранят запрос. При каждом запросе к представлению выполняется SQL-код. Данные не переносятся и не записываются при использовании представлений, поэтому каждое выполнение кода требует пересчёта. В dbt представления являются настройкой по умолчанию.

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

3. Ephemeral

Эфемерные модели (Ephemeral) представляют собой CTE (Common Table Expressions). Они не сохраняются в базе данных и доступны только внутри dbt. Используйте их только при необходимости.

Совет: Освойте написание CTE, так как в dbt вы будете использовать их часто. Поскольку dbt позволяет писать только SELECT-запросы, вы не можете использовать временные таблицы или переменные таблиц.

4. Incremental

Инкрементные модели материализуются как таблицы, но с настройкой на добавление или обновление записей с момента последнего запуска dbt. Это удобно при работе с большими объёмами данных, чтобы избежать их полной перезагрузки.

Важно: Хотя вы пишете только SELECT-запросы, dbt компилирует их в команды, необходимые для обновления данных (например, UPSERT или MERGE).

Снепшоты (Snapshots)

Снепшоты в dbt — это особый тип объектов, который, однако, в некоторой степени схож с материализациями, рассмотренными ранее. Снепшоты материализуются в виде таблицы и применяются, когда требуется отслеживать изменения данных с течением времени. По сути, такие преобразования реализуют Type-2 медленно изменяющееся измерение (Slowly Changing Dimension, SCD).

Это означает, что при обнаружении изменений между исходными данными (source) и целевыми (target), в таблице создаётся новая строка вместо перезаписи существующего значения.

Как видно из структуры проекта, снепшоты хранятся отдельно от других объектов, поскольку обладают уникальными характеристиками. Похожим образом работают инкрементные модели, однако мы не рекомендуем начинать с них, если вы только осваиваете dbt. Использовать снепшоты следует по мере возникновения необходимости. В книге этой теме посвящена Глава 5, где она детально рассматривается.

Выполнение команд dbt

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

Ниже приведён обзор всех доступных команд, разделённых на:

Команды, поддерживаемые как dbt Cloud, так и dbt Core.
Команды, поддерживаемые только dbt Core.

На данный момент нет команд, поддерживаемых исключительно dbt Cloud.

Команды, поддерживаемые dbt Cloud и dbt Core

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

dbt build
Строит и деплоит модели для преобразования данных. При выполнении dbt build запускаются модели, тесты, снепшоты и загрузка исходных данных (seed) одной командой.

dbt deps
Загружает указанные версии пакетов из файла packages.yml.

dbt test
Выполняет тесты для проверки точности и надёжности моделей и данных. Тесты определяются в SQL-файлах, размещённых в папке test проекта.

dbt run-operation
Выполняет макрос.

dbt snapshot
Создаёт снепшот исходных данных. Эти данные позволяют dbt отслеживать изменения данных источника с течением времени и обеспечивать актуальность данных.

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

dbt show
Позволяет просмотреть результаты модели, теста, анализа или SQL-запроса непосредственно в терминале.

dbt source freshness
Проверяет актуальность исходных таблиц на основе настроек в файле sources.yml.

Команды dbt Core

Ниже приведён список команд, поддерживаемых исключительно в dbt Core:

dbt clean
Используется для очистки папки target и директории проекта dbt_project. Полезно для подготовки к новому сбору проекта с чистого листа.

dbt debug
Тестирует подключение к базе данных и предоставляет информацию для устранения неполадок.

dbt init
Инициализирует новый проект dbt в среде dbt Core.

dbt list
Показывает список всех ресурсов, определённых в вашем проекте.

dbt parse
Анализирует и проверяет содержимое проекта. Если в проекте есть ошибки синтаксиса, команда завершится с ошибкой.

dbt docs generate
Генерирует документацию для вашего dbt-проекта. Результат — набор HTML-файлов, содержащих информацию о моделях, включая их структуру, зависимости и исходные данные.

dbt docs serve
Локально запускает сервер документации и открывает сайт документации в вашем браузере.

Флаги команд dbt

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

Вот некоторые из флагов, используемых с командой dbt build:

--select
Запускает только определённые модели преобразования. После флага нужно указать имя модели. Этот флаг особенно мощный, так как позволяет фильтровать по имени пакета, модели, директории, пути, тегам, конфигурации, типу теста и имени теста.

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

--resource-type
Позволяет выбрать тип ресурса для выполнения.

--defer
Позволяет запускать модели или тесты без выполнения зависимостей. Это полезно, если нужно протестировать небольшую часть моделей в большом проекте.

--selector
Позволяет использовать заранее определённые селекторы ресурсов, сохранённые в YAML-файле.

Дополнительные флаги, которые не связаны с построением ресурсов:

--help
Показывает все доступные команды и аргументы. Полезно, если вы не помните доступные опции.

--vars
Передаёт переменные вашему проекту.

--full-refresh
Принудительно обновляет инкрементные модели. Удаляет существующие таблицы и создаёт их заново.

--fail-fast
Прерывает выполнение dbt, если хотя бы один ресурс не удаётся построить.

--threads
Определяет количество потоков, которые dbt будет использовать для построения моделей. Может ускорить процесс, выполняя модели параллельно.

--target
Указывает целевое подключение к базе данных. Этот флаг используется только в развертываниях dbt Core.

Заключение

Флаги и команды dbt предоставляют широкие возможности для кастомизации и управления процессами в проекте. Чтобы узнать больше о возможностях каждой команды и флага, обратитесь к официальной документации dbt. В книге мы будем часто ссылаться на эти команды и использовать их с наиболее распространёнными опциями.

Чувствительность к регистру

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

Чувствительность в самом dbt

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

SELECT * FROM {{ ref(‘customers’) }};
SELECT * FROM {{ ref(‘Customers’) }};
SELECT * FROM {{ ref(‘cUsToMeRs’) }};

Чувствительность базы данных

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

Чувствительность YAML

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

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

При выполнении команд dbt через командную строку регистр также имеет значение, как и при обработке SQL-скриптов или YAML-файлов. Например:

Правильное написание команды:

dbt run

Неправильное написание команды:

dbt Run # Ошибка
dbt rUn # Ошибка

Все команды выполнения dbt должны быть написаны только в нижнем регистре.

Чувствительность аргументов флагов

Флаги команд dbt (например, --select) также чувствительны к регистру. Это значит, что при указании модели для выполнения вы должны использовать точное имя модели с правильным регистром, как оно указано в вашем проекте.

Пример:
Допустим, в вашем проекте есть модель под названием Customers. Если вы выполните команду:

dbt run --select Customers

То dbt выполнит преобразование для этой модели.

Если же вы введёте модель с неправильным регистром:

dbt run --select customers # Ошибка
dbt run --select CUSTOMERS # Ошибка

То dbt выдаст сообщение об ошибке, что не удалось найти модель, и команда выполнится только после ввода правильного регистра.

Полезный совет

Работа с чувствительностью к регистру в dbt может быть неудобной. Мы рекомендуем изначально предполагать, что всё в dbt чувствительно к регистру. Это избавит вас от лишних сложностей и ошибок в будущем.

Что такое YAML?

YAML играет важную роль в работе с dbt, и важно хорошо понимать этот формат. YAML (расшифровывается как YAML Ain’t Markup Language или Yet Another Markup Language, в зависимости от контекста) — это человекочитаемый язык сериализации данных, который часто используется для конфигурационных файлов. Он упрощает задачу по сравнению с более сложными форматами, такими как JSON или XML, благодаря своей простой структуре.

Множество современных инструментов используют YAML в своих фреймворках.

Рассмотрим преимущества YAML:

Человекочитаемость.
Однозначность.
Переносимость между большинством языков программирования.
Удобство для систем контроля версий.
Строгие требования к синтаксису, обеспечивающие единообразие.
Простой и чистый синтаксис.
Быстрота внедрения.
Безопасность, исключающая уязвимости, присутствующие в других языках.
Простота в освоении.

В контексте dbt YAML используется для описания свойств и конфигураций.

Свойства описывают ресурсы проекта: их описания, тесты и источники.
Конфигурации указывают, как dbt строит ресурсы в хранилище данных (например, материализации, расположение объектов, теги).

Основы YAML

Если вы новичок в YAML, полезно понять фундаментальные концепции, такие как массивы и словари.

Массивы YAML

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

fruits:
— apple
— banana
— cherry

Словари YAML

Словари отображают пары ключ-значение и могут быть представлены двумя способами:

Блочное отображение (block mapping):
Ключи и значения разделяются двоеточием, а каждая пара пишется на новой строке:

database:
host: localhost
port: 5432
user: admin

Отображение в строке (flow mapping):
Ключи и значения разделяются запятыми, а пары заключаются в фигурные скобки:

database: {host: localhost, port: 5432, user: admin}

Для большинства YAML-файлов в dbt используется блочное отображение, так как оно считается стандартом для парсинга dbt.
Строгий синтаксис YAML

YAML очень строг к форматированию, что имеет как плюсы, так и минусы:

Плюс: единый стиль написания упрощает совместную работу.
Минус: даже небольшая ошибка (например, неправильный отступ) приведёт к сбою парсинга.

Поэтому важно быть внимательным к деталям при работе с YAML.

Роль YAML в dbt

YAML играет ключевую роль в настройке dbt-проектов. В dbt YAML-файлы делятся на два типа:

Конфигурационные файлы

Конфигурационные YAML-файлы управляют тем, как работает dbt.
Основной файл: dbt_project.yml. Этот файл автоматически создаётся при инициализации проекта dbt и располагается в корневой директории.

Он:

Определяет структуры папок.
Устанавливает типы материализаций.
Указывает расположение объектов.
Задаёт теги.

Вы не можете иметь более одного dbt_project.yml на проект. Если нужно изменить поведение dbt, это делается через этот файл.

Файлы свойств

Файлы свойств описывают различные ресурсы проекта, включая:

Описания моделей.
Тесты.
Источники данных.
Экспозиции.

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

Совет для новичков

Если вы никогда не работали с YAML, не переживайте — его легко освоить. Работа с YAML в dbt носит повторяющийся характер, так что вскоре вы приобретёте нужные навыки и уверенность. Если вы всё же столкнётесь с трудностями, обратитесь к онлайн-ресурсам и учебникам для более глубокого понимания.

Семантический слой

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

Однако при выпуске первой версии семантического слоя возникли ограничения, которые затрудняли его использование:

Отсутствие навигации по соединениям (join navigation).
Ограниченная поддержка платформ данных.

В начале 2023 года dbt приобрела компанию Transform, основанную бывшими инженерами Airbnb, которых считают новаторами в области семантического слоя. Эта новость стала значительным шагом вперёд, поскольку Transform уже решила многие из тех сложных задач, которые стояли перед dbt. Сразу после приобретения началась работа над интеграцией решений Transform в функционал семантического слоя dbt, что привело к полной переработке исходной версии.

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

Подготовка к изучению книги

В оставшихся главах книги мы детально рассмотрим описанные компоненты. Для удобства обучения примеры кода будут размещены в открытом репозитории GitHub Apress:
https://github.com/apress/unlocking-dbt.

Наш проект подключён к экземпляру Snowflake, но вы можете использовать любую базу данных, поддерживаемую dbt. Примеры кода достаточно просты и требуют минимальных изменений при работе с другими платформами. Если вы хотите использовать Snowflake, вы можете зарегистрировать пробный аккаунт на сайте Snowflake.com. Альтернативно, проект можно настроить для работы с любым другим адаптером dbt.

Подход к обучению

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

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

Резюме

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

Ключевые возможности dbt:

Использование SQL и Python для написания моделей трансформации данных.
Проведение тестов для проверки качества и консистентности данных.
Эффективность, надёжность и совместная работа благодаря применению лучших практик разработки ПО.

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