Блог Amazon Web Services
Способы обработки данных для AI/ML
Оригинал статьи: ссылка (Brent Rabowsky, focuses on data science at AWS)
Тренировка точной модели машинного обучения (ML) требует многочисленных шагов, но самый важный из них всё же обработка данных. Примерами шагов обработки данных являются: преобразование данных во входной формат, поддерживаемый ML алгоритмом, масштабирование, нормализация, очистка и токенизация текста, и многое другое. Тем не менее, обработка данных в больших масштабах означает довольно серьёзные операционные накладные расходы: управление сложной инфраструктурой (кластеры обработки), написание кода для оркестрации всех составных частей процессов обработки, внедрение подходов безопасности и централизованного управления процессами (governance). К счастью, AWS предлагает широкий выбор инструментов обработки данных, подходящих для любых ML задач и соответствующих устоявшимся процессам в командах. Этот набор инструментов ещё больше увеличился после AWS re:Invent 2020, поэтому сейчас самое лучшее время определиться, по какому принципу из них выбирать.
Предпосылки: Data Lake или Lake House
Перед началом углубления в варианты надо решить, как мы согласуем наш выбор с теми технологиями, которые предпочитают инженеры данных? Разный инструментарий может подходить для разных ролей: инструменты, предпочитаемые специалистами машинного обучения могут лишь частично пересекаться с инструментами, используемыми инженерами данных для построения аналитических процессов, таких как составление отчётов. Хорошая новость в том, что AWS позволяет представителю каждой из ролей выбрать их предпочтительный инструментарий, и применить его на данные в рамках их организации без каких-то конфликтов. Ключевым элементов здесь является озеро данных на основе Amazon Simple Storage Service (Amazon S3), используемое в качестве центрального элемента архитектуры для всех данных в рамках организации. Его использование отделяет хранение данных от вычислительных мощностей для их обработки, и позволяет избежать проблемы, когда каждая из команд создает разрозненные хранилища данных.
Используя озеро данных в качестве ядра архитектуры, команды инженеров данных могут применять свои собственные инструменты для аналитических задач. В то же время, команды ML специалистов могут использовать свои любимые инструменты для работы с теми же самыми данными, но уже для задач ML. Несколько разных кластеров обработки данных, управляемых различными командами могут обращаться к одним и тем же данным, не забывая о необходимости сохранять исходные «сырые» данны в Amazon S3, служащий эталонным источником достоверных данных. Кроме того, использование хранилища признаков обработанных данных, такого как Amazon SageMaker Feature Store, помогает отчертить границу ответственности между командами ML специалистов и инженеров данных, и дает дополнительные преимущества, такие как обнаружение функций, обновление, пере-использование и возможность их распространения.
В качестве альтернативы «классическому» озеру данных, команды могут строить свою архитектуру поверх архитектуры Lake House, который является эволюцией концепции озер данных. Имеющая встроенную поддержку ACID транзакций, эта архитектура позволяет разным пользователям параллельно вставлять, удалять, обновлять строки в разных таблицах; и в то же самое время позволяет другим пользователям запускать аналитические запросы и ML модели на тех же данных. AWS Lake Formation недавно добавил функционал для поддержки Lake House архитектуры (сейчас в рамках предварительного ознакомления).
Теперь, когда мы развязали гордиев узел и придумали, как дать командам инженеров данных и ML специалистов возможность использовать их инструменты работы с данными, без создания конфликтов, давайте исследуем варианты обработки данных для ML задач в AWS.
Обзор способов обработки данных
В этой статье мы рассмотрим следующие способы, отсортированные по их рейтингу, определённому формулой: (удобство использования для инженеров данных и ML специалистов) x (полезность для ML-задач).
- Инструменты Amazon SageMaker
- Решения с небольшим количеством кода (или вообще без необходимости что-либо программировать) на базе других AWS сервисов
- Spark в Amazon EMR
- Самостоятельно запущенное рабочее окружение с Spark, Python или R
Данные варианты не является взаимоисключающими, вы можете использовать их в различных комбинациях, для обеспечения рабочих процессов, предпочтительных для команды. Например, некоторые команды склоняются к максимизации использования решений на основе SQL запросов, другие могут использовать Spark для некоторых задач в дополнение к Pandas (фреймворк на основе Python). Еще одним аспектом, который нужно учитывать, является то, что некоторые сервисы имеют встроенные возможности по визуализации данных, в то время, как другие – требуют дополнительных сервисов. Давайте обсудим эти нюансы каждого из вариантов.
Инструменты Amazon SageMaker
SageMaker — это полностью управляемый сервис, который позволяет разработчикам и специалистам по работе с данными создавать, обучать и быстро развёртывать модели машинного обучения, используя широкий спектр инструментов, специально созданных для задач машинного обучения. Также эти возможности включают в себя функционал подготовки и обработки данных – вы можете использовать Amazon SageMaker Data Wrangler или Amazon SageMaker Processing для обработки, и Amazon SageMaker Studio или SageMaker notebook instances для визуализации данных. Вы можете обрабатывать наборы данных объемом вплоть до петабайтов с помощью SageMaker.
SageMaker Data Wrangler – это функционал SageMaker, которым вы можете воспользоваться в SageMaker Studio. Он упрощает работу инженеров данных и ML инженеров по подготовке и группировке данных для ML задач, предоставляя визуальный интерфейс для ускорения очистки, исследования и визуализации данных. Интерфейс позволяет легко подключаться к различным источникам данных, таких как Amazon S3, и применять встроенные или пользовательские трансформации, написанные в PySpark, Pandas или SQL. SageMaker Data Wrangler удобно интегрирован с другими инструментами SageMaker, такими как SageMaker Clarify (для обнаружения предвзятости в данных), SageMaker Feature Store (упомянуто выше) и SageMaker Pipelines (специально созданный CI / CD для машинного обучения). Еще вы можете экспортировать процесс подготовки данных, созданный в Data Wrangler, в виде Python кода.
В то время как SageMaker Data Wrangler – это интерактивный инструмент для визуальной подготовки и исследования данных, SageMaker Processing позволяет запускать уже созданные задачи по предварительной обработке данных, а также постобработке и оценке ML моделей в полностью управляемой инфраструктуре. Этот инструмент предоставляет преднастроенные контейнеры для Spark и Scikit-learn, и позволяет подключить ваши собственные контейнеры, например для языка R. В отличие от SageMaker Data Wrangler, если вы используете только SageMaker Processing, вам потребуется отдельный инструмент для визуализации. Можно использовать любую рабочую среду, например Amazon SageMaker Studio или отдельные SageMaker ноутбуки. SageMaker Processing может подойти для миграции существующих скриптов обработки данных на SageMaker «as is», без переделывания.
Мы поставили использование инструментов SageMaker на первое место нашего рейтинга из-за простоты использования и удобности для инженеров данных и ML инженеров. Эти инструменты специально разработаны с нуля для задач машинного обучения. Кроме того, SageMaker Data Wrangler и ресурсы SageMaker Processing включены в Amazon SageMaker Savings Plans – гибкую модель ценообразования SageMaker, которая может предоставлять существенные скидки при условии постоянного уровня использования ресурсов SageMaker (измеряемого в долларах в час) в течение одного или трех лет.
Кроме SageMaker, существуют и другие варианты инструментов – они могут оказаться полезными, даже если не были специально созданы для задач машинного обучения. Давайте рассмотрим эти варианты.
Подход с малым количеством кода или без необходимости программировать (“low code” / “no code”)
Давайте проясним терминологию. Мы будем считать решение, которое требует написания SQL запросов – решением с малым количеством кода («low code»), а если вообще ничего писать не надо, даже SQL – «no code».
В рамках этого подхода мы рассмотрим несколько бессерверных инструментов – их инфраструктура и управление ею скрыто от пользователя. Использование таких инструментов может быстро выдать результаты, но в какой-то мере усложнить построение процесса обработки данных в целом – нужно будет переключаться между разными сервисами, UI и утилитами, потеряв некоторые продвинутые возможности по настройке.
Одним из примеров «low code» решения может быть совместное использование Amazon Athena (интерактивный сервис запросов) для преобразования данных SQL запросами, и Amazon QuickSight (бессерверный инструмент бизнес-аналитики), в котором есть готовый набор встроенных визуализаций, не требующих программирования. При рассмотрении этой комбинации сервисов оцените, могут ли преобразования данных быть в принципе реализованы на SQL. Альтернативой QuickSight для визуализации может быть библиотека PyAthena для запуска SQL запросов в ноутбуках SageMaker, и декларативная библиотека визуализации, например Altair (получается решение «low code+», поскольку для этой библиотеки нужно написать немного простого кода).
Другим «low code» решением может выступить AWS Glue, бессерверный ETL сервис с возможностью каталогизации ваших данных, имеющий встроенные шаблоны преобразования данных, и возможности по написанию пользовательского кода на PySpark. Для визуализации, помимо QuickSight, вы можете подключить SageMaker или Zeppelin ноутбуки к AWS Glue development endpoint. Если встроенные в AWS Glue преобразования данных не покрывают ваши требования, выбор между AWS Glue и Athena зависит от предпочтений команды – на чём им будет удобнее описывать преобразования – на SQL или в коде PySpark .
«No code» подход предлагается инструментом AWS Glue DataBrew. Это визуальная среда, в которой можно подготавливать, нормализовать и преобразовывать данные без необходимости написания кода. Вы можете выбрать любые из более чем 250 готовых преобразований, которые выполняют различные этапы подготовки данных, например фильтруют аномальные данные, конвертируют их в стандартные форматы, и исправляют неверные значения.
В таблице мы произвели сравнение DataBrew и SageMaker Data Wrangler:
Glue DataBrew | SageMaker Data Wrangler | |
Встроенные визуализации | да | да |
Поддержка пользовательского кода | нет | да |
Встроенные преобразования данных | да (более 250) | да (более 300) |
Вычислительные мощности | бессерверные | m5 инстанс (масштабирование вверх, но не по горизонтали) |
Лимиты для наборов данных | Профилирование данных только для первых 20т строк | Максимум 100 колонок |
Прямая интеграция с SageMaker | нет | да (Clarify, Feature Store, Pipelines) |
Spark в Amazon EMR
Многие компании используют Spark для разных задач, например – для преобразования данных или в качестве основы для построения хранилища данных. В таких сценариях кластеры Spark обычно запускаются в Amazon EMR (управляемый сервис для кластеров экосистемы Hadoop), что избавляет вас от необходимости поднимать, настраивать и обслуживать эти кластеры. С точки зрения инженера данных или ML инженера, Spark в Amazon EMR может быть использован в следующих случаях:
- Spark уже используется в постоянно работающем кластере, для построения хранилищ данных или другого применения. По сравнения с другими опциями, описанными ранее, которые создают только временные ресурсы и инфраструктуру, Amazon EMR позволяет создавать постоянные кластеры для использования в аналитических приложениях.
- Команда уже построила законченный пайплайн обработки в Spark, имеет опыт его администрирование, и готова продолжать использовать постоянно работающий Spark кластер в будущем. Иначе, варианты с SageMaker или AWS Glue для Spark задач будут более предпочтительны.
Также следует обратить внимание на широкий выбор типов инстансов, доступных в Amazon EMR, в том числе инстансов с процессорами AWS Graviton2, а также Amazon EC2 Spot Instances для оптимизации затрат.
Для визуализации в сценариях с Amazon EMR есть несколько опций. Чтобы продолжать использовать SageMaker как основной инструмент для процесса машинного обучения, используйте SageMaker Studio и её встроенный SparkMagic kernel для подключения к Amazon EMR. Вы можете начать запрашивать данные, анализировать и преобразовывать их с помощью Spark за несколько шагов. Для повышения безопасности можно подключаться к кластерам EMR с помощью аутентификации Kerberos. Amazon EMR предлагает и другие варианты интеграции с SageMaker, например, вы можете запустить задачу по тренировке ML модели в SageMaker прямо из Spark задачи в Amazon EMR. Еще один вариант для визуализации – использовать среду разработки Amazon EMR Studio, которая обеспечивает доступ к полностью управляемым Jupyter ноутбукам, и включает возможность логина через AWS Single Sign-On (AWS SSO). В то же время, EMR Studio не хватает многих специфичных UI-интеграций с SageMaker, которые есть в SageMaker Studio.
Есть и другие факторы, которые нужно учесть при рассмотрении Spark в EMR как способа обработки данных. Spark основан на Scala/Java стеке, со всеми особенностями управления зависимостями, и нюансами работы JVM, которые могут быть неизвестны инженерам данных. Также имейте ввиду, что PySpark API часто отстаёт от основного Spark API на Scala – языке программирования, который менее известен инженерам данных. Если вы предпочитаете альтернативный PandasAPI-совместимый фреймворк Dask для ваших задач, вы можете установить Dask на ваши EMR кластеры.
Самостоятельно запущенное рабочее окружение на базе Spark, Python или R
Если выбрать этот способ, командам нужно будет развернуть свои решения, запустив Spark, Dask или код на R на самостоятельно поднятном кластере. Такой кластер можно запустить на базе вычислительных ресурсов Amazon Elastic Compute Cloud (Amazon EC2), или контейнерных сервисов: Amazon Elastic Container Service (Amazon ECS) или Amazon Elastic Kubernetes Service (Amazon EKS). Наиболее простой способ добавить интеграцию с SageMaker — использовать Amazon SageMaker Python SDK. Любой EC2 инстанс, для которого в AWS Identity and Access Management (IAM) заданы разрешения доступа к сервису SageMaker, может использовать SageMaker Python SDK для запуска процессов SageMaker для создания, тренировки, тюнинга, развёртывания моделей, и многого другого.
Этот вариант обеспечивает наибольшую гибкость комбинирования различных утилит и фреймворков для преобразования данных, а также предлагает доступ к широму спектру EC2 инстансов и вариантам хранения данных. Помимо возможности использования спот-инстансов, как и в Amazon EMR, вы также можете воспользоваться гибкими ценовыми тарифами, предлагаемыми в рамках AWS Savings Plans. Эти тарифы могут быть применены не только к ресурсам Amazon EC2, но также и к бессерверным мощностям в рамках AWS Lambda и AWS Fargate .
Но имейте ввиду – если рассмотреть вариант «сделай всё сам» с точки зрения пользовательского опыта инженеров данных и ML специалистов, окажется, что он требует от этих команд управления низкоуровневой инфраструктурой. Эта задача более подходит для других специлистов. Хотя существует множество фреймворков (типа Spark) и утилит, которые могут быть надстроены поверх базовой инфраструктуры, для упрощения управления ресурсами и поддержки ML задач, этот вариант всё ещё очень далек с точки зрения простоты, управляемости и общей адаптированности под специальные требования ML, по сравнению с другими вариантами, рассмотренными выше. Больше времени ваших сотрудников уйдет на управление, настройку и поддержку инфраструктуры и её зависимостей, и на написание кода для покрытия недостающего функционала. В результате этот вариант может оказаться наиболее дорогим в долгосрочной перспективе.
Обзор и заключение
Итоговый выбор варианта обработки данных для задач машинного обучения обычно зависит от предпочтений вашей команды – какие инструменты она предпочитает (Spark, SQL или Python), и насколько она готова писать код и управлять инфраструктурой. В следующей таблице приведены особенности каждого из вариантов по нескольким ключевым параметрам. В первом столбце подчеркивается, что отдельные сервисы или функционал могут использоваться и для обработки данных, и для их визуализации, а третий столбец показывает, какие типы вычислительных ресуров используются скорее для обработки данных, чем для визуализации (визуализация обычно требует гораздо меньшего количества ресурсов).
Задачи обработки данных развиваются со временем, и вам не нужно все время продолжать использовать один и тот же набор инструментов. Вы можете сочетать инструменты в соответствии с вашими задачами. Когда вы используете Amazon S3 как ядро озера данных, и управляемый сервис SageMaker для основных этапов машинного обучения – вы можете легко заменять инструменты по мере необходимости или по желанию, чтобы быть на пике новейших технологий. Какой бы вариант вы ни выбрали сейчас, AWS поможет гибко развивать ваш инструментарий, чтобы он наилучшим образом соответствовал текущим потребностям в обработке данных ваших ML задач.