Для кого предназначен dbt Mesh?

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

Корпоративный data mesh

Некоторые команды по работе с данными функционируют в глобальном масштабе. По определению, такой команде необходимо управлять, развёртывать и распространять data-продукты для большого количества команд. Центральное IT-подразделение может владеть частью data-продуктов или же только платформой, на которой эти data-продукты создаются. Часто в таких организациях есть «архитекторы», которые могут консультировать бизнес-команды по их работе, одновременно отслеживая, что происходит на глобальном уровне (с точки зрения инструментов и содержания работы). Это во многом похоже на то, как устроены крупные софтверные организации после достижения определённого масштаба.

Соотношение численности доменных команд к платформенным в этом сценарии составляет примерно ≥10:1. На каждого участника центральной платформенной команды могут приходиться десятки участников доменно-ориентированных data-команд.

Подходит ли Mesh в таком сценарии? Безусловно! Другого способа масштабно делиться data-продуктами просто нет. Один dbt-проект не сможет удовлетворить глобальные потребности организации такого уровня.

Советы и рекомендации

• Управление общими макросами: Команды, работающие в таком масштабе, выиграют от наличия отдельного репозитория с dbt-пакетом, содержащим переиспользуемые утилитарные макросы, которые будут устанавливаться во все остальные проекты. Это отличается от public models, которые предоставляют data-as-a-service (набор «API-эндпоинтов») — здесь речь идёт о распространении в виде библиотеки. Такой пакет также может стандартизировать подключение других сторонних пакетов, а также предоставлять обёртки / шимы для этих макросов. У этого пакета должна быть выделенная команда мейнтейнеров — вероятно, центральная платформенная команда или группа «суперпользователей» из доменно-ориентированных команд по моделированию данных.

подсказка

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

Сложности внедрения

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

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

Если это похоже на вашу организацию, Mesh — архитектура, к которой вам стоит стремиться. ✅

Hub-and-spoke

Некоторые чуть менее крупные организации всё ещё работают с центральной data-командой, обслуживающей несколько бизнес-ориентированных аналитических команд, при соотношении численности примерно 5:1. Такие центральные команды меньше похожи на классическое IT-подразделение и больше — на современную data-платформенную команду аналитических инженеров. Эта команда предоставляет большую часть data-продуктов остальной организации, а также инфраструктуру, позволяющую downstream-командам запускать собственные spoke-проекты для обеспечения качества и сопровождения ядра платформы.

Подходит ли Mesh в таком сценарии? Почти наверняка! Если ваша центральная data-команда начинает становиться узким местом в работе аналитиков, вам нужен способ позволить этим командам работать относительно независимо, при этом сохраняя качество наиболее используемых data-продуктов. Mesh создан именно для решения этой задачи.

Советы и рекомендации

• Data-продукты, создаваемые некоторыми — для всех: Spoke-команды не должны выпускать public models. Напротив, разработка в проекте hub-команды должна идти медленнее и более осторожно, с фокусом на создании базовых public models, разделяемых между доменами. Мы рекомендуем предоставить участникам hub-команды доступ (как минимум на чтение) к downstream-проектам — это поможет проводить более детальный impact-анализ в Catalog. Если public model не используется ни в одном downstream-проекте или конкретная колонка в этой модели нигде не применяется, hub-команда может с большей уверенностью удалить её. При этом всё равно следует использовать возможности управления в dbt, такие как deprecation_date и version, чтобы корректно задавать ожидания. Если возникает необходимость, чтобы public model из spoke-проекта использовалась в нескольких проектах, сначала стоит подумать, можно ли или нужно ли перенести её в hub-проект.
• Sources: Spoke-командам следует разрешать и поощрять определение и использование доменно-специфичных источников данных. Платформенной команде не обязательно учитывать, например, данные Thinkific при построении базовых витрин данных, но проект Training может в них нуждаться. Ни два источника нигде в dbt mesh не должны указывать на один и тот же relation object. Если spoke-команда считает, что ей нужен источник, который уже использует hub, интерфейсы должны быть изменены так, чтобы spoke могла получать необходимые данные из платформенного проекта.
• Качество проектов: Команды, ориентированные в большей степени на аналитиков, будут иметь разный уровень навыков и разные требования к качеству. Владея своими данными, они владеют и последствиями. Вместо ответственности за сквозную поставку data-активов, hub-команда выполняет роль enablement-команды: её задача — предоставлять защитные рамки и проверки качества, но не исправлять все проблемы строго «под себя» (и тем самым оставаться узким местом).

Сложности внедрения

У этой архитектуры есть компромиссы, особенно для hub-команды, которая управляет и поддерживает public models. В этом рабочем процессе намеренно заложено трение, чтобы снизить вероятность непреднамеренных изменений моделей, нарушающих негласные data-контракты. Эти гарантии могут требовать определённых жертв — например, более быстрого онбординга или более гибких процессов разработки. По сравнению с единым проектом, где разработкой занимается ограниченный круг людей, эта архитектура оптимизирует более медленную разработку с участием более широкого круга участников.

Если это похоже на вашу организацию, с большой вероятностью Mesh вам подойдёт. ✅

Монолит одной команды

Некоторые организации работают в ещё меньшем масштабе. Если ваша data-организация — это одна небольшая команда, которая полностью контролирует процесс создания и сопровождения всех data-продуктов в компании, Mesh может быть не нужен. Сложность проектов обычно возникает из-за большого количества источников данных и стейкхолдеров. Однако при таком размере команды работа с единой кодовой базой может быть самым эффективным способом управления data-продуктами. Как правило, если команда такого размера и охвата задумывается о внедрении Mesh, это связано с желанием улучшить дизайн интерфейсов и/или производительность отдельных частей dbt DAG, а не с необходимостью решать организационную проблему.

Подходит ли Mesh? Возможно! Есть причины разделять большой монолитный проект на несколько, чтобы упростить оркестрацию и управление моделями. Однако если одни и те же люди управляют каждым проектом, они могут прийти к выводу, что накладные расходы на сопровождение нескольких проектов не оправдывают получаемые выгоды.

Если это похоже на вашу организацию, стоит внимательно оценить, подходит ли вам Mesh.

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

Создать GitHub Issue