Как мы структурируем наши dbt проекты
Почему структура имеет значение?
Инженерия аналитики в своей основе направлена на то, чтобы помочь группам людей сотрудничать для принятия более обоснованных решений в большом масштабе. У нас есть ограниченная способность принимать решения. Также, как социальный вид, мы полагаемся на системы и шаблоны для оптимизации сотрудничества с другими. Эта комбинация черт означает, что для совместных проектов крайне важно установить последовательные и понятные нормы, чтобы ограниченные ресурсы вашей команды для принятия решений могли быть потрачены на уникальные и сложные проблемы, а не на решение, куда поместить папки или как назвать файлы.
Создание отличного dbt проекта — это по своей сути совместное предприятие, объединяющее знания из каждой области для отображения целей и историй всей компании. Поэтому особенно важно установить глубокий и широкий набор шаблонов, чтобы как можно больше людей могли использовать свои особые знания положительным образом, и чтобы проект оставался доступным и поддерживаемым по мере роста вашей организации.
Известно, что Стив Джобс носил одну и ту же одежду каждый день, чтобы уменьшить усталость от принятия решений. Вы можете рассматривать это руководство аналогично, как черную водолазку и кроссовки New Balance для dbt проекта вашей компании. "Силовой костюм" dbt проекта, или, точнее, его структура, состоит не из ткани, а из файлов, папок, соглашений об именах и программных шаблонов. То, как вы маркируете вещи, группируете их, разделяете или объединяете — это система, которую вы используете для организации преобразований данных, закодированных в вашем dbt проекте — это и есть структура вашего проекта.
Это руководство — лишь отправная точка. Вы можете решить, что предпочитаете Birkenstocks или фиолетовый худи для ваш его проекта вместо минимализма в стиле Джобса. Это нормально. Важно, чтобы вы обдумали причины этих изменений в вашей организации, четко заявили о них в доступной форме для всех участников и, прежде всего, оставались последовательными.
Один из основополагающих принципов, применимых ко всем dbt проектам, заключается в необходимости установить связную дугу, перемещающую данные от источника к бизнесу. Данные, соответствующие источнику, формируются внешними системами, которые мы не контролируем, в то время как данные, соответствующие бизнесу, формируются нашими потребностями, концепциями и определениями. Независимо от того, какие шаблоны или соглашения вы определяете в своем проекте, этот процесс остается основной целью слоя преобразования, и dbt является вашим инструментом в этом процессе. Это руководство является обновлением основополагающего поста по инженерии аналитики с тем же названием от великой Клэр Кэрролл, и хотя некоторые детали изменились со временем (как и ожидалось в этом посте), эта фундаментальная трае ктория остается верной. В дальнейшем это руководство будет итеративно обновляться по мере того, как новые инструменты расширяют наши взгляды, новый опыт оттачивает наше видение, а новые голоса укрепляют наши перспективы, но всегда в служении этой цели.
Цели обучения
Это руководство имеет три основные цели:
- Тщательно охватить наши самые актуальные рекомендации по структуре типичных dbt проектов
- Иллюстрировать эти рекомендации с помощью всесторонних примеров
- На каждом этапе объяснять, почему мы рекомендуем именно такой подход, чтобы вы могли решить, когда и где отклониться от этих рекомендаций, чтобы лучше соответствовать уникальным потребностям вашей организации
Вы должны уйти из этого руководства с более глубоким ментальным представлением о том, как компоненты dbt проекта сочетаются друг с другом, так что цели и принципы инженерии аналитики станут более ясными и интуитивными.
Подходя к нашей структуре намеренно, мы получим лучшее понимание основополагающих идеалов, таких как перемещение наших данных от широкого набора узких моделей, соответствующих источнику, которые предоставляют нам наши системы, к более узкому набору более широких, богатых дизайнов, соответствующих бизнесу, которые мы создаем. По мере того, как мы движемся по этой дуге, мы поймем, как укладка наших преобразований в оптимизированные, модульные слои означает, что мы можем применять каждое преобразование только в одном месте. С дисциплинированным подходом к файлам, папкам и материализациям, которые составляют нашу структуру, мы обнаружим, что можем создавать ясные истории не только через наши данные, но и через наш код и артефакты, которые он генерирует в нашем хранилище.
Мы надеемся, что, углубив ваше понимание связей между этими шаблонами и принципами, из которых они вытекают, вы сможете адаптировать их к вашим конкретным нуждам и создать индивидуальную документацию для вашей команды.
Это руководство проходит через наши рекомендации, используя очень простой dbt проект — аналогичный тому, который используется в руководстве по началу работы и многих других демонстрациях — от вымышленной компании под названием Jaffle Shop. Вы можете прочитать больше о jaffles, если хотите (они действительно существуют), но этот контекст не важен для понимания структуры. Мы призываем вас следовать вместе с нами, пробовать, вносить изменения и делать заметки о том, что работает или не работает для вас по ходу дела.
Мы получим более глубокое понимание нашего проекта п о мере продвижения по руководству, но сейчас нам просто нужно знать, что Jaffle Shop — это ресторан, продающий jaffles, у которого есть два основных источника данных:
- Реплика нашей транзакционной базы данных, называемая
jaffle_shop
, с основными сущностями, такими как заказы и клиенты. - Синхронизированные данные из Stripe, которые мы используем для обработки платежей.
Обзор структуры руководства
Мы пройдем через наши темы в том же порядке, в котором наши данные будут проходить через преобразование:
- Изучите, как мы структурируем файлы, папки и модели для наших трех основных слоев в директории
models
, которые строятся друг на друге:- Стадия — создание наших атомов, наших начальных модульных строительных блоков, из исходных данных
- Промежуточный — укладка слоев логики с четким и и конкретными целями для подготовки наших моделей стадии к объединению в сущности, которые мы хотим
- Марты — объединение наших модульных частей в широкое, богатое видение сущностей, которые важны для нашей организации
- Исследуйте, как эти слои вписываются в остальную часть проекта:
- Полностью рассмотрите общую структуру
- Подробно расширьте конфигурацию YAML
- Обсудите, как использовать другие папки в dbt проекте:
tests
,seeds
иanalyses
Ниже приведено полное дерево файлов проекта, с которым мы будем работать. Не беспокойтесь, если это кажется большим объемом информации для восприятия сразу - это просто чтобы дать вам полное представление о том, к чему мы стремимся. Мы сосредоточимся на каждой из секций по отдельности, разбирая структуру проекта.
jaffle_shop
├── README.md
├── analyses
├── seeds
│ └── employees.csv
├── dbt_project.yml
├── macros
│ └── cents_to_dollars.sql
├── models
│ ├── intermediate
│ │ └── finance
│ │ ├── _int_finance__models.yml
│ │ └── int_payments_pivoted_to_orders.sql
│ ├── marts
│ │ ├── finance
│ │ │ ├── _finance__models.yml
│ │ │ ├── orders.sql
│ │ │ └── payments.sql