AWS DataZone: покрокова інструкція як спростити роботу з каталогами даних та їхнім пошуком

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт усім! Мене звати Юля — я Big Data Architect в SoftServe і маю значний досвід у роботі з різноманітними типами даних. У цій статті я хочу поговорити про переваги та нюанси використання нового сервісу від Amazon — Amazon DataZone.

У наш час, коли гігабайти інформації генеруються щосекунди, просте зберігання даних в одній системі, як-от реляційних базах даних, вже не вирішує всіх задач. Дані зараз розкидані повсюди, і ключовим завданням є не тільки їх аналіз чи доступ до них, але й вміння знайти потрібну інформацію.

Саме тут із рішенням приходить Amazon DataZone, сервіс, який обіцяє революціонізувати спосіб, за допомогою якого ми інтегруємо, аналізуємо та управляємо даними в масштабах всієї організації. З мого досвіду, Amazon DataZone — це не просто ще один інструмент в арсеналі дата архітекта, а скоріше місток, що з’єднує різні джерела даних, надаючи єдину точку доступу до цілісної картини всіх даних.

Огляд Amazon DataZone

У процесі вдосконалення або створення платформ для даних з’являється все більше перешкод, пов’язаних з управлінням даними. Дані надходять з різних джерел і контролюються різними командами, що вимагає методу, за допомогою якого ці команди могли б навігувати та отримувати доступ до цієї інформації.

Останніми роками на ринку з’явились інструменти, призначені для полегшення управління цими викликами, такі як Datahub, Microsoft Purview та Alation. Amazon, не бажаючи залишатися осторонь, також представив своє рішення в цій сфері, яке називається Amazon DataZone.

Amazon DataZone — це оптимізований сервіс для управління даними, який дозволяє швидко каталогізувати, виявляти, ділитися та управляти даними між AWS, локальними ресурсами та джерелами третіх сторін. Він дозволяє адміністраторам та кураторам даних (data steward) регулювати доступ до даних за допомогою точних налаштувань забезпечуючи відповідні рівні доступу та контекст.

Це спрощує доступ і співпрацю з організаційними даними для широкого кола користувачів, включаючи інженерів, науковців у галузі даних (data scientist), менеджерів продуктів, аналітиків та бізнес-персонал, з метою ухвалення обґрунтованих рішень.

Місце Amazon DataZone серед сервісів AWS

Amazon DataZone — це сервіс, доступний поза стандартною консоллю управління AWS через окреме посилання, відоме як портал даних. Він виступає як платформа самообслуговування (self-service platform) для даних з трьома ключовими функціональностями, адаптованими до ролі користувачів:

1. Куратори даних (Data Stewards) мають можливість створювати бізнес-словник та встановлювати політики управління.
2. Виробники (Producers) мають можливість завантажувати дані до бізнес-каталогу даних.
3. Споживачі (Consumers) можуть досліджувати каталог, підписуватися на дані та використовувати їх в інтегрованих інструментах споживання даних.

Місце Amazon DataZone у екосистемі AWS

Amazon DataZone — це новаторський додатковий сервіс в екосистемі хмарних сервісів Amazon, який призначений для розширення можливостей, а не заміни, широкого спектру існуючих Amazon Web Services (AWS). Однак, такий підхід дещо ускладнений, оскільки він вимагає підтримки оригінальних конфігурацій доступу та дозволів, встановлених у середовищі AWS.

Наприклад, управління доступом до баз даних Athena продовжує регулюватися Lake Formation, вимагаючи від користувачів налаштування доступу через цей конкретний сервіс. Це розподіл обов’язків гарантує, що DataZone безперебійно інтегрується з інфраструктурою AWS, дотримуючись встановлених рамок безпеки та управління.

Аналогічно, контроль доступу до даних Redshift здійснюється через наявні механізми конфігурації Redshift та адміністративні групи. Ця інтеграція вимагає, щоб користувачі ознайомилися з базовими сервісами AWS, аби ефективно використовувати можливості DataZone.

По суті, DataZone діє як модульний компонент у екосистемі AWS, вимагаючи детального та витонченого підходу до конфігурації та управління системою. Користувачі повинні ретельно зібрати та налаштувати весь системний комплекс, подібно до складання складного пазла, де кожна деталь має бути ідеально розміщена для досягнення бажаного результату.

Цей процес підкреслює значення ретельного розуміння сервісів AWS і їх конкретних функцій у забезпеченні надійного, ефективного управління даними та доступом до них у хмарному середовищі.

Amazon DataZone на практиці

Для ефективного пояснення термінології DataZone я підготувала два рисунки, які базуються на двох головних шаблонах (blueprints) підтримуваних DataZone: Data lake blueprint та Data warehouse. Це зроблено для того, щоб зробити зрозумілими термінологію та структуру DataZone, показуючи які конфігурації шаблонів використовуються для розгортання необхідної інфраструктури.

Ці схеми можуть слугувати практичним посібником для розуміння термінів середовища Amazon DataZone.

Blueprint для Data Warehouse з використанням Amazon DataZone

На схемі нижче показано, які опції можуть бути, якщо використовувати Data warehouse blueprint. Під час використання цього шаблону будуть створені всі необхідні конфігураційні налаштування (IAM ролі), потрібні для того, щоб мати змогу доєднатися до Redshift або Redshift serverless.

Опції під час використання Data Warehouse Blueprint

Нижче подано опис кожної опції:

1. Розпочинаємо зі створення домену (domain). Домен слугує центральним вузлом, що зв’язує таблиці (asset), користувачів та їхні проєкти. Кожен з власним унікальним посиланням на портал даних. Уявіть домен як незалежний вебсайт.

Вікно domains на AWS Console DataZone

2. Створюємо проєкт у межах домену. Домен може містити кілька проєктів, організованих логічно, наприклад, за назвами команд, які володіють даними: Маркетинг, Реклама тощо. Проєкти дозволяють команді користувачів працювати разом над різними бізнес-сценаріями.

Вікно Projects на порталі DataZone

3. Після створення проєкту ви можете створити середовище (environment). Це місце, де ви використовуєте blueprints. Ви налаштовуєте environment за допомогою environment profiles, які є готовими комбінаціями ресурсів і blueprints для легкого налаштування. При використанні data warehouse blueprint споживачі (consumers) можуть під’єднатися до свого Amazon Redshift для пошуку даних і створення нових наборів даних. Виробники (producers) роблять те саме, але також можуть ділитися цими наборами даних у каталозі Amazon DataZone для використання іншими.

Вікно Environment на порталі DataZone

4. Data source створюється для імпорту технічних метаданих з Amazon Redshift. Цей data source повинен вже існувати в Amazon Redshift, щоб його можна було додати до Amazon DataZone.

5. Після того, як data source доданий можна його виконати, після чого всі метадані у вигляді asset (даних про кожну таблицю) запишуться у розділ Inventory.

Вікно результату виконання команди Run для data source Redshift

6. На цьому кроці метадані переглядаються, вносяться правки, щоб інформація у каталозі даних відповідала дійсності.

Вікно Inventory

7. Після перегляду даних їх можна публікувати, роблячи доступними для пошуку користувачам домену. Зверніть увагу, тільки власник або contributor проєкту може публікувати asset у каталозі.

8. Як зазначалося раніше, є producers (власники даних, які додають дані до каталогу) та consumers (користувачі, які шукають дані для аналізу або запитів). Із DataZone користувачі можуть шукати та «гуглити» дані в межах свого домену.

9. Коли користувач знаходить потрібні дані, він може підписатися на них, натиснувши кнопку підписки на порталі даних. Це надсилає запит до producer, який може схвалити або відхилити його.

Зверніть увагу, створене середовище повинно мати доступ до запитуваних таблиць, інакше користувач не зможе переглядати дані в Redshift, особливо, якщо таблиця перебуває в іншій базі даних, ніж та, до якої підімкнено середовище, оскільки міжбазові запити можуть бути обмежені типом кластера Redshift.

Вікно Subscribed для data source Redshift

10. Як тільки producer схвалює запит, користувач автоматично отримує доступ . Потім користувач може перейти з порталу даних до середовища Redshift. При цьому доступ користувачу надається автоматично через згенероваий тимчасовий пароль. Коли користувач перейде на Redshift він буде бачити тільки ті таблиці, до яких йому дали доступ.

11. Користувачі також мають можливість створювати нові asset, по суті створюючи нові таблиці в середовищі Redshift. Підключившись до Redshift, користувачі можуть виконувати SQL-скрипти для створення таблиць, а потім повторно публікувати asset, щоб зробити їх доступними для запитів.

12. Після виконання команди publish користувачі можуть підписатися (кнопка subscribe) на нові додані таблиці.

Blueprint для DataLake з використанням Amazon DataZone

Другий наявний на цей час шаблон — це Data Lake Blueprint. Цей шаблон описує, як розпочати та налаштувати AWS Glue, AWS Lake Formation та Amazon Athena в каталозі Amazon DataZone.

На схемі нижче наведено, які опції можуть використовуватись для профілю Data Lake. Хоча вони значною мірою подібні на ті опції, що є у профілі Data Warehouse, все ж вони мають певні відмінності, які я поясню далі.

Опції під час використання Data Lake Blueprint

1 та 2: Початкові кроки створення домену та проєкту залишаються незмінними.

3: На цьому етапі вибір профілю Data Lake означає, що метадані таблиць будуть отримані з каталогу даних AWS Glue.

4-8: Тут містяться важливі деталі. Наразі Data Zone дозволяє користувачам доєднатися до даних через Redshift або Athena. Для того, щоб доступатись до даних з Athena, дані мають бути керовані Lake Formation.

Наприклад, якщо у AWS Glue було створено JDBC connection і додано AWS Glue Crawler для того, щоб заповнити метадані, такий набір даних вважатиметься unmanaged. Хоча подання запитів subscribe на unmanned asset можливе, однак користувач не зможе писати запити з Athena чи Redshift над цими даними.

Вікно для unmanaged data asset

9: Після створення проєкту DataZone автоматично генерує дві бази даних у Amazon Athena: одна закінчується суфіксом _pub_db, а інша — _sub_db. База даних з міткою pub буде містити нові створені і опубліковані користувачами таблиці, тоді як база даних sub буде містити дані, на які користувач підписався.

Якщо дані знаходяться на S3 Data Lake і керуються Lake Formation, тоді користувачі, підписані на ці дані, можуть доступатись до них через Athena. Критично важливо, щоб роль, яка доступається від імені DataZone, мала дозволи для таблиць у Lake Formation. Це має бути зроблено окремо адміністратором Lake Formation.

Додатково місцезнаходження S3, що містить дані, має бути зареєстроване в Lake Formation. Тільки з цими налаштуваннями користувачі зможуть підписуватися на дані та виконувати запити через Athena.

10: І тут виникає питання: що робити з unmanaged data asset, враховуючи, що користувачам все ще може знадобитись доступ? Управління цим аспектом вимагає окремого, спеціалізованого підходу. Коли користувач підписується на unmanaged data asset цю подію можна виявити через Event Bridge з події Subscription Request Created.

Як діяти далі, залежить від розсуду архітекта, який може налаштувати функцію Lambda або написати окрему аплікацію для полегшення процесу надання доступу. Незалежно від обраного рішення, організація цього процесу точно буде складним завданням.

11-12: Користувачі мають можливість перейти до Athena, створити нові asset і після запуску data source публікувати ці asset у каталозі Data Zone, так само як у сценарії з використанням Redshift. Всі створені asset будуть розміщені в Athena у базі даних _pub_db.

Висновки та загальні рекомендації

Загалом я вважаю, що AWS DataZone — це цікавий, але водночас складний сервіс. Як було підкреслено на початку, використання цього сервісу вимагає всебічного розуміння всіх пов’язаних сервісів, як-от Lake Formation, належної конфігурації ролей IAM, груп в Redshift, налаштування Event Bridge тощо. Це не рішення, яке працює «з коробки»; необхідно вивчити екосистему AWS, щоб розкрити його повний потенціал.

З точки зору користувача, після завершення початкового налаштування, AWS DataZone справді може значно спростити робочі процеси. Наявність центрального вузла для всієї інформації, документації пов’язаної з даними, і навіть запитів на доступ без необхідності додаткових інструментів на кшталт Jira є суттєвою перевагою.

Для тих, хто розглядає можливість використання AWS DataZone, слід мати реалістичні очікування. Це не всеосяжне рішення, яке працює відразу без докладання зусиль. Воно вимагає часу, архітектурного бачення та роботи розробників.

Однак кінцева винагорода виглядає перспективно. Ви отримуєте консолідоване, ефективне середовище, яке може значно покращити ваше управління даними та проєктами. Отже, рекомендую ставитися до DataZone з терпінням та готовністю інвестувати у фазу розробки, оскільки, скоріш за все, що результати виправдають витрачені зусилля.