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

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

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

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

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

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

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

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

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

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

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

подсказка

Чтобы помочь вам начать работу, ознакомьтесь с нашим Quickstart with Mesh или пройдите наш онлайн‑курс Mesh course, чтобы узнать больше!

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

  • Сначала вы можете создать группу, чтобы определить владельца набора моделей.
# в 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
    config:
      group: marketing # changed to config in v1.10
  - name: stg_marketing_model
    config:
      group: marketing # changed to config in v1.10
  • После того как вы добавили модели в группу, вы можете добавить настройки access для моделей на основе их связей между группами, выбирая максимально приватный уровень доступа, который при этом сохраняет текущую функциональность. Это означает, что любая модель, которая имеет только связи с другими моделями внутри той же группы, должна быть помечена как private, а любая модель, которая имеет межгрупповые связи или является терминальным узлом в DAG группы, должна быть protected, чтобы другие части DAG могли продолжать на неё ссылаться.
# в models/marketing/__models.yml

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

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

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

# в 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.

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

  • Platform — содержит централизованные staging-модели.
  • Marketing — содержит витрины данных (marts) для маркетинга.
  • Finance — содержит витрины данных (marts) для финансов.

dbt-meshify​

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

Нашли ошибку?

0
Loading