Data Mesh на AWS SageMaker Unified Studio: практическое руководство

Каждые несколько месяцев очередной клиент описывает нам свою боль: данные невозможно найти, они не совместимы между системами, изолированы в силосах, и всё превращается в бутылочное горлышко. Или же клиент делится своим видением: доступ ко всем данным компании, управление на уровне команд и безопасные AI-нагрузки, которые используют активы каждого подразделения без нарушения приватности и комплаенса. Они описывают архитектуру, которую представляют, проблемы, с которыми столкнулись, и политику, через которую пробираются. Тогда мы говорим: «То, что вы описываете, укладывается в два слова: Data Mesh. Слыхали?»

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

Data Mesh на AWS SageMaker Unified Studio архитектурно прост. AWS продуктизировал cлой контроля. Успех или провал определяется тем, способна ли ваша организация принять федеративное владение данными без создания бюрократии. В этом руководстве мы разберём, что такое Data Mesh, как SageMaker Unified Studio его реализует, три архитектурных решения, определяющих всё дальнейшее, и организационные паттерны, от которых зависит, выживет ваш mesh в реальности, аль нет.

Что же такое Data Mesh (и почему ваш CDO вероятно о нём не слышал)

Data Mesh: это не технология. Это не конкретный сервис AWS. Это не замена вашего data lake, и уж точно не повод перестраивать оргструктуру за ночь. Это организационная архитектура владения данными: четыре принципа, операционализированных через технологию.

Эти четыре принципа, сформулированные Жамак Дехгани и соответствующие AWS Well-Architected Data Analytics Lens:

1. Доменное владение. Данные принадлежат команде, которая их создаёт, а не централизованной «команде данных», пытающейся управлять дата-активами всех остальных.
2. Данные как продукт. Каждый домен публикует обнаруживаемые, контролируемые по качеству датасеты с определёнными SLA. Представьте внутренний API-контракт, но для данных.
3. Self-serve платформа данных. Инфраструктура, позволяющая доменным командам работать автономно, без тикетов и ожидания реакции от центрального узкого горлышка.
4. Федеративное вычислительное управление. Централизованные стандарты, децентрализованное исполнение. Правила определяются на Олимпе; реализация живёт в командах.

Уинстон Черчилль говорил: «Мы строим наши здания, а затем они строят нас». То же применимо к тому, как компании структурируют свои команды. Если ваша компания группирует людей по технической специализации (единая «команда данных», управляющая всеми данными компании вне зависимости от владения), архитектура отразит эту централизацию. С ростом компании ситуация быстро выходит из-под контроля. Data Mesh инвертирует этот подход.

Аналогия, которая лучше всего воспринимается технической аудиторией: domain-driven development. Вы понимаете идею группировки кода по бизнес-домену: модуль Payments, а не «все Python-скрипты» или «все файлы, связанные со Stripe». Data Mesh применяет тот же принцип к data-активам. Знаменитые two-pizza teams Amazon следуют той же идее: маленькие, автономные, кросс-функциональные, ориентированные на результат группы, которые владеют своим доменом от начала и до конца.

Как архитектура приложений эволюционировала от монолитов к микросервисам, так и data-команды модуляризируют свои платформы в федеративные, децентрализованные решения. AWS Well-Architected Framework Data Analytics Lens явно проводит эту параллель.

Почему опытные CDO это упускают? Потому что концепция требует мышления на другом уровне абстракции. Дело не в новых инструментах, а в том, кто чем владеет и почему. Этот когнитивный сдвиг сложен даже для людей, работающих с данными десятилетиями. Особенно трудно тем data-менеджерам, которые ближе к практической реализации на шкале управление–исполнение.

Как SageMaker Unified Studio позволяет реализовать Data Mesh

AWS SageMaker Unified Studio, доступный для всех с марта 2025 года, это конкретная реализация принципов Data Mesh от AWS. Он базируется на SageMaker Catalog (эволюция Amazon DataZone), Lake Formation, Glue Data Catalog и Athena. Вместе они формируют контрольный слой для федеративной архитектуры данных.

Иерархия: домены, доменные юниты, проекты

Полная структура чётко соответствует организационной реальности:

AWS Account → Domain(s) → Domain Unit(s) → Project(s) → Member(s)

Домен представляет крупное направление бизнеса. Большинству компаний достаточно одного. Исключение: крупные диверсифицированные предприятия, такие как Siemens, где отдельные домены для энергетики, потребительской электроники и транспорта были бы оправданы. Когда мы строили событийно-ориентированный data pipeline для Siemens Energy, кросс-аккаунтная архитектура естественно легла на их дивизионную структуру, и это паттерн, который Data Mesh формализует. Как правило, домены соответствуют крупным направлениям бизнеса компаний, которые занимаются множеством слабо связанных видов деятельности.

Рекомендуемый дизайн: единый governance-домен, который не содержит данных и доменных юнитов, а служит исключительно control plane для mesh. Здесь обеспечивается соблюдение правил и лучших практик. Остальные домены с данными подключаются к участию. У производителей данных есть владельцы даннымх и инженеры данных. У потребителей: data-инженеры, разработчики отчётов и data scientist'ы. По возможности держите governance-аккаунт AWS отдельно от остальных. В противном случае разместите их рядом в одном аккаунте AWS.

Доменные юниты: это организационные подразделения внутри домена: департаменты, команды, функциональные области. Именно здесь сосредоточена основная часть структуры.

Рекомендация: один governance-домен, один корневой бизнес-домен с множеством доменных юнитов, множество проектов в каждом доменном юните. Затем эта структура повторяется в аккаунтах development, UAT и production.

Проекты как единица работы

Проектная команда не постоянна. Это кросс-функциональное пересечение людей из разных физических команд, объединённых для достижения конкретной бизнес-цели. Участники играют роли либо Contributors либо Owners, и они приходят и уходят по мере необходимости проекта.

Именно здесь возражение «вы хотите, чтобы я нанял data-инженера в каждый департамент?» душится в зачатке. Data-инженеры временно присоединяются к конкретному проекту, настраивают необходимую инфраструктуру, затем уходят и возвращяются только когда владеющей команде снова нужна помощь. Те же люди, что и сегодня. Другие уровни абстракции.

Проекты включают ресурсы, необходимые для достижения бизнес-целей: Data Lakehouse для источников данных, ETL-инструменты (скрипты, JupyterLab ноутбуки, оркестрация через Apache Airflow) для обработки и миграции, и MLflow tracking servers для data science работы. Каждый проект выбирает blueprints, которые провижинят эти ресурсы, и мы настоятельно рекомендуем устанавливать все blueprints в режим ONDEMAND, а не ONCREATE (подробнее в разделе о стоимости ниже).

Корпоративный домен использует blueprint Tooling; персональный IAM-домен использует более новый (но менее функциональный) ToolingLite. Различия между ними и когда какой использовать: тема для другой статьи этой серии.

Каталог: паттерн producer/consumer

Data Mesh оживает через паттерн producer/consumer, который напрямую соответствует эталонной архитектуре Well-Architected:

1. Проекты-производители публикуют data-активы в SageMaker Catalog с метаданными, терминами глоссария, информацией о качестве и родословной данных.
2. Проекты-потребители подписываются на эти активы и запрашивают их через Athena изнутри Unified Studio.
3. Lake Formation обеспечивает контроль доступа на уровне партиций, выступая governance-слоем между производителями и потребителями.

Каждый слой (producer, governance, consumer) размещается в собственном аккаунте AWS, согласно рекомендациям Well-Architected. Эта лучшая практика не всегда реализуема. Многие компании, даже крупные, размещают рабочие нагрузки в одном аккаунте AWS вместо изоляции. Наиболее распространённая конвенция: один аккаунт AWS на среду (dev/uat/prd).

Проекты Master Data: наша рекомендация

Мы рекомендуем создавать выделенные проекты вокруг критических источников данных, добавляя «Master Data» к названию: «CRM Master Data», «Website Analytics Master Data». Они питаются источником данных, используемым множеством потребителей через несколько проектов.

Уточнение: любой проект может быть одновременно производителем и потребителем данных. Большинство таковыми и будут. Однако проекты Master Data: это фундаментальные, атомарные листья древа переработки данных. Как правило, они не потребляют данных. Они экспонируют один источник данных в каталог mesh. Well-Architected Framework рекомендует настраивать этих производителей как можно раньше, но реальность более нюансированная. Мы встречали исключения: у одного клиента система управления страховыми полисами и её предшественница были выставлены как отдельные датасеты, плюс агрегированное представление, которое ретрофитило старую схему в новую. Потребители могли запрашивать репозиторий полисов так, будто миграции никогда и не было. Внутренняя механика и исторические бизнес-решения были скрыты, что упрощало интеграцию.

Только владельцы данных (отдел продаж для CRM, маркетинговая команда для аналитики) являются постоянными участниками. Data-инженеры приглашаются временно (для настройки blueprints и подключений) и затем удаляются до следующей необходимости. Эти проекты Master Data экспонируют очищенные датасеты с понятными названиями, глоссариями, метаданными, описаниями, lineage и информацией о качестве. Они, по сути, фундаментальные блоки для всей последующей аналитики, BI и AI-работы.

Три решения, определяющие всё

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

1. Стратегия аккаунтов AWS

Идеал: один аккаунт AWS на workload на среду. Для uni-domain mesh это обычно означает один аккаунт на среду (dev/UAT/prd), с полной репликацией доменной структуры в каждом. Для мульти-доменных предприятий каждый домен (или даже каждый крупный проект) получает свой набор аккаунтов. Принцип: изоляция blast radius и отражение SDLC.

Каждый аккаунт имеет свой корневой домен. Разрабатывайте mesh как приложение: собирайте в dev, продвигайте в UAT, деплойте в production.

Не путайте концепцию environment в AWS (внутри Unified Studio) с средами dev/UAT/prod. Это разные вещи. В каждой среде SDLC полная доменная структура будет реплицирована.

2. Модель идентификации: SSO vs IAM

SSO через AWS Identity Center настоятельно предпочтителен. Он обеспечивает гранулярность на уровне пользователя для governance, трассируемость и детальный контроль доступа к данным. SSO работает там, где IAM недостаточен. Консоль AWS SageMaker Unified Studio будет продолжать предлагать вам настроить SSO, пока вы не сдадитесь.

Альтернатива, IAM с федеративными группами, теряет гранулярность. Наименьшая единица контроля доступа становится группой, что слишком грубый помол для осмысленного data governance. Если ваша компания требует федеративных групп без Identity Center, вы пожертвуете трассируемостью и аудируемостью на уровне пользователя.

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

Мы часто наблюдаем путаницу, когда клиенты смешивают IAM/SSO (доступ к инфраструктуре, кто может войти в AWS-консоль) с Lake Formation (data governance, кто видит какие строки и столбцы в таблицах). Это разные плоскости контроля доступа. Большинство технологов хорошо знают IAM, но не сталкивались с концепциями Lake Formation: доступ на уровне строк, столбцов, RBAC или TBAC. Каждая реализация начинается с ликбеза, разбирающего это различие.

3. Сетевая стратегия: только VPC vs открытая

Домены с VPC-only более безопасны, но значительно увеличивают сложность реализации. Ожидайте настройку VPC service endpoints, модификацию security groups и координацию с IT по сетевым изменениям. В организациях с hub-and-spoke архитектурой на Transit Gateways, где spoke VPC не имеют интернет-трафика, сложность возрастает и подавно.

Если VPC-only требуется (по политике или регуляциям), начинайте с него сразу. Не оставляйте на потом. Ретрофит VPC-only на уже существующий mesh намного сложнее, чем закладка с первого дня.

Для первых развёртываний, где VPC-only не является обязательным, начинайте с открытой позиции по умолчанию, докажите ценность mesh, затем ужесточайте. Но только если это действительно возможно для вашей организации.

Практическая защита от будущих вопросов безопасности: добавить CDK NAG с первого дня. Да, это дополнительная канитель для педантов, но это даёт фору, когда (не «если», а «когда») кто-то спросит: «Это прошло валидацию на соответствие лучшим практикам AWS?»

Операционная модель: где реализации возвращаются со щитом или на щите

Технология составляет около 30% внедрения Data Mesh. Оставшиеся 70%: это организационное управление изменениями, роли, владение и политика того, кто контролирует данные.

Почему доменные команды сопротивляются концепту владения

Самое частое возражение: «Вы хотите, чтобы я нанял data-инженера в каждый департамент?» Менеджеры слышат «федеративное владение» и немедленно представляют запросы на штат для каждой команды.

Переосмысление: проектная команда может быть гибкой, а не постоянной. Data-команда (нынешний «Департамент данных»): это фиксированная группа людей. Проект: временное пересечение подмножеств из разных команд, собранных для бизнес-цели. Data-инженеры уже существуют. Мы не нанимаем новых. Мы группируем тех же людей по-другому в рамках проекта. Если команда постоянно загружает технического специалиста, вы как менеджер обнаружили критическую локальную потребность, и наём выделенного FTE может быть обоснован.

«Закон Конвея» гарантирует, что ваша текущая оргструктура порождает вашу текущую архитектуру. Data Mesh инвертирует это: группировка по бизнес-результату, а не по технической специализации.

Парадокс governance

Центральный governance определяет стандарты: соглашения об именовании, пороги качества, политики хранения и правила классификации. Доменные команды реализуют и поддерживают контракты для собственных data-продуктов.

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

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

Каждый data-продукт нуждается в определённом контракте: схема, правила качества, SLA по свежести данных и именованный владелец. Well-Architected lens указывает, что data-продукты должны быть автономными, обнаруживаемыми, безопасными и переиспользуемыми.

Роль data steward (согласно эталонной архитектуре AWS) обеспечивает федеративное принятие решений и аудируемость метаданных. Без контрактов и стюардства mesh деградирует в распределённый хаос, который хуже, чем централизованный lake, который он заменил.

Получение поддержки

Внедрение: это в равной мере политика и инженерия. Начните с одного проекта Master Data producer. Докажите, что контролируемый доступ работает: отдел продаж видит свои CRM-данные, маркетинговая команда может запрашивать аналитику сайта, и ни один из них не может получить доступ к таблицам другого, причём с гранулярным, попроектным контролем.

Аргумент Marie Kondo: прежде чем запускать AI-нагрузки масштаба компании, необходим гранулярный, контекстно-специфичный доступ к хорошо управляемым данным. Data Mesh не роскошь параллельно с вашей AI-дорожной картой. Это предпосылка, которая делает AI возможным.

Сколько это стоит (и что застаёт врасплох)

Инфраструктура mesh сама по себе дешёвая. Неожиданные расходы появляются от blueprints, которые вы активируете, не понимая, какие ресурсы они провижинят.

Ловушка стоимости blueprints

Настройка SageMaker Unified Studio не несёт per-domain стоимости. Lake Formation, Glue Catalog и управление проектами по сути бесплатны на малых масштабах. Счёт приходит от вычислительных ресурсов, которые провижинят blueprints. (Актуальные тарифы: на странице ценообразования SageMaker.)

Самый дорогой сюрприз: MLFlow tracking server. Активируется blueprint'ом, ориентированным на ML, и стоит несколько тысяч долларов в месяц даже для минимального compute-варианта, даже если им никто не пользуется. (Примечание: AWS анонсировал serverless вариант MLflow в конце 2025 года без дополнительной платы, но managed tracking server, провижиненный старыми blueprints, по-прежнему несёт эти расходы.)

Code spaces (удалённые вычислительные среды JupyterLab и VS Code, в которых вы пишете скрипты) доступны, но не бесплатны. Инстанс t3.medium стоит примерно $0,60 за 10 часов использования, и минимальный таймаут простоя перед автоматическим выключением: 1 час.

GP3-хранилище обходится примерно в $2 за 15 ГБ в месяц. Пренебрежимо мало.

Паттерн: Инфраструктура (домены, проекты, каталог) = по сути бесплатно. Compute (endpoints, tracking servers, code spaces) = где растёт счёт. Governance (Lake Formation, разрешения) = бесплатно. Хранилище = дёшево.

Наша рекомендация: если вы заранее не знаете, какая функциональность потребуется проекту, можно создать профиль проекта «All Capabilities» (свой, а не Амазоновский) со всеми добавленными blueprints и установить их все в ONDEMAND, не ONCREATE. Если вы не знаете, что провижинит blueprint, не активируйте его. Наши следующие статьи этой серии объяснят каждый blueprint и что он создаёт.

Как мы помогаем с расходами

Как AWS-партнёр, мы помогаем клиентам получить доступ к ценовым преимуществам помимо стандартной оптимизации compute, экономия, недоступная при работе с AWS напрямую. Все клиенты получают DoIt PartnerOps, кросс-облачную FinOps- и compliance-платформу, без дополнительной платы. Она обеспечивает прозрачность того, какие именно ресурсы, провижиненные blueprints, генерируют расходы. Мы видели клиентов, которые экономили сумму, эквивалентную нашему консалтинговому гонорару, только за счёт инструментов оптимизации затрат.

Прагматичный путь: начните с малого, докажите ценность

Не всё разом. Выберите один критический источник данных, один доменный юнит, одного потребителя, и докажите, что паттерн работает, прежде чем просить кого-то ещё что-то менять.

Шаг 1: Определите ваш самый запрашиваемый датасет, тот, который каждый проект сейчас получает через Slack DM, общие диски или ручной экспорт. Альтернативно, выберите болевую точку: «Мы переплачиваем за эту существующую SAS-платформу и должны мигрировать на современную архитектуру».

Шаг 2: Создайте проект Master Data producer, назначьте data owner'а и настройте доступ Lake Formation через SageMaker Unified Studio, а не напрямую в консоли Lake Formation.

Шаг 3: Опубликуйте в SageMaker Catalog с метаданными, терминами глоссария и правилами качества.

Шаг 4: Подключите один проект-потребитель. Докажите, что они могут обнаружить данные и запросить их без обращения к кому-либо. Подключите AWS QuickSight, чтобы бизнес-стейкхолдеры могли общаться с BI-дашбордом через чат. Реакция обычно мгновенная.

Шаг 5: Отпразднуйте победу. Затем переходите к следующему датасету. При правильном подходе каждое успешное подключение создаёт минимум одного внутреннего евангелиста, человека, который увидел, что это работает, и рассказывает коллегам. Эти евангелисты критически важны. Консультанты не пользуются тем же уровнем доверия. Товарищи по цеху распространяют философию Data Mesh намного эффективнее любого мандата свыше.

Именно это рекомендует Well-Architected lens: быстрые циклы поставки с итерацией на основе полученного опыта. Альтернатива (big-bang rollout mesh, требующий одновременных изменений от всех) умирает в управленческих комитетах.

Для команд, которые хотят автоматизировать этот процесс с помощью Infrastructure as Code: мы поддерживаем опинионированную open-source библиотеку L2-конструктов для SageMaker Unified Studio, управляемую через projen. Она провижинит домены, доменные юниты, проекты и blueprints в одном CDK-деплое. Мы опубликуем в NPM и PyPI, когда библиотека стабилизируется, следите за нашим GitHub.

Несколько практических замечаний для команд, выбирающих IaC-путь: по мере роста mesh вы столкнётесь с лимитом CloudFormation в 500 ресурсов на стек. Наш подход: отдельный CDK stage для ресурсов Data Mesh, один стек на домен, вложенные стеки для проектов. Это даёт пространство для масштабирования без рефакторинга всего деплоя.

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

AWS также предоставляет полезные отправные точки: CI/CD CLI для SageMaker Unified Studio и официальный репозиторий утилит с шаблонами CloudFormation для типовых паттернов.

Заключение

Data Mesh на SageMaker Unified Studio архитектурно прост. AWS продуктизировал control plane: домены, проекты, каталог и разрешения Lake Formation. Технология работает. Успех или провал вашей реализации определяется тем, способна ли ваша организация принять федеративное владение, не порождая больше бюрократии, чем устраняет.

Ключевой инсайт не изменился: невозможно запускать безопасные AI-нагрузки масштаба компании без гранулярного, контекстно-специфичного доступа к управляемым данным. Пирамида AI-потребностей тут как тут: чистые, управляемые, доступные данные, это фундамент, на котором строится всё остальное. Data Mesh не побочный проект параллельно с вашей AI-дорожной картой. Это то, что делает корпоративный AI возможным.

Если это описывает вашу задачу (видение доступа ко всем данным компании без чёткого пути от текущего состояния к целевому), именно с этим мы и помогаем. Как AWS-партнёр, мы привносим сертификации, ценовые преимущества и практический опыт. Жахнем!

Malik AlimoekhamedovEngineer, techno-optimist, entrepreneur, writer, musician, investor and minimalist. I strive to automate as much of my life as possible. Writing helps me crystallise and manage thoughts. Technology is my bread and butter, as well as a passion. You can safely reach out any time.