Понимание назначения промежуточных, промежуточных и витринных моделей в контексте инструмента построения данных (dbt)
В одной из своих недавних статей я рассказывал о том, как правильно структурировать проекты БДТ и модели данных. Создание новых и обслуживание существующих моделей данных может быть утомительным занятием, если не применяются какие-либо определенные правила и принципы проектирования. В большинстве организаций библиотека моделей данных может быстро расти и, следовательно, может превратиться в хаос, если ею не управлять должным образом.
Как мы обсуждали в моей предыдущей статье, процесс структурирования моделей данных с помощью инструмента построения данных (dbt) включает в себя разделение моделей на три основных уровня, а именно промежуточный, промежуточный и рынки. В следующих нескольких разделах мы подробно рассмотрим каждый из этих уровней и рассмотрим некоторые основные понятия, которые помогут вам их различать. К концу этого мини-учебника вы также должны быть в состоянии сказать, в какой из этих слоев вы должны поместить вновь созданные модели (или, возможно, в какой слой следует вставить рефакторинговую модель).
Постановочные модели
Промежуточный слой содержит все отдельные компоненты вашего проекта, которые будут использоваться другими слоями для создания более сложных моделей данных. Промежуточные модели должны иметь связь 1-к-1 (или сопоставление) с исходными таблицами.
Поэтому важно сохранять их простыми и минимизировать преобразования. Некоторые типы преобразований, которые допустимы в контексте промежуточного уровня, включают приведение типов, переименование столбцов, базовые вычисления (например, преобразование КБ в МБ или ГБ), категоризация (например, с использованием операторов CASE WHEN).
Учитывая, что промежуточные модели соответствуют начальным строительным блокам наших окончательных моделей данных, мы обычно материализуем их в виде представлений. Эта стратегия позволяет любым промежуточным или рыночным моделям, ссылающимся на промежуточный уровень, получать доступ к свежим данным и в то же время экономит место и снижает затраты.
Кроме того, следует избегать объединений, поскольку они могут привести к избыточным или дублированию вычислений. Такие операции предполагается выполнять в последующих слоях.
Наконец, следует также избегать объединений, поскольку такие операции будут группировать наши данные. Целью этого уровня является создание основных строительных блоков для последующих и более сложных моделей данных, поэтому мы не хотим ограничивать себя и потенциально потерять доступ к ценным исходным данным. сильный>.
Промежуточные модели
Промежуточный уровень объединяет атомарные строительные блоки, находящиеся на промежуточном уровне, что позволяет создавать более сложные и содержательные модели. Несмотря на то, что промежуточные модели используются для представления конструкций, которые более значимы для бизнеса, они не должны предоставляться конечным пользователям напрямую через информационные панели или приложения.
Поскольку такие модели не видны конечным пользователям, в большинстве случаев имеет смысл хранить их эфемерно. Эфемерные модели не создаются непосредственно в базе данных/наборе данных, вместо этого их код интерполируется в модели, которые ссылаются на них как на Common Table Expressions. Обратите внимание, однако, что есть случаи, когда имеет смысл материализовать их как представления. Учитывая, что они эфемерны, это означает, что их нельзя выбрать напрямую, и поэтому устранение неполадок становится немного болезненным. Кроме того, макросы, вызываемые через run-operation, не могут ссылаться (например, ref() на эфемерные модели). Так что вам решать, следует ли конкретную промежуточную модель материализовать эфемерно или как представление, но я бы посоветовал начать с эфемерной материализации, если это больше не работает для конкретного варианта использования.
Всякий раз, когда вы решите материализовать их в виде представлений, может быть проще сделать это в пользовательской схеме, то есть схеме вне основной схемы, определенной в вашем профиле dbt.
Теперь, переходя к фактической цели этого типа моделей, если вы все еще не уверены, нужно ли вам создавать промежуточную модель или нет, имейте в виду, что промежуточный слой состоит из моделей, которые будут объединять разные объекты, чтобы впитывать сложность из окончательных моделей витрины. Кроме того, их следует использовать таким образом, чтобы сохранялась и даже облегчалась удобочитаемость и гибкость наших компонентов.
Наконец, хорошее эмпирическое правило заключается в том, как часто вы ссылаетесь на промежуточную модель в других моделях. Если на одну и ту же модель ссылается более чем одна модель, это означает, что наша конструкция, вероятно, пошла не так. Такое явление обычно указывает на то, что нам, возможно, придется рассмотреть возможность превращения нашей промежуточной модели в макрос.
Март Модели
Предполагается, что верхний уровень включает в себя так называемые витринные модели. Другими словами, это место, где все объединяется таким образом, что определенные бизнес-объекты создаются и становятся легко доступными для конечных пользователей через информационные панели или приложения.
Поскольку этот уровень содержит модели, к которым обращаются конечные пользователи, это означает, что производительность имеет значение. Поэтому имеет смысл материализовать их в виде таблиц. Если для создания таблицы требуется слишком много времени (или, возможно, она стоит слишком дорого), вам также может потребоваться настроить ее как инкрементную модель.
Обратите внимание, что модели витрин должны быть относительно простыми, поэтому следует избегать слишком большого количества объединений. Если вы обнаружите такую неточность, то хорошей практикой будет сделать шаг назад и пересмотреть свой дизайн — в большинстве случаев такие недостатки дизайна можно исправить на промежуточном слое.
Последние мысли
Создание хорошо структурированных проектов в dbt чрезвычайно важно, поскольку надежный дизайн поможет вам быстро и, что более важно, расширять и поддерживать вашу библиотеку моделей данных, не сталкиваясь постоянно.
Важным аспектом этого процесса является определение и применение трехуровневого дизайна, который также предлагается в документации dbt, который включает промежуточную, промежуточную и рыночную модели. Подводя итог,
Постановка моделей должна:
- Быть материализованными в виде представлений
- Используйте только базовые преобразования, такие как приведение типов, переименование столбцов, базовые вычисления и категоризация.
- Избегайте объединений и/или агрегаций.
Промежуточные модели должны:
- Быть материализованным эфемерно (или в виде представлений в настраиваемой схеме)
- Не показывать конечным пользователям (через приложения или информационные панели).
- Быть созданным для изоляции сложных операций
- Не ссылаться повторно более чем в одной модели (в этом случае рассмотрите возможность превращения промежуточной модели в макрос)
Маркированные модели должны:
- Быть материализованными в виде таблиц или добавочных моделей моделей.
- Избегайте слишком большого количества объединений в модели с одной витриной
Стать участником и читать все истории на Medium. Ваш членский взнос напрямую поддерживает меня и других писателей, которых вы читаете. Вы также получите полный доступ ко всем историям на Medium.
Статьи по теме, которые вам также могут понравиться
