Перейти к основному содержимому

Как мы структурируем наши dbt проекты

Почему структура имеет значение?

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

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

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

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

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

Цели обучения

Это руководство имеет три основные цели:

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

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

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

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

Пример проекта.

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

Мы получим более глубокое понимание нашего проекта по мере продвижения по руководству, но сейчас нам просто нужно знать, что Jaffle Shop — это ресторан, продающий jaffles, у которого есть два основных источника данных:

  • Реплика нашей транзакционной базы данных, называемая jaffle_shop, с основными сущностями, такими как заказы и клиенты.
  • Синхронизированные данные из Stripe, которые мы используем для обработки платежей.

Обзор структуры руководства

Мы пройдем через наши темы в том же порядке, в котором наши данные будут проходить через преобразование:

  1. Изучите, как мы структурируем файлы, папки и модели для наших трех основных слоев в директории models, которые строятся друг на друге:
    1. Стадия — создание наших атомов, наших начальных модульных строительных блоков, из исходных данных
    2. Промежуточный — укладка слоев логики с четкими и конкретными целями для подготовки наших моделей стадии к объединению в сущности, которые мы хотим
    3. Марты — объединение наших модульных частей в широкое, богатое видение сущностей, которые важны для нашей организации
  2. Исследуйте, как эти слои вписываются в остальную часть проекта:
    1. Полностью рассмотрите общую структуру
    2. Подробно расширьте конфигурацию YAML
    3. Обсудите, как использовать другие папки в 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
│ │ └── marketing
│ │ ├── _marketing__models.yml
│ │ └── customers.sql
│ ├── staging
│ │ ├── jaffle_shop
│ │ │ ├── _jaffle_shop__docs.md
│ │ │ ├── _jaffle_shop__models.yml
│ │ │ ├── _jaffle_shop__sources.yml
│ │ │ ├── base
│ │ │ │ ├── base_jaffle_shop__customers.sql
│ │ │ │ └── base_jaffle_shop__deleted_customers.sql
│ │ │ ├── stg_jaffle_shop__customers.sql
│ │ │ └── stg_jaffle_shop__orders.sql
│ │ └── stripe
│ │ ├── _stripe__models.yml
│ │ ├── _stripe__sources.yml
│ │ └── stg_stripe__payments.sql
│ └── utilities
│ └── all_dates.sql
├── packages.yml
├── snapshots
└── tests
└── assert_positive_value_for_total_amount.sql
0