Раз на кілька місяців клієнт ділиться своїми проблемами щодо даних, які неможливо знайти, які не сумісні між собою та ізольовані в різних системах, і як усе це стає вузьким місцем, або описує своє бачення доступу до даних на рівні всієї компанії. Вони хочуть управління на рівні команд і безпечні AI-навантаження, які використовують ресурси кожного відділу без порушення конфіденційності чи відповідності вимогам. Вони пояснюють архітектуру, яку уявляють, проблеми, з якими стикаються, та політичні аспекти, які доводиться враховувати. Тоді ми говоримо: "Те, що ви описуєте, — це два слова: Data Mesh. Чули про це?"
У дев'яти випадках із десяти відповідь — ні. Це патерн, який ми впроваджуємо найчастіше для наших клієнтів, але ті, хто потребує його найбільше, рідко чули цей термін. Цей посібник — для них і для всіх, хто підозрює, що проблема з даними в їхній організації — це прогалина у відповідальності, а не в технологіях.
Data mesh на AWS SageMaker Unified Studio є архітектурно простим. AWS перетворила площину управління на готовий продукт. Успіх чи невдача залежать від того, чи зможе ваша організація впровадити федеративне володіння даними без створення бюрократії. Цей посібник охоплює значення data mesh, як SageMaker Unified Studio реалізує цей підхід, три архітектурні рішення, що визначають усе подальше, та організаційні патерни, що визначають, чи витримає ваш mesh зіткнення з реальністю.
Що насправді означає data mesh (і чому ваш CDO, ймовірно, про це не чув)
Data mesh — це не технологія. Це не конкретний сервіс AWS. Це не заміна вашого data lake і точно не привід для перебудови організаційної структури за одну ніч. Це організаційна архітектура володіння даними: чотири принципи, реалізовані через технології.
Ці чотири принципи, визначені Zhamak Dehghani та відповідні до AWS Well-Architected Data Analytics Lens:
- Доменно-орієнтоване володіння. Дані належать команді, яка їх створює, а не централізованій команді "Data", що намагається керувати ресурсами всіх.
- Дані як продукт. Кожен домен публікує доступні для пошуку набори даних з контролем якості та визначеними SLA. Уявіть це як внутрішній API-контракт, але для даних.
- Самообслуговувана платформа даних. Інфраструктура, яка дає змогу доменним командам працювати автономно, без подання заявок чи очікування на централізоване вузьке місце.
- Федеративне обчислювальне управління. Централізовані стандарти, децентралізоване виконання. Правила встановлюються зверху; реалізація залишається за командами.
Winston Churchill сказав: "Ми формуємо наші будівлі, а потім вони формують нас." Те ж саме стосується й того, як компанії структурують свої команди. Якщо ваша компанія групує людей за технічною спеціалізацією (команда "Data" обслуговує всі дані компанії незалежно від належності), ваша архітектура відображатиме цю централізацію. З ростом компанії ситуація швидко виходить з-під контролю. Data mesh перевертає цей підхід.
Аналогія, яка найбільше резонує з технічною аудиторією, — це доменно-орієнтована розробка. Ви розумієте групування коду за бізнес-доменом: модуль Payments, а не "всі Python-скрипти" чи "всі файли, пов'язані зі Stripe." Data mesh застосовує той самий принцип до даних. Відомі "команди двох піц" Amazon слідують тій самій ідеї: невеликі, автономні, крос-функціональні, орієнтовані на результат групи, що повністю володіють своїм доменом.
Так само, як архітектура застосунків еволюціонувала від монолітів до мікросервісів, команди з даних модуляризують свої платформи у федеративні, децентралізовані рішення. AWS Well-Architected Framework Data Analytics Lens явно проводить цю паралель.
Чому досвідчені CDO це пропускають? Тому що ця концепція вимагає мислення на іншому рівні абстракції. Йдеться не про нові інструменти, а про те, хто чим володіє і чому. Ця когнітивна зміна складна навіть для людей, які працювали з даними десятиліттями. Особливо важко це дається менеджерам з даних, які ближче до практичної реалізації на спектрі управління-виконання.
Як 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 → Домен(и) → Доменна одиниця(і) → Проєкт(и) → Учасник(и)
Один домен представляє основний напрямок бізнесу. Більшості компаній потрібен лише один. Винятками є великі диверсифіковані підприємства, такі як Siemens, де окремі домени для енергетики, споживчої електроніки та транспорту мали б сенс. Коли ми будували подієво-орієнтований конвеєр даних для Siemens Energy, міжоблікова архітектура природно відповідала їхній дивізіональній структурі — патерн, який data mesh формалізує. Як правило, домени відповідають основним напрямкам бізнесу компаній, що мають безліч слабко пов'язаних видів діяльності.
Рекомендований дизайн — єдиний домен управління, який не містить даних чи доменних одиниць і слугує лише площиною управління mesh. Тут застосовуються правила та найкращі практики. Інші домени, насичені даними, підключаються для участі. Продюсери даних мають власників даних та інженерів. Споживачі даних мають дата-інженерів, розробників звітів та data scientists. За можливості тримайте обліковий запис AWS для управління окремо від інших. В іншому випадку розміщуйте їх поруч в одному обліковому записі AWS.
Доменні одиниці — це організаційні підрозділи в межах домену, такі як департаменти, команди та функціональні можливості. Тут зосереджена більша частина структури.
Правило: один домен управління, один кореневий бізнес-домен із багатьма доменними одиницями, багато проєктів на доменну одиницю. Потім ця структура повторюється в середовищах розробки, UAT та продакшну.
Проєкти як одиниця роботи
Проєктна команда — це не постійна команда. Це крос-функціональний перетин людей з різних фізичних команд, згрупованих для конкретної бізнес-мети. Учасники є або Contributors, або Owners, і вони приходять та йдуть відповідно до потреб проєкту.
Саме тут зникає заперечення "ви хочете, щоб я найняв дата-інженера для кожного відділу?". Дата-інженери тимчасово приєднуються до конкретного проєкту, налаштовують необхідні механізми, потім йдуть і повертаються, коли команді-власнику потрібна допомога. Ті ж самі люди, що й сьогодні. Інші рівні абстракції.
Проєкти включають ресурси, необхідні для досягнення бізнес-цілей: Data Lakehouse для джерел даних, ETL-інструменти (скрипти, ноутбуки, оркестрація Airflow) для обробки та міграції, а також MLflow tracking servers для роботи з data science. Кожен проєкт обирає блюпринти, що забезпечують ці ресурси, і ми наполегливо рекомендуємо встановити всі блюпринти в ONDEMAND замість ONCREATE (див. розділ про витрати нижче для детальнішої інформації).
Корпоративний домен використовує блюпринт Tooling; персональний IAM-домен використовує новіший (але менш функціональний) ToolingLite. Відмінності між ними та коли який використовувати — тема для іншої публікації в цій серії.
Каталог: патерн продюсер/споживач
Data mesh оживає завдяки патерну продюсер/споживач, який безпосередньо відповідає еталонній архітектурі Well-Architected:
- Проєкти-продюсери публікують дані в SageMaker Catalog із повними метаданими, термінами глосарію, інформацією про якість та лінійністю.
- Проєкти-споживачі підписуються на ці ресурси та запитують їх через Athena безпосередньо з Unified Studio.
- Lake Formation забезпечує контроль доступу на рівні партицій, виступаючи рівнем управління між продюсерами та споживачами.
Кожен рівень (продюсер, управління, споживач) розміщується у власному обліковому записі 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, маркетингова команда для своєї аналітики) є постійними учасниками. Дата-інженери запрошуються тимчасово для налаштування блюпринтів та підключень, а потім видаляються до наступної потреби. Ці проєкти Master Data відкривають очищені набори даних зі зрозумілими назвами, глосаріями, метаданими, описами, лінійністю та інформацією про якість. Вони є основними блоками для всієї подальшої аналітики, BI та AI-роботи.
Три рішення, що визначають усе
Перед написанням інфраструктурного коду три рішення визначають складність вашої реалізації, деталізацію управління та щомісячний рахунок.
Рішення | Варіант A | Варіант B | Наша рекомендація | Причина |
|---|---|---|---|---|
Стратегія облікових записів AWS | Один обліковий запис на середовище (dev/UAT/prod) з усіма доменами та проєктами | Один обліковий запис на домен (якщо кілька доменів) або проєкт (якщо один домен) | Один на домен/проєкт з (dev/uat/prd для кожного) | Відображає SDLC, дотримується найкращих практик одного облікового запису AWS на комбінацію навантаження + середовище. |
Модель ідентифікації | SSO через AWS Identity Center | IAM | SSO | Деталізація на рівні користувача, відстежуваність, тонке управління Lake Formation, рекомендоване AWS. |
Мережева конфігурація | Без VPC (за замовчуванням) | Тільки VPC | Починайте з відкритого доступу, якщо політика не вимагає іншого | Тільки VPC додає значну складність; спочатку доведіть цінність, потім посилюйте обмеження. |
1. Стратегія облікових записів AWS
Ідеал — один обліковий запис AWS на навантаження на середовище. Для mono-доменного mesh це зазвичай означає один обліковий запис на середовище (dev/UAT/prd) з повною доменною структурою, реплікованою в кожному. Для підприємств із кількома доменами кожен домен (або навіть кожен великий проєкт) отримує власний набір облікових записів. Принцип: ізолюйте зону ураження та відображайте свій SDLC.
Кожен обліковий запис має власний кореневий домен. Розробляйте mesh як застосунок: збирайте в dev, просувайте до UAT, розгортайте у продакшн.
Не плутайте концепцію середовища AWS (в межах Unified Studio) із середовищами dev/UAT/prod. Це різні речі. Кожне середовище SDLC матиме повну реплікацію доменної структури.
2. Модель ідентифікації: SSO проти IAM
SSO через AWS Identity Center є переважним. Він забезпечує деталізацію на рівні користувача для управління, відстежуваності та тонкого контролю доступу до даних. SSO працює там, де IAM не справляється. Консоль AWS SageMaker Unified Studio продовжуватиме пропонувати вам налаштувати SSO, поки ви цього не зробите.
Альтернатива — IAM із федеративними групами, втрачає деталізацію. Найменшою одиницею контролю доступу стає група, що є занадто грубим для ефективного управління даними. Якщо ваша компанія вимагає федеративних груп без Identity Center, ви пожертвуєте відстежуваністю та аудитом на рівні користувача.
Ось політична реальність: SSO часто є однією з найважчих речей, на які можна отримати підтримку клієнтів. Їхні руки зв'язані тими, хто вище в ланцюгу командування. IAM-домени працюють, якщо IAM-користувачі дозволені, але це часто не гарантовано.
Ми часто бачимо плутанину, коли клієнти ототожнюють IAM/SSO (доступ до інфраструктури, хто може входити в консоль AWS) з Lake Formation (управління даними, хто може бачити які рядки та колонки в таблицях). Це окремі площини контролю доступу. Більшість технологів добре знають IAM, але не стикалися з концепціями Lake Formation, такими як доступ на рівні рядків, доступ на рівні колонок, рольовий контроль доступу (RBAC) або контроль доступу на основі тегів (TBAC). Кожне впровадження починається з сесії біля дошки, де ми розбираємо цю різницю.
3. Мережева конфігурація: тільки VPC проти відкритого доступу
Домени тільки з VPC є більш захищеними, але значно збільшують складність реалізації. Очікуйте налаштування VPC service endpoints, зміни security groups та координацію з IT для мережевих змін. В організаціях, що використовують архітектуру hub-and-spoke з Transit Gateways, де spoke VPC не мають інтернет-трафіку, складність зростає ще більше.
Якщо тільки VPC є обов'язковим (за політикою чи регуляцією), починайте з нього від самого початку. Не залишайте це на потім. Додавання обмеження тільки VPC до існуючого mesh набагато складніше, ніж вбудовування його з першого дня.
Для перших розгортань, де тільки VPC не є обов'язковим, починайте з відкритої конфігурації за замовчуванням, доведіть цінність mesh, потім посилюйте обмеження. Але лише якщо це дійсно є варіантом для вашої організації.
Практичний захист від майбутніх перевірок безпеки — додати CDK NAG з першого дня. Додаткове навантаження реальне, але забезпечує перевагу, коли (не якщо) хтось запитає: "Чи було це перевірено на відповідність найкращим практикам AWS?"
Операційна модель: де впровадження досягають успіху чи зазнають невдачі
Технологія становить близько 30% впровадження data mesh. Решта 70% — це управління організаційними змінами: ролі, відповідальність та політика щодо того, хто контролює дані.
Чому доменні команди чинять опір відповідальності
Найпоширеніше заперечення: "Ви хочете, щоб я найняв дата-інженера для кожного відділу?" Менеджери чують "федеративне володіння" і одразу уявляють запити на збільшення штату для кожної команди.
Переформулювання: проєктна команда може бути гнучкою, а не постійною. Команда даних (поточний "Data Department") — це фіксована група людей. Проєкт — це тимчасовий перетин підмножин з різних команд, зібраних для бізнес-мети. Дата-інженери вже є. Ми не наймаємо нових. Ми групуємо тих самих людей по-різному для кожного проєкту. Якщо команда постійно завантажує технічного спеціаліста, як менеджер ви виявили критичну локальну потребу, і наймання виділеного штатного працівника (FTE) може бути гарною ідеєю.
Закон Конвея гарантує, що ваша поточна організаційна структура породжує вашу поточну архітектуру. Data mesh перевертає це: групування за бізнес-результатом, а не за технічною спеціалізацією.
Парадокс управління
Центральне управління визначає стандарти: конвенції іменування, порогові значення якості, політики зберігання та правила класифікації. Доменні команди впроваджують і підтримують контракти для своїх власних продуктів даних.
Найскладніша частина — не технологія. Це змусити стейкхолдерів, які параноїдально ставляться до доступу до даних, дійти згоди щодо значення "спільного доступу". Допомогти їм зрозуміти, що це не "все або нічого". Парадокс безпеки з'являється знову: чим менш зріле управління в організації, тим вищу планку вони встановлюють для нової системи.
Контракти даних та відповідальність
Кожен продукт даних потребує визначеного контракту: схема, правила якості, SLA свіжості та названий власник. Well-Architected lens зазначає, що продукти даних повинні бути автономними, доступними для пошуку, захищеними та придатними для повторного використання.
Роль data steward (згідно з еталонною архітектурою AWS) забезпечує федеративне прийняття рішень та аудит метаданих. Без контрактів та стюардства mesh деградує в розподілений хаос, гірший за централізоване озеро даних, яке він замінив.
Отримання підтримки
Впровадження — це настільки ж політика, наскільки й інженерія. Починайте з одного проєкту-продюсера Master Data. Доведіть, що контрольований доступ працює: команда продажів може бачити свої дані CRM, маркетингова команда може запитувати аналітику вебсайту, і жодна з них не може отримати доступ до таблиць іншої з детальним контролем на рівні проєкту.
Аргумент "Marie Kondo": перш ніж запускати AI-навантаження в масштабах компанії, вам потрібен детальний, контекстно-специфічний доступ до добре керованих даних. Data mesh — це не розкіш поряд із вашою AI-дорожньою картою. Це передумова, яка робить AI можливим.
Скільки це коштує (і що застає зненацька)
Інфраструктура mesh сама по собі дешева. Несподівані витрати виникають через блюпринти, які ви активуєте, не розуміючи, які ресурси вони створюють.
Пастка вартості блюпринтів
Налаштування SageMaker Unified Studio не має вартості за домен. Lake Formation, Glue Catalog та управління проєктами по суті безкоштовні в малому масштабі. Рахунок формується з обчислювальних ресурсів, які створюють блюпринти. (Див. тарифи SageMaker для актуальних цін.)
Найдорожчий сюрприз: MLFlow tracking server. Активований ML-орієнтованим блюпринтом, він обходиться в кілька тисяч на місяць навіть для найменшого обчислювального варіанту, навіть коли ніхто ним не користується. Ми бачили клієнтів, які виявляли це через тижні після активації, дивуючись, звідки такий рахунок. (Примітка: AWS анонсувала безсерверний варіант MLflow наприкінці 2025 року без додаткової плати, але керований tracking server, створений старішими блюпринтами, все ще має цю вартість.)
Code spaces (віддалені обчислювальні середовища JupyterLab та VS Code, де ви пишете скрипти) доступні за ціною, але не безкоштовні. Інстанс t3.medium коштує приблизно $0,60 за 10 годин використання, а найменший тайм-аут простою до автоматичного вимкнення — 1 година.
Сховище GP3 коштує приблизно $2 за 15 ГБ на місяць. Незначна сума.
Закономірність: Інфраструктура (домени, проєкти, каталог) = по суті безкоштовно. Обчислення (endpoints, tracking servers, code spaces) = тут зростає рахунок. Управління (Lake Formation, дозволи) = безкоштовно. Сховище = дешево.
Наша рекомендація: якщо ви наперед не знаєте, яка функціональність знадобиться вашому проєкту, ви можете створити профіль проєкту "All Capabilities" з усіма доданими блюпринтами та встановити їх усі в ONDEMAND, а не ONCREATE. Якщо ви не знаєте, що створює блюпринт, — не активуйте його. Наші наступні статті в цій серії пояснять кожен блюпринт та що він створює.
Як ми допомагаємо з витратами
Як AWS Partner, ми допомагаємо клієнтам отримати переваги у витратах, що перевищують доступні через звичайну оптимізацію обчислень, — економію, недоступну при роботі з AWS напряму. Усі клієнти отримують DoIt PartnerOps, крос-хмарну платформу FinOps та відповідності, без додаткової плати. Вона забезпечує видимість того, які саме ресурси, створені блюпринтами, генерують витрати. Ми бачили, як клієнти заощаджували суму, еквівалентну нашому консультаційному гонорару, лише завдяки інструментам оптимізації витрат.
Прагматичний шлях: починайте з малого, доводьте цінність
Не намагайтеся осягнути неосяжне. Виберіть одне критичне джерело даних, одну доменну одиницю, одного споживача та доведіть, що патерн працює, перш ніж просити когось іншого змінитися.
Крок 1: Визначте найбільш запитуваний набір даних — той, який кожен проєкт наразі отримує через Slack DM, спільні диски або ручний експорт. Або виберіть больову точку: "Ми переплачуємо за цю існуючу платформу SAS і потребуємо міграції на сучасну архітектуру."
Крок 2: Створіть проєкт-продюсер Master Data, призначте власника даних та налаштуйте доступ Lake Formation через SageMaker Unified Studio, а не безпосередньо в консолі Lake Formation.
Крок 3: Опублікуйте в SageMaker Catalog з метаданими, термінами глосарію та правилами якості.
Крок 4: Підключіть один проєкт-споживач. Доведіть, що вони можуть знайти дані та запитувати їх без звернення до когось. Підключіть AWS QuickSight, щоб бізнес-стейкхолдери могли взаємодіяти з BI-дашбордом. Реакція зазвичай миттєва.
Крок 5: Святкуйте перемогу. Потім беріться за наступний набір даних. Якщо зроблено правильно, кожне успішне підключення створює щонайменше одного внутрішнього євангеліста — людину, яка бачила, як це працює, і розповідає колегам. Ці євангелісти критично важливі. Консультанти не мають такого рівня довіри. Підтримка колег поширює філософію data mesh набагато ефективніше, ніж будь-який наказ зверху.
Це саме те, що рекомендує Well-Architected lens: швидкі цикли поставки з ітераціями на основі отриманих уроків. Альтернатива (масштабне одномоментне розгортання mesh, що вимагає від усіх одночасних змін) гине на засіданнях комітетів з управління.
Для команд, які хочуть автоматизувати цей процес за допомогою Infrastructure as Code: ми підтримуємо опініонований open-source L2 construct library для SageMaker Unified Studio, що керується projen. Він створює домени, доменні одиниці, проєкти та блюпринти в одному 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 перетворила площину управління на готовий продукт: домени, проєкти, каталог та дозволи Lake Formation. Технологія працює. Успіх чи невдача вашого впровадження залежать від того, чи зможе ваша організація впровадити федеративне володіння, не створюючи більше бюрократії, ніж усуває.
Ключове розуміння не змінилося: неможливо запускати безпечні AI-навантаження в масштабах компанії без детального, контекстно-специфічного доступу до керованих даних. Піраміда потреб AI застосовується тут: чисті, керовані, доступні дані — це фундамент, на якому тримається все інше. Data mesh — це не побічний проєкт поряд із вашою AI-дорожньою картою. Це те, що робить корпоративний AI можливим.
Якщо це описує вашу проблему — бачення доступу до даних на рівні всієї компанії без чіткого шляху звідси туди, саме з цим ми допомагаємо. Як AWS Partner, ми надаємо сертифікації, переваги у витратах та практичний досвід.
