Выпуск #26. Разработка хранилищ данных с dbt

Опубликовано 02.02.2026

В одной из бесед с гостем подкаста обсуждалось последствие импортозамещения для консультантов SAP BW, долгие годы использовавших SAP-стек для построение хранилищ данных и аналитических систем. В той беседе был отмечен один из инструментов, который сейчас является, пожалуй, стандартом в сфере работы с данными. Этот инструмент называется dbt - data build tool.

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

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

Полезные ссылки

Руководство по созданию хранилищ данных с помощью dbt (dwh-book.ru)

Профиль профессиональной сети (Владимир Юсупов)

Слушайте подкаст на любимых платформах

Поделитесь подкастом с друзьями и коллегами

---

Расшифровка выпуска

00:00 - 01:43 Вступление

Добро пожаловать в очередной выпуск подкаста технического коммуникатора Техкомпод! С вами Владимир Юсупов.

В нескольких предыдущих выпусках поднималась тема дальнейшего профессионального пути инженеров, которые работали с проприетарным программным обеспечением, после ухода многих зарубежных вендоров с российского рынка. В частности, в беседе с Владимиром Лагутинским мы обсуждали последствия импортозамещения для консультантов SAP BW, долгие годы использовавших SAP-стек для построение хранилищ данных и аналитических систем. В той беседе Володя отметил один из инструментов, который сейчас является одним из основных в сфере работы с данными. Этот инструмент называется dbt - data build tool. Я с ним также познакомился в рамках задач по импортозамещению. В процессе знакомства выполнил небольшой проект. Руководство по созданию хранилищ данных с помощью dbt размещено в открытом доступе по адресу dwh-book.ru.

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

01:44 - 05:52 Для кого и зачем?

Руководство адресовано, в первую очередь, таким же BI-консультантам и разработчикам хранилищ данных, как и я, которые на протяжении большей части своего профессионального пути взаимодействовали с решением одного вендора. Лично я более 15 лет проработал в основном с продуктами семейства SAP.

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

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

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

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

1. Изучение коммерческих отечественных и альтернативных зарубежных продуктов.
2. Изучение open-source технологий и инструментов.
3. Сочетание первых двух подходов.

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

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

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

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

По сути ресурс dwh-book.ru представляет собой практико-теоретическое руководство по работе с dbt на основе моих конспектов официальной документации и множества заметок из различных источников, которые я находил в процессе изучения этого инструмента. Данный материал ни в коем случае не является заменой документации и учебных курсов, а скорее может быть использован в качестве первого знакомства с dbt и его возможностями.

05:53 - 07:47 Несколько слов о dbt

dbt (data build tool) - это инструмент, который упрощает инженерам и аналитикам работу по преобразованию данных в ходе их интеграции в единое хранилище. Словом, этот инструмент закрывает собою букву «T» в ETL/ELT процессах, то есть он используется для трансформации или преобразования данных.

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

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

Таким образом, data build tool имеет две версии:

• dbt Core - open-source продукт (разработанный на Python), который можно свободно скачать и использовать локально с помощью командной строки под различными операционными системами;
• dbt Cloud - коммерческая версия, которая реализована по модели Software-as-a-Service (SaaS). Включает в себя всю функциональность dbt Core, но не в командной строке, а веб-интерфейсе. Здесь также представлены некоторые дополнительные возможности, которых нет в свободной версии.

В данной руководстве я остановился на dbt Core. Хотя после выполнения проекта очень рекомендую протестировать облачную версию. Ценовая политика dbt Cloud предусматривает тариф «Developer», который, пусть и с некоторыми ограничениями, но все-таки бесплатный. Для продуктивных решений этот вариант вряд ли подойдет, а вот для ознакомления в самый раз. Но это уже другая история.

07:48 - 09:11 Уровень технических знаний и технологическая оснастка

Для освоения dbt необходимы базовые знания SQL (понимание select) и базовые знания работы с командной строкой. Но, честно говоря, это мелочи. Самое главное требование - наличие любознательности и желания открывать новые горизонты при работе с данными.

Для выполнения учебного проекта потребуется следующее программное обеспечение:

• dbt Core – бесплатный инструмент современной аналитики с открытым кодом;
• Python и менеджер пакетов pip;
• PostgreSQL – бесплатная объектно-реляционная система баз данных с открытым исходным кодом;
• pgAdmin – бесплатная платформа администрирования и разработки с открытым исходным кодом для PostgreSQL;
• Git – бесплатная распределенная система контроля версий с открытым исходным кодом для эффективной совместной работы над проектами;
• GitHub – бесплатная онлайн-платформа для хранения, отслеживания и совместной работы над проектами (или локальный Git-сервер в качестве альтернативы). Если используется GitHub, то также потребуется учетная запись этого сервиса;
• IDE - среда ведения разработки. Выбирайте любой подходящий вариант. Я использую VS Code.

Другими словами, стек состоит из open-source инструментов.

09:12 - 10:38 Учебный проект

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

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

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

Стоит отметить, что в данном руководстве приведен лишь один из вариантов реализации витрин. Вы вольны расширить их перечень на основании подготовленных исходных данных.

10:39 - 11:48 Моделирование

Несколько слов о моделировании. Существует несколько вариантов моделирования хранилищ - от популярного нынче DataVault (DV1 и DV2) до одной большой таблицы (OBT), или наоборот.

Годы работы с платформой SAP BW (Business Warehouse) не прошли для меня бесследно (к сожалению или счастью, тут сложно сказать). Так как основной подход моделирования хранилищ данных в SAP BW - модель Кимбалла (многомерная модель или dimensional model), то и учебный проект будет строится именно в этой парадигме с таблицами фактов и измерений.

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

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

• заказчики,
• автомобили,
• календарь (период - год, месяц, день).

11:49 - 12:33 Архитектура проекта

Проект будет представлять собой традиционное хранилище данных с трехуровневой архитектурой:

1. Первичные данные - уровень, который содержит транзакционные данные одного или нескольких источников в неизменном виде.
2. Ядро хранилища – основной уровень, где происходит очистка исходных данных, их преобразование в структуру, удовлетворяющую потребностям бизнеса.
3. Аналитические витрины - уровень представления данных для проведения анализа по определенной бизнес-специфике с помощью отчетности, дашбордов и т.д.

Архитектура dbt-проекта соответствует принципу «слоенного пирога» хранилища данных.

12:34 - 13:04 Слои хранилища (проекта)

Немного ознакомимся со слоями dbt-проекта, которые идут в порядке преобразования данных.

Разработчиками (dbt Labs) рекомендованы следующие слои (папки) dbt-проекта:

• слой первичных данных (staging),
• промежуточный слой (intermediate),
• слой витрин данных (marts).

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

Рассмотрим немного подробнее каждый из слоев.

13:05 - 14:18 Слой первичных данных (staging)

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

Несколько слов о материализации данных.

Поскольку данные staging-слоя не предназначены для запроса конечными потребителями, то эти объекты на этом слое создаются как представления. Такой выбор варианта материализации обусловлен также следующими соображениями:

1. Модели staging-слоя являются фундаментом хранилища. Это значит, что все последующие по потоку данных модели напрямую или косвенно обращаются к моделям первичного слоя. Следовательно, имея источник в виде представлений, модели последующих слоев всегда будут содержать актуальные данные, которые предоставляют системы-источники.
2. Использование staging-моделей в виде представлений позволяет сэкономить место в хранилище на модели, которые не предназначены для запросов потребителей данных.

14:19 - 15:16 Промежуточный слой (intermediate)

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

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

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

15:17 - 16:03 Слой витрин данных (marts)

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

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

Поэтому для материализации на слое витрин применяются следующие типы:

• таблица (table),
• инкрементальная таблица (incremental).

16:04 - 16:50 Правило материализации

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

Вообще разработчики и инженеры-аналитики dbt Labs дают следующие рекомендации по выбору типа материализации:

1. Начинайте выбор типа материализации данных в модели с представления, так как оно практически не занимает места в памяти и всегда дает актуальные результаты.
2. Если модели в виде представления требует слишком много времени на выполнение запроса, используйте таблицы.
3. Когда вы понимаете, что и на таблице запросы выполняются слишком долго, то используйте для таких случаев инкрементные модели.

16:50 - 17:55 Заключение

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

Благодарю, что прослушали этот выпуск.

Напоминаю, что вы всегда можете ознакомиться с текстовой расшифровкой на сайте подкаста.

С вами был Владимир Юсупов. Подкаст технического коммуникатора Техкомпод.

До встречи!

Понравился выпуск? Поделитесь с друзьями и коллегами!

Похожие выпуски