Создание и обучение моделей машинного обучения с использованием архитектуры сетки данных в AWS: часть 1

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

Крупные предприятия иногда создают центр передового опыта (CoE) для удовлетворения потребностей различных направлений бизнеса (LoB) с помощью инновационных проектов аналитики и машинного обучения.

Чтобы создавать высококачественные и производительные модели машинного обучения в масштабе, им необходимо сделать следующее:

• Обеспечьте простой способ доступа к соответствующим данным для их аналитики и ML CoE.
• Обеспечьте подотчетность поставщиков данных из отдельных бизнес-подразделений, чтобы совместно использовать тщательно отобранные активы данных, которые являются доступными для обнаружения, понятными, интероперабельными и заслуживающими доверия.

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

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

В этой серии, состоящей из двух частей, мы даем рекомендации о том, как организации могут построить современную архитектуру данных с помощью шаблона проектирования сетки данных в AWS, а также позволить аналитике и Центру обучения машинного обучения создавать и обучать модели машинного обучения с данными из нескольких бизнес-объектов. Мы используем пример организации, предоставляющей финансовые услуги, чтобы установить контекст и вариант использования для этой серии.

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

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

Обзор сетки данных

Основатель шаблона сетки данных Жамак Дехгани в своей книге Сетка данных, обеспечивающая ценность, основанную на данных, в масштабе, определил четыре принципа для достижения цели сетки данных:

• Владение распределенным доменом – Провести организационный переход от централизованного владения данными специалистами, управляющими технологиями платформы данных, к децентрализованной модели владения данными, возвращая право собственности и подотчетность данных бизнес-направлениям, в которых данные производятся (домены, ориентированные на источник) или потребляются ( домены, ориентированные на потребление).
• Данные как продукт – Для повышения ответственности за совместное использование проверенных, высококачественных, интероперабельных и безопасных активов данных. Таким образом, производители данных из разных бизнес-подразделений несут ответственность за создание данных в пригодной для использования форме прямо в источнике.
• Аналитика самообслуживания – Чтобы оптимизировать работу пользователей данных с аналитикой и машинным обучением, чтобы они могли обнаруживать, получать доступ и использовать продукты данных с помощью предпочитаемых ими инструментов. Кроме того, чтобы оптимизировать опыт поставщиков данных бизнес-приложений для создания, развертывания и обслуживания продуктов данных с помощью рецептов и повторно используемых компонентов и шаблонов.
• Федеративное управление вычислениями – Объединение и автоматизация принятия решений, связанных с управлением и контролем доступа к данным, на уровне владельцев данных из различных бизнес-подразделений, что по-прежнему соответствует более широкой политике организации в области законодательства, соответствия и безопасности, которые в конечном итоге применяются посредством сетка.

AWS представила свое видение построения сетки данных поверх AWS в различных сообщениях:

• Во-первых, мы сосредоточились на организационной части, связанной с владением распределенным доменом и данными как принципами продукта. Авторы описали видение согласования нескольких LOB в организации со стратегией продукта данных, которая предоставляет доменам, ориентированным на потребление, инструменты для поиска и получения необходимых им данных, гарантируя при этом необходимый контроль над использованием этих данных путем введения ответственности за домены, выровненные по источнику, для предоставления продуктов данных, готовых к использованию непосредственно у источника. Для получения дополнительной информации см. Как компания JPMorgan Chase построила архитектуру сетки данных, чтобы повысить ценность своей корпоративной платформы данных.
• Затем мы сосредоточились на технической части, связанной с созданием продуктов данных, аналитикой самообслуживания и принципами управления федеративными вычислениями. Авторы описали основные сервисы AWS, которые позволяют доменам, ориентированным на источник, создавать продукты данных и обмениваться ими, широкий спектр сервисов, которые могут позволить доменам, ориентированным на потребителя, использовать продукты данных различными способами в зависимости от их предпочтительных инструментов и вариантов использования, которые они используют. работают над сервисами AWS, которые регулируют процедуру обмена данными, применяя политики доступа к данным. Для получения дополнительной информации см. Разработка архитектуры сетки данных с использованием AWS Lake Formation и AWS Glue.
• Мы также продемонстрировали решение для автоматизации обнаружения данных и управления доступом с помощью централизованного пользовательского интерфейса сетки данных. Для получения более подробной информации см. Создайте рабочий процесс обмена данными с помощью AWS Lake Formation для своей сетки данных.

Пример использования финансовых услуг

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

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

Каждая бизнес-сфера определяет свои собственные продукты данных, которые курируются людьми, которые разбираются в данных и лучше всего подходят для определения того, кто уполномочен их использовать и как их можно использовать. Напротив, другие бизнес-направления и области приложений, такие как аналитика и ML CoE, заинтересованы в обнаружении и использовании качественных продуктов данных, объединении их вместе для получения информации и принятии решений на основе данных.

На следующем рисунке показаны некоторые бизнес-объекты и примеры продуктов данных, которые они могут совместно использовать. Он также показывает потребителей продуктов данных, таких как аналитика и ML CoE, которые создают модели ML, которые можно развернуть в приложениях, ориентированных на клиентов, для дальнейшего повышения качества обслуживания конечных клиентов.

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

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

Затем мы переходим к техническому аспекту, который включает в себя следующий сквозной сценарий, определенный на предыдущей диаграмме:

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

Далее мы опишем технические потребности каждого из компонентов.

Глубокое погружение в технические потребности

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

Потребитель данных: Analytics и ML CoE

Потребители данных, такие как специалисты по обработке и анализу данных из отдела аналитики и ML CoE, должны иметь возможность делать следующее:

• Обнаружение и доступ к соответствующим наборам данных для данного варианта использования
• Будьте уверены, что наборы данных, к которым они хотят получить доступ, уже проверены, обновлены и имеют надежные описания.
• Запросить доступ к наборам данных, представляющим интерес для их бизнес-кейсов
• Используйте свои предпочтительные инструменты для запроса и обработки таких наборов данных в своей среде для машинного обучения без необходимости репликации данных из исходного удаленного местоположения или беспокойства о технических или инфраструктурных сложностях, связанных с обработкой данных, физически хранящихся на удаленном сайте.
• Получайте уведомления о любых обновлениях данных, сделанных владельцами данных

Производитель данных: владение доменом

Производители данных, такие как доменные команды из разных бизнес-подразделений в организации, предоставляющей финансовые услуги, должны зарегистрироваться и поделиться курируемыми наборами данных, которые содержат следующее:

• Технические и операционные метаданные, такие как имена и размеры баз данных и таблиц, схемы столбцов и ключи.
• Бизнес-метаданные, такие как описание данных, классификация и конфиденциальность
• Отслеживание метаданных, таких как эволюция схемы от исходной до целевой формы и любых промежуточных форм
• Метаданные о качестве данных, такие как коэффициенты правильности и полноты и предвзятость данных
• Политики и процедуры доступа

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

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

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

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

Обзор решения

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

Мы решаем проблему потребления данных аналитикой и ML CoE с помощью Амазонка Афина и Создатель мудреца Амазонки in часть 2 из этой серии.

В этом посте мы сосредоточимся на процессе загрузки данных в сетку данных и опишем, как отдельные бизнес-направления, такие как группа данных домена потребительского банковского обслуживания, могут использовать инструменты AWS, такие как Клей AWS и AWS Glue Data Brew готовить, курировать и повышать качество своих продуктов данных, а затем регистрировать эти продукты данных в центральной учетной записи управления данными через Формирование озера AWS.

Потребительский банк LoB (поставщик данных)

Одним из основных принципов сетки данных является концепция данных как продукта. Очень важно, чтобы команда по работе с данными домена потребительского банкинга работала над подготовкой продуктов данных, готовых к использованию потребителями данных. Это можно сделать с помощью инструментов AWS для извлечения, преобразования и загрузки (ETL), таких как AWS Glue, для обработки необработанных данных, собранных на Простой сервис хранения Amazon (Amazon S3) или, в качестве альтернативы, подключиться к оперативным хранилищам данных, в которых создаются данные. Вы также можете использовать ДанныеБрю, который представляет собой визуальный инструмент подготовки данных без кода, который упрощает очистку и нормализацию данных.

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

Управление данными

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

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

Кроме того, Lake Formations предлагает API обмена данными которые вы можете использовать для обмена данными через разные аккаунты. Это позволяет потребителю аналитики и ML CoE выполнять запросы Athena, которые запрашивают и объединяют таблицы в нескольких учетных записях. Для получения дополнительной информации см. Руководство разработчика AWS Lake Formation.

Диспетчер доступа к ресурсам AWS (AWS RAM) обеспечивает безопасный способ обмена ресурсами через Диспетчер идентификации и доступа AWS (IAM) роли и пользователи в учетных записях AWS внутри организации или организационных подразделений (OU) в Организации AWS.

Lake Formation вместе с AWS RAM предоставляет один из способов управления совместным использованием данных и доступом между учетными записями AWS. Мы называем этот подход как Контроль доступа на основе оперативной памяти. Подробнее об этом подходе см. Создайте рабочий процесс обмена данными с помощью AWS Lake Formation для своей сетки данных.

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

В этом посте мы используем подход к управлению доступом на основе тегов, поскольку он упрощает создание политик для меньшего числа логических тегов, которые обычно находятся в разных бизнес-объектах, вместо указания политик для именованных ресурсов на уровне инфраструктуры.

Предпосылки

Чтобы настроить архитектуру сетки данных, вам потребуются как минимум три учетные записи 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. Создайте рабочую группу Афины consumer-workgroup.
4. Создайте пользователя IAM ConsumerAdmin.

Добавьте базу данных и подпишите на нее учетную запись потребителя.

После запуска шаблонов вы можете пройти шаг за шагом руководство чтобы добавить продукт в каталог данных и подписаться на него потребителем. Руководство начинается с создания базы данных, в которой производитель может размещать свои продукты, а затем объясняется, как потребитель может подписаться на эту базу данных и получить доступ к данным. Все это выполняется при использовании LF-метки, какой контроль доступа на основе тегов для образования озера.

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

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

Общие шаги для регистрации продукта данных следующие:

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 этой серии мы обсудили цели организаций, предоставляющих финансовые услуги, по повышению гибкости своих аналитических и машинных групп и сокращению времени от получения данных до анализа. Мы также сосредоточились на создании архитектуры сетки данных на AWS, где представили простые в использовании, масштабируемые и экономичные сервисы AWS, такие как AWS Glue, DataBrew и Lake Formation. Команды по производству данных могут использовать эти сервисы для создания и обмена проверенными, высококачественными, совместимыми и безопасными продуктами данных, которые готовы к использованию различными потребителями данных в аналитических целях.

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

---

Об авторах

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

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

Бенуа де Патуль является специалистом по архитектуре решений AI/ML в AWS. Он помогает клиентам, предоставляя рекомендации и техническую помощь по созданию решений, связанных с искусственным интеллектом и машинным обучением, с использованием AWS. В свободное время он любит играть на пианино и проводить время с друзьями.