Створюйте та навчайте моделі ML за допомогою архітектури сітки даних на AWS: Частина 1

Організації в різних галузях використовують штучний інтелект (AI) і машинне навчання (ML) для вирішення бізнес-завдань, характерних для їх галузі. Наприклад, у сфері фінансових послуг ви можете використовувати AI та ML для вирішення проблем, пов’язаних із виявленням шахрайства, прогнозуванням кредитного ризику, прямим маркетингом та багатьма іншими.

Великі підприємства іноді створюють центр передового досвіду (CoE), щоб задовольняти потреби різних напрямків бізнесу (LoBs) за допомогою інноваційної аналітики та проектів ML.

Щоб створити високоякісні та ефективні моделі ML у великому масштабі, їм потрібно зробити наступне:

• Надайте простий спосіб доступу до відповідних даних для їх аналітики та ML CoE
• Створіть підзвітність постачальників даних з окремих LoB для обміну підібраними даними, які можна знайти, зрозумілі, сумісні та надійні

Це може скоротити тривалий час циклу для перетворення варіантів використання ML з експерименту на виробництво та створити цінність для бізнесу в усій організації.

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

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

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

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

Огляд сітки даних

Засновник шаблону сітки даних Жамак Дехгані у своїй книзі Сітка даних, що забезпечує масштабне використання цінностей, керованих даними, визначив чотири принципи щодо мети сітки даних:

• Володіння розподіленим доменом – Здійснити організаційний перехід від централізованого володіння даними фахівцями, які керують технологіями платформи даних, до децентралізованої моделі володіння даними, повертаючи володіння та підзвітність даними до LoB, де дані виробляються (домени, узгоджені з джерелом) або споживаються ( домени, орієнтовані на споживання).
• Дані як продукт – Підвищити підзвітність обміну керованими, високоякісними, сумісними та безпечними даними. Таким чином, виробники даних з різних LoBs несуть відповідальність за створення даних у споживаній формі прямо в джерелі.
• Аналітика самообслуговування – Щоб спростити досвід користувачів даних аналітики та ML, щоб вони могли знаходити, отримувати доступ і використовувати продукти даних за допомогою своїх бажаних інструментів. Крім того, для оптимізації досвіду постачальників даних LoB для створення, розгортання та підтримки продуктів даних за допомогою рецептів і повторно використовуваних компонентів і шаблонів.
• Об’єднане обчислювальне управління – Об’єднати й автоматизувати прийняття рішень, пов’язаних із керуванням доступом до даних і контролем, на рівні власників даних із різних LoB, що все ще відповідає ширшій правовій політиці, політиці відповідності та безпеки організації, яка в кінцевому підсумку забезпечується через сітка.

AWS представила своє бачення створення сітки даних на основі AWS у різних публікаціях:

• По-перше, ми зосередилися на організаційній частині, пов’язаній із володінням розподіленим доменом і принципами використання даних як продукту. Автори описали бачення вирівнювання кількох LOB в організації для стратегії продукту даних, яка надає доменам, узгодженим із споживанням, інструменти для пошуку та отримання необхідних даних, гарантуючи при цьому необхідний контроль над використанням цих даних шляхом запровадження відповідальності за домени, узгоджені з джерелом, щоб надати продукти даних, готові до використання безпосередньо в джерелі. Для отримання додаткової інформації див Як JPMorgan Chase створив архітектуру сітки даних, щоб отримати значну вартість для покращення своєї корпоративної платформи даних.
• Потім ми зосередилися на технічній частині, пов’язаній зі створенням продуктів даних, аналітикою самообслуговування та принципами федеративного керування обчисленнями. Автори описали основні сервіси AWS, які дають змогу доменам, узгодженим з джерелом, створювати та обмінюватися продуктами даних, широкий спектр сервісів, які можуть дозволити доменам, орієнтованим на споживачів, використовувати продукти даних різними способами на основі їхніх інструментів, яким вони віддають перевагу, і варіантів використання, які вони використовують. і, нарешті, сервіси AWS, які регулюють процедуру обміну даними шляхом застосування політик доступу до даних. Для отримання додаткової інформації див Створіть архітектуру сітки даних за допомогою AWS Lake Formation і AWS Glue.
• Ми також показали рішення для автоматизації виявлення даних і контролю доступу за допомогою централізованого інтерфейсу користувача сітки даних. Для отримання додаткової інформації див Створіть робочий процес обміну даними з AWS Lake Formation для вашої сітки даних.

Приклад використання фінансових послуг

Як правило, великі організації, що надають фінансові послуги, мають кілька LoBs, наприклад споживчий банкінг, інвестиційний банкінг і управління активами, а також одну або кілька команд аналітики та ML CoE. Кожен LoB надає різні послуги:

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

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

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

Дотримуючись соціально-технічної концепції сітки даних, ми починаємо з соціального аспекту з низки організаційних кроків, таких як:

• Використання експертів домену для визначення меж для кожного домену, щоб кожен продукт даних можна було зіставити з певним доменом
• Ідентифікація власників для продуктів даних, які надаються з кожного домену, тому кожен продукт даних має стратегію, визначену їх власником
• Визначення політики управління з глобальних і локальних або федеративних стимулів, тому, коли споживачі даних отримують доступ до певного продукту даних, політика доступу, пов’язана з продуктом, може автоматично застосовуватися через центральний рівень управління даними

Потім ми переходимо до технічного аспекту, який включає наступний наскрізний сценарій, визначений на попередній діаграмі:

1. Розширте можливості LoB споживчого банківського обслуговування за допомогою інструментів для створення готового до використання продукту з даними про кредитний профіль споживача.
2. Дозвольте споживчому банківському LoB ділитися продуктами даних із центральним рівнем управління.
3. Вбудуйте глобальні та об’єднані визначення політик доступу до даних, які слід застосовувати під час доступу до продукту з даними профілю споживчого кредиту через центральне управління даними.
4. Дозвольте аналітиці та ML CoE виявляти та отримувати доступ до продукту даних через рівень центрального управління.
5. Надайте аналітиці та ML CoE інструменти для використання продукту даних для створення та навчання моделі прогнозування кредитного ризику. Ми не розглядаємо останні кроки (6 і 7 на попередній діаграмі) у цій серії. Однак, щоб показати бізнес-цінність, яку така модель ML може принести організації в наскрізному сценарії, ми проілюструємо наступне:
6. Пізніше цю модель можна було б знову розгорнути в системах, орієнтованих на клієнтів, наприклад, на веб-порталі або мобільному додатку для банківських послуг.
7. Його можна спеціально використовувати в кредитній заявці для оцінки профілю ризику кредитних та іпотечних запитів.

Далі ми описуємо технічні потреби кожного з компонентів.

Глибоке занурення в технічні потреби

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

Споживач даних: Analytics і ML CoE

Споживачі даних, такі як спеціалісти з аналітики та ML CoE, повинні вміти:

• Виявляйте та отримуйте доступ до відповідних наборів даних для певного випадку використання
• Будьте впевнені, що набори даних, до яких вони хочуть отримати доступ, уже підібрані, оновлені та мають надійні описи
• Запитувати доступ до наборів даних, які цікавлять їхні бізнес-кейси
• Використовуйте їхні бажані інструменти для запитів і обробки таких наборів даних у їхньому середовищі для ML без необхідності копіювати дані з вихідного віддаленого місця або турбуватися про інженерні чи інфраструктурні складності, пов’язані з обробкою даних, які фізично зберігаються на віддаленому сайті.
• Отримуйте сповіщення про будь-які оновлення даних, зроблені власниками даних

Виробник даних: право власності на домен

Виробники даних, наприклад групи доменів з різних LoBs в організації фінансових послуг, повинні зареєструватися та надати спільний доступ до підібраних наборів даних, які містять таке:

• Технічні та операційні метадані, такі як імена та розміри баз даних і таблиць, схеми стовпців і ключі
• Бізнес-метадані, такі як опис даних, класифікація та конфіденційність
• Відстеження метаданих, таких як еволюція схеми від вихідної до цільової форми та будь-яких проміжних форм
• Метадані якості даних, такі як співвідношення правильності та повноти та зміщення даних
• Політики та процедури доступу

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

Управління даними: можливість виявлення, доступності та перевірки

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

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

Огляд рішення

На наступній діаграмі показано високорівневу архітектуру запропонованого рішення.

Ми розглядаємо споживання даних аналітикою та ML CoE Амазонка Афіна та Amazon SageMaker in частина 2 цієї серії.

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

Споживчий банкінг LoB (виробник даних)

Одним із основних принципів сітки даних є концепція даних як продукту. Дуже важливо, щоб група даних домену банківського обслуговування споживачів працювала над підготовкою продуктів даних, готових до використання споживачами даних. Це можна зробити за допомогою інструментів AWS для вилучення, перетворення та завантаження (ETL), таких як AWS Glue, для обробки необроблених даних, зібраних на Служба простого зберігання Amazon (Amazon S3) або підключіться до сховищ оперативних даних, де створюються дані. Ви також можете використовувати DataBrew, який є інструментом підготовки візуальних даних без коду, який полегшує очищення та нормалізацію даних.

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

Управління даними

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

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

Крім того, Lake Formations пропонує a API обміну даними які можна використовувати для обміну даними між різними обліковими записами. Це дозволяє споживачам аналітики та ML CoE запускати запити Athena, які надсилають запити та об’єднують таблиці в кількох облікових записах. Для отримання додаткової інформації зверніться до Посібник розробника AWS Lake Formation.

Менеджер доступу до ресурсів AWS (AWS RAM) забезпечує безпечний спосіб обміну ресурсами через AWS Identity and Access Manager (IAM) ролей і користувачів в облікових записах AWS в межах організації або організаційних підрозділів (OU) в Організації AWS.

Lake Formation разом із AWS RAM забезпечує один спосіб керування обміном даними та доступом між обліковими записами AWS. Ми називаємо цей підхід Контроль доступу на основі оперативної пам'яті. Додаткову інформацію про цей підхід див Створіть робочий процес обміну даними з AWS Lake Formation для вашої сітки даних.

Lake Formation також пропонує інший спосіб керування обміном даними та використанням доступу Теги утворення озера. Ми називаємо цей підхід контроль доступу на основі тегів. Для отримання додаткової інформації див Створіть сучасну архітектуру даних і шаблон сітки даних у масштабі за допомогою керування доступом на основі тегів AWS Lake Formation.

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

Передумови

Щоб налаштувати архітектуру сітки даних, вам потрібні принаймні три облікові записи AWS: обліковий запис виробника, обліковий запис центрального користувача та обліковий запис споживача.

Розгорніть середовище сітки даних

Щоб розгорнути середовище сітки даних, ви можете скористатися наступним GitHub сховище. Цей репозиторій містить три AWS CloudFormation шаблони, які розгортають середовище сітки даних, що включає кожен обліковий запис (виробник, центральний і споживач). У кожному обліковому записі ви можете запустити відповідний шаблон CloudFormation.

Центральний рахунок

У центральному обліковому записі виконайте такі дії:

1. Запустіть стек CloudFormation:
   
2. Створіть двох користувачів IAM:
   1. DataMeshOwner
   2. ProducerSteward
3. Грант DataMeshOwner як адміністратор Lake Formation.
4. Створіть одну роль IAM:
   1. LFRegisterLocationServiceRole
5. Створіть дві політики IAM:
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. Створіть базу даних кредитної картки для ProducerSteward на рахунок виробника.
7. Поділитися дозволом на розташування даних обліковому запису виробника.

Обліковий запис виробника

В обліковому записі виробника виконайте такі дії:

1. Запустіть стек CloudFormation:
   
2. Створіть відро S3 credit-card, який тримає стіл credit_card.
3. Дозволити доступ до відра S3 для ролі служби Lake Formation центрального облікового запису.
4. Створіть сканер AWS Glue creditCrawler-<ProducerAccountID>.
5. Створіть роль служби сканера AWS Glue.
6. Надайте дозволи на розташування сегмента S3 credit-card-<ProducerAccountID>-<aws-region> на роль сканера AWS Glue.
7. Створіть користувача IAM-продюсера.

Рахунок споживача

В обліковому записі споживача виконайте такі дії:

1. Запустіть стек CloudFormation:
   
2. Створіть відро S3 <AWS Account ID>-<aws-region>-athena-logs.
3. Створіть робочу групу Athena consumer-workgroup.
4. Створіть користувача IAM ConsumerAdmin.

Додайте базу даних і підпишіться на обліковий запис споживача

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

Реєстрація продукту даних

Наступна архітектура описує детальні кроки того, як команда споживчого банкінгу LoB, яка діє як виробники даних, може зареєструвати свої продукти даних в центральному обліковому записі керування даними (вбудовані продукти даних до сітки даних організації).

Загальні кроки для реєстрації продукту обробки даних такі:

1. Створіть цільову базу даних для продукту даних в обліковому записі центрального управління. Як приклад, шаблон CloudFormation із центрального облікового запису вже створює цільову базу даних credit-card.
2. Поділіться створеною цільовою базою даних з джерелом в обліковому записі виробника.
3. Створіть посилання на ресурс спільної бази даних в обліковому записі виробника. На наступному знімку екрана ми бачимо на консолі Lake Formation в обліковому записі виробника, що rl_credit-card це посилання на ресурс credit-card бази даних.
   
4. Заповнити таблиці (даними, зібраними в обліковому записі виробника) у базі даних посилань на ресурси (rl_credit-card) за допомогою сканера AWS Glue в обліковому записі виробника.
   

Створена таблиця автоматично з’являється в обліковому записі центрального управління. На наступному знімку екрана показано приклад таблиці в Lake Formation у центральному обліковому записі. Це після виконання попередніх кроків для заповнення бази даних посилань на ресурси rl_credit-card на рахунку виробника.

Висновок

У частині 1 цієї серії ми обговорювали цілі організацій, що надають фінансові послуги, щоб досягти більшої гнучкості для своїх аналітичних і ML-команд і скоротити час від отримання даних до розуміння. Ми також зосередилися на створенні архітектури сітки даних на AWS, де ми представили прості у використанні, масштабовані та економічно ефективні служби AWS, такі як AWS Glue, DataBrew і Lake Formation. Команди, які створюють дані, можуть використовувати ці служби для створення та обміну підібраними, високоякісними, сумісними та безпечними продуктами даних, готовими до використання різними споживачами даних для аналітичних цілей.

In частина 2, ми зосереджуємося на аналітиці та командах ML CoE, які використовують продукти даних, якими користуються LoB споживчого банківського обслуговування, щоб створити модель прогнозування кредитного ризику за допомогою таких служб AWS, як Athena та SageMaker.

---

Про авторів

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

Хасан Пунавала Хасан є старшим архітектором рішень спеціаліста зі штучного інтелекту/ML в AWS. Він допомагає клієнтам розробляти та розгортати програми машинного навчання у виробництві на AWS. Він має понад 12 років досвіду роботи науковцем з даних, практиком машинного навчання та розробником програмного забезпечення. У вільний час Хасан любить досліджувати природу та проводити час з друзями та родиною.

Бенуа де Патул є архітектором спеціалістів із штучного інтелекту та ML в AWS. Він допомагає клієнтам, надаючи вказівки та технічну допомогу для створення рішень, пов’язаних із ШІ/ML ​​за допомогою AWS. У вільний час любить грати на піаніно та проводити час з друзями.