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

Реализация вашего плана mesh

С чего начать ваше путешествие в мир mesh?​

Переход на dbt Mesh представляет собой значительное изменение в архитектуре разработки и развертывания. Перед любым достаточно сложным рефакторингом или миграцией программного обеспечения важно задать вопрос: «Почему это может не сработать?» Две наиболее распространенные причины, которые мы видели, связаны с

  1. Отсутствием уверенности в том, что dbt Mesh является правильной долгосрочной архитектурой
  2. Отсутствием согласованности в выборе хорошо определенной отправной точки

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

Как найти эти организационные интерфейсы? Вот несколько шагов, чтобы начать:

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

При попытке определить интерфейсы вашего проекта, вы должны рассмотреть возможность исследования:

  • Ваших заданий: Какие наборы моделей чаще всего строятся вместе?
  • Вашего графа родословной: Как связаны модели?
  • Ваших селекторов (определенных в selectors.yml): Как люди уже определяют группы ресурсов?

Давайте рассмотрим пример процесса, в котором монолитный проект используется для определения интерфейсов с помощью групп и доступа, а затем разделяется на несколько проектов.

Чтобы узнать больше, обратитесь к нашему бесплатному курсу по изучению dbt Mesh.

Определение интерфейсов проекта с помощью групп и доступа​

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

  • Сначала вы можете создать группу, чтобы определить владельца набора моделей.
# в models/__groups.yml

groups: 
  - name: marketing
    owner:
        name: Ben Jaffleck 
        email: ben.jaffleck@jaffleshop.com
  • Затем мы можем добавить модели в эту группу, используя ключ group: в YAML-записи модели.
# в models/marketing/__models.yml

models: 
  - name: fct_marketing_model
    group: marketing
  - name: stg_marketing_model
    group: marketing
  • После того как вы добавили модели в группу, вы можете добавить настройки доступа к моделям на основе их связей между группами, выбирая наиболее приватный доступ, который сохранит текущую функциональность. Это означает, что любая модель, имеющая только связи с другими моделями в той же группе, должна быть private, а любая модель, имеющая межгрупповые связи или являющаяся конечным узлом в DAG группы, должна быть protected, чтобы другие части DAG могли продолжать ссылаться на нее.
# в models/marketing/__models.yml

models: 
  - name: fct_marketing_model
    group: marketing
    access: protected
  - name: stg_marketing_model
    group: marketing
    access: private
  • Проверьте эти группы, постепенно мигрируя ваши задания для выполнения этих групп с помощью синтаксиса выбора. Мы рекомендуем делать это параллельно с вашими производственными заданиями, пока вы не будете уверены в них. Это поможет вам понять, правильно ли вы провели границы.
  • Если вы обнаружите, что постоянно вносите изменения в несколько групп при обновлении логики, это знак того, что вам, возможно, стоит пересмотреть ваши группы.

Разделите ваши проекты​

  1. Переместите ваши сгруппированные модели в подпапку. Это будет включать любую модель в выбранной группе, ее соответствующую YAML-запись, а также ее родительские или дочерние ресурсы в зависимости от того, где эта группа находится в вашем DAG.
    1. Обратите внимание, что, как и в вашем проекте dbt, циклические ссылки не допускаются! Проект B не может иметь родителей и детей в проекте A, например.
  2. Создайте новый файл dbt_project.yml в подкаталоге.
  3. Скопируйте любые макросы, используемые ресурсами, которые вы переместили.
  4. Создайте новый файл packages.yml в вашем подкаталоге с пакетами, которые используются ресурсами, которые вы переместили.
  5. Обновите функции {{ ref }} — Для любой модели, имеющей межпроектную зависимость (это может быть в файлах, которые вы переместили, или в файлах, которые остались в вашем проекте):
    1. Обновите функцию {{ ref() }} так, чтобы она имела два аргумента, где первый — это имя исходного проекта, а второй — имя модели: например, {{ ref('jaffle_shop', 'my_upstream_model') }}
    2. Обновите конфигурации access для межпроектных родителей, чтобы они были public, обеспечивая возможность безопасного использования {{ ref() }} этих моделей в любом проекте.
    3. Мы настоятельно рекомендуем добавить контракт модели к моделям верхнего уровня, чтобы гарантировать, что форма данных будет последовательной и надежной для ваших потребителей.
  6. Создайте файл dependencies.yml (документация) для нижестоящего проекта, объявляя верхний проект как зависимость.

# в dependencies.yml
projects:
  - name: jaffle_shop

Лучшие практики​

  • Когда вы подтвердили правильные группы, пришло время разделить ваши проекты.
    • Делайте одну группу за раз!
    • Не рефакторизуйте во время миграции, как бы это ни было заманчиво. Сосредоточьтесь на достижении 1-к-1 соответствия и фиксируйте любые проблемы, которые вы обнаружите в процессе миграции, для последующего решения. После полной миграции проекта вы можете начать его оптимизацию для новой жизни в составе вашего mesh.
  • Начните с разделения вашего проекта в рамках одного репозитория для полного отслеживания git и легкого отката, если вам нужно начать с нуля.

Подключение существующих проектов​

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

  1. Установку родительских проектов как пакетов dbt
  2. Использование функций {{ source() }} для чтения выходных данных родительского проекта в качестве входных данных для дочернего проекта.

Это имеет несколько недостатков:

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

Шаги миграции здесь гораздо проще, чем при разделении монолита!

  1. Если используется метод package:
    1. В родительском проекте:
      1. отметьте все модели, на которые ссылаются нижестоящие проекты, как public и добавьте контракт модели.
    2. В дочернем проекте:
      1. Удалите запись пакета из packages.yml
      2. Добавьте верхний проект в ваш dependencies.yml
      3. Обновите функции {{ ref() }} для моделей из верхнего проекта, чтобы включить аргумент имени проекта.
  2. Если используется метод source:
    1. В родительском проекте:
      1. отметьте все модели, импортируемые нижестоящими проектами, как public и добавьте контракт модели.
    2. В дочернем проекте:
      1. Добавьте верхний проект в ваш dependencies.yml
      2. Замените функции {{ source() }} на межпроектные функции {{ ref() }}.
      3. Удалите ненужные определения source.

Дополнительные ресурсы​

Наши примерные проекты​

Мы предоставили набор примерных проектов, которые вы можете использовать для изучения тем, рассмотренных здесь. Мы разделили наш проект Jaffle Shop на 3 отдельных проекта в многорепозитории dbt Mesh. Обратите внимание, что вам потребуется использовать dbt Cloud для использования многопроектной архитектуры, так как межпроектные ссылки поддерживаются через API dbt Cloud.

  • Platform - содержит наши централизованные модели подготовки.
  • Marketing - содержит наши маркетинговые витрины.
  • Finance - содержит наши финансовые витрины.

dbt-meshify​

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

Связанные документы​

0
Отредактировать эту страницу