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

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

Корпоративная сетка данных

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

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

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

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

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

Проблемы внедрения

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

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

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

Центр и спицы

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

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

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

• Продукты данных от некоторых, для всех: Команды спиц не должны создавать публичные модели. Напротив, разработка в проекте команды центра должна быть более медленной, более тщательной и сосредоточенной на создании фундаментальных публичных моделей, которые будут использоваться в разных доменах. Мы рекомендуем предоставить членам команды центра доступ (по крайней мере, только для чтения) к проектам спиц, что поможет с более детальным анализом воздействия в dbt Explorer. Если публичная модель не используется в каком-либо проекте спиц или конкретный столбец в этой модели, команда центра может быть более уверена в ее удалении. Однако они все равно должны использовать функции управления dbt, такие как deprecation_date и version, чтобы установить ожидания. Если в проекте спиц возникает необходимость в публичной модели, которая должна быть использована в нескольких проектах, сначала подумайте, можно ли или следует ли ее перенести в проект центра.
• Источники: Спицам следует разрешить/поощрять определение и использование домен-специфичных источников данных. Команда платформы не должна беспокоиться, скажем, о данных Thinkific при создании основных хранилищ данных, но проект Обучения может нуждаться в этом. Ни один источник в dbt mesh не должен указывать на один и тот же объект отношения. Если спица считает, что ей нужно использовать источник, который уже использует центр, интерфейсы должны измениться, чтобы спица могла получить то, что ей нужно, из проекта платформы.
• Качество проекта: Команды, ориентированные на аналитиков, будут иметь разные уровни навыков и качества. Владение своими данными означает, что они также несут ответственность за последствия. Вместо того чтобы нести ответственность за доставку данных от начала до конца, команда центра является командой поддержки: их роль заключается в предоставлении ограничений и проверок качества, но не в исправлении всех проблем в точности по своему усмотрению (и тем самым оставаться узким местом).

Проблемы внедрения

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

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

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

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

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

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