Как гибридная Mesh разблокирует масштабное сотрудничество в dbt

Одной из самых важных функций dbt является возможность для команд сотрудничать в создании и распространении организационных знаний.

Ранее это выглядело как работа команды в одном проекте dbt для создания набора преобразованных объектов в их платформе данных.

Когда dbt был принят более крупными организациями и начал управлять рабочими нагрузками в глобальном масштабе, стало ясно, что нам нужны механизмы, позволяющие командам работать независимо друг от друга, создавая и делясь моделями данных между командами — dbt Mesh.

dbt Mesh мощен, потому что позволяет командам работать независимо и совместно, каждая команда свободна строить свои собственные модели, но при этом вносит вклад в более крупный, общий набор данных.

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

Как гибридная Mesh обеспечивает сотрудничество между командами dbt Core и dbt Cloud

Сценарий — Компания с центральной командой данных использует dbt Core. Эта настройка хорошо работает для этой команды. Они хотят расширить свое влияние, чтобы ускорить принятие решений по всей организации. Текущая настройка dbt Core не подходит для вовлечения большего числа менее технических, нетехнических или менее частых участников.

Цель — Позволить трем доменным командам менее технических пользователей использовать и расширять центральные модели данных, полностью владея своими доменно-специфичными моделями dbt.

• Центральная команда данных: Инженеры данных, комфортно работающие с dbt Core и интерфейсом командной строки (CLI), создающие и поддерживающие основные модели данных для всей организации.

• Доменные команды: Аналитики данных, комфортно работающие с SQL, но не использующие CLI и предпочитающие сразу приступить к работе без управления локальными установками или обновлениями dbt Core. Команда должна строить преобразования, специфичные для их бизнес-контекста. Некоторые из этих пользователей могли пробовать dbt в прошлом, но не смогли успешно адаптироваться к настройке центральной команды.

Решение: Гибридная Mesh — Команды данных могут использовать dbt Mesh для соединения проектов между dbt Core и dbt Cloud, создавая рабочий процесс, в котором каждый работает в предпочитаемой среде, создавая общую линию, которая позволяет видеть, проверять и владеть данными по всему конвейеру данных.

Каждая команда будет полностью владеть своим кодом dbt, от разработки до развертывания, используя продукт, соответствующий их потребностям и возможностям, при этом делясь продуктами данных между командами, использующими как dbt Core, так и dbt Cloud.

Диаграмма до и после, подчеркивающая, как гибридная Mesh позволяет центральным командам данных, использующим dbt Core, работать с доменными командами данных, использующими dbt Cloud.

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

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

Как построить гибридную Mesh

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

Шаг 1: Подготовьте ваш проект Core для доступа через dbt Mesh

Настройте публичные модели, чтобы они служили стабильными интерфейсами для нижестоящих проектов dbt.

• Определите, какие модели из вашего проекта Core будут доступны в вашем Mesh. Подробнее о том, как настроить публичный доступ для этих моделей, см. на странице model access page.
• При необходимости настройте model contract для всех публичных моделей, чтобы улучшить управление и контроль.
• Храните проекты dbt Core и dbt Cloud в отдельных репозиториях, чтобы обеспечить чёткое разделение между upstream‑моделями, которыми управляет команда dbt Core, и downstream‑моделями, за которые отвечает команда dbt Cloud.

Шаг 2: Отразите каждый "производящий" проект Core в dbt Cloud

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

• Создайте аккаунт в dbt Cloud и проект dbt для каждого upstream‑проекта на dbt Core.
  • Примечание: если в вашем проекте используются environment variables, то переменные окружения в dbt Cloud должны иметь префикс DBT_ (включая DBT_ENV_CUSTOM_ENV_ или DBT_ENV_SECRET). Следуйте инструкциям из этого руководства, чтобы корректно преобразовать их для dbt Cloud.
• Для каждого upstream‑проекта на dbt Core в dbt Cloud должна существовать production‑environment. Вам необходимо настроить учетные данные и переменные окружения в dbt Cloud так, чтобы разрешение имен relations происходило в тех же местах, куда ваши dbt Core workflows деплоят модели.
• Настройте merge job в production‑environment для запуска dbt parse. Это позволит подключать downstream‑проекты в dbt Mesh за счет генерации необходимых artifacts для кросс‑проектных ссылок.
  • Опционально: вместо merge job для dbt parse можно настроить обычную job с запуском dbt build и централизовать оркестрацию dbt, перенеся production‑запуски в dbt Cloud. Подробнее о переносе production‑запусков в dbt Cloud см. в этом руководстве.
• Опционально: настройте регулярную job (например, ежедневную) для запуска source freshness и docs generate. Это наполнит dbt Cloud дополнительными метаданными и включит возможности в dbt Explorer, которые будут полезны обеим командам, включая column‑level lineage.

Шаг 3: Создайте downstream‑проекты и подключите их к вашему Core‑проекту с помощью dbt Mesh

Теперь, когда dbt Cloud располагает всей необходимой информацией о вашем Core‑проекте, вы можете приступить к настройке downstream‑проектов, которые будут строиться поверх public‑моделей проекта, перенесенного в Cloud на шаге 2. Для этого:

• Инициализируйте каждый новый downstream‑проект в dbt Cloud и создайте файл dependencies.yml.

• В файле dependencies.yml укажите имя dbt‑проекта из dbt_project.yml upstream‑проекта (или проектов). Это настраивает кросс‑проектные ссылки между различными dbt‑проектами:

  # файл dependencies.yml в нижестоящем проекте dbt Cloud
  projects:
  - name: upstream_project_name

• Используйте перекрестные ссылки для публичных моделей в верхнем проекте. Добавьте версию к ссылкам на версионные модели:

  select * from {{ ref('upstream_project_name', 'monthly_revenue') }}

И на этом всё! Теперь доменные команды, которые владеют каждым dbt Project, могут развивать свои модели в соответствии со своими собственными сценариями использования. Вы можете выстраивать свой Hybrid Mesh так, как вам удобно, используя весь набор возможностей dbt Cloud.

• Оркестрируйте свой Mesh, чтобы обеспечить своевременную доставку дата‑продуктов и сделать их доступными для downstream‑потребителей.
• Используйте dbt Explorer, чтобы прослеживать lineage ваших данных вплоть до источника.
• Подключайте новые команды и интегрируйте их в свой Mesh.
• Создавайте semantic models и metrics в своих проектах, чтобы затем запрашивать их через dbt Semantic Layer.

Заключение

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