анализ расходов Amazon SageMaker и определение возможностей оптимизации затрат на основе использования, часть 3: работа по обработке и обработке данных

Переиздано Платоном

Читают: 0

В 2021 году мы запустили Проактивные сервисы поддержки AWS в качестве части Поддержка предприятий AWS план. С момента его появления мы помогли сотням клиентов оптимизировать их рабочие нагрузки, установить ограничения и улучшить видимость затрат и использования их рабочих нагрузок машинного обучения (ML).

В этой серии сообщений мы делимся извлеченными уроками об оптимизации затрат в Создатель мудреца Амазонки. В этом посте мы сосредоточимся на предварительной обработке данных с использованием Обработка Amazon SageMaker и Обработчик данных Amazon SageMaker рабочие места.

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

Кроме того, в дополнение к обычным задачам извлечения, преобразования и загрузки (ETL), командам машинного обучения иногда требуются более продвинутые возможности, такие как создание быстрых моделей для оценки данных и получения оценок важности функций или оценки модели после обучения в рамках конвейера MLOps.

SageMaker предлагает две функции, специально разработанные для решения этих проблем: SageMaker Processing и Data Wrangler. SageMaker Processing позволяет легко выполнять предварительную обработку, постобработку и оценку модели в полностью управляемой инфраструктуре. Data Wrangler сокращает время, необходимое для агрегирования и подготовки данных, упрощая процесс интеграции источников данных и разработки функций с помощью единого визуального интерфейса и полностью распределенной среды обработки данных.

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

В этом посте мы проанализируем факторы ценообразования и предоставим рекомендации по оптимизации затрат для заданий SageMaker Processing и Data Wrangler.

Обработка SageMaker

SageMaker Processing — это управляемое решение для выполнения рабочих нагрузок обработки данных и оценки моделей. Вы можете использовать его на этапах обработки данных, таких как разработка функций, проверка данных, оценка модели и интерпретация модели в рабочих процессах ML. С помощью SageMaker Processing вы можете создавать свои собственные сценарии обработки и создавать собственный контейнер или использовать контейнер, управляемый SageMaker, с такими распространенными платформами, как scikit-learn, Lime, Spark и другими.

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

Вы можете отфильтровать затраты на обработку, применив фильтр к типу использования. Названия этих типов использования следующие:

REGION-Processing:instanceType (например, USE1-Processing:ml.m5.large)
REGION-Processing:VolumeUsage.gp2 (например, USE1-Processing:VolumeUsage.gp2)

Чтобы просмотреть стоимость обработки SageMaker в Cost Explorer, начните с фильтрации с помощью SageMaker для Сервис, А для Тип использования, вы можете выбрать все часы работы экземпляров обработки, введя processing:ml префикс и выбор списка в меню.

Избегайте затрат на обработку и разработку конвейера

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

Во-первых, вы можете получить доступ к Обработка на консоли SageMaker.

Кроме того, вы можете использовать API list_processing_jobs.

Статус задания обработки может быть InProgress, Completed, Failed, Stoppingили Stopped.

При разработке новых конвейеров MLOps часто встречается большое количество неудачных заданий. Однако вы всегда должны тестировать и прилагать все усилия для проверки заданий перед их запуском в SageMaker, поскольку за используемые ресурсы взимается плата. Для этой цели вы можете использовать SageMaker Processing в локальный режим. Локальный режим — это функция SageMaker SDK, позволяющая создавать средства оценки, процессоры и конвейеры и развертывать их в локальной среде разработки. Это отличный способ протестировать сценарии перед их запуском в среде, управляемой SageMaker. Локальный режим поддерживается как управляемыми контейнерами SageMaker, так и теми, которые вы предоставляете сами. Чтобы узнать больше о том, как использовать локальный режим с Конвейеры Amazon SageMaker, Ссылаться на Локальный режим.

Оптимизация затрат, связанных с вводом-выводом

Задания SageMaker Processing предлагают доступ к трем источникам данных в рамках управляемого ввод обработки: Простой сервис хранения Amazon (Амазон С3), Амазонка Афинаи Амазонка Redshift. Для получения дополнительной информации см. ОбработкаS3Input, AthenaDatasetОпределениеи Определение RedshiftDatasetDefinition, Соответственно.

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

Чтобы лучше понять производительность обработки и определить возможности оптимизации, мы рекомендуем следующее: лучшие практики ведения журнала в вашем сценарии обработки. SageMaker публикует журналы обработки в Amazon CloudWatch.

В следующем примере журнала заданий мы видим, что обработка скрипта заняла 15 минут (между Start custom script и End custom script).

Однако на консоли SageMaker мы видим, что задание заняло 4 дополнительные минуты (почти 25% от общего времени выполнения задания).

Это связано с тем, что в дополнение к тому времени, которое занял наш скрипт обработки, загрузка и выгрузка данных, управляемых SageMaker, также заняла время (4 минуты). Если это окажется значительной частью затрат, рассмотрите альтернативные способы ускорения загрузки, такие как использование Boto3 API с многопроцессорной обработкой для одновременной загрузки файлов или использование сторонних библиотек, таких как WebDataset или s5cmd, для более быстрой загрузки с Amazon S3. . Для получения дополнительной информации см. Распараллеливание рабочих нагрузок S3 с помощью s5cmd. Обратите внимание, что такие методы могут привести к взиманию платы в Amazon S3 из-за передача данных.

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

Как упоминалось ранее, SageMaker Processing также поддерживает Athena и Amazon Redshift в качестве источников данных. При настройке задания обработки с этими источниками SageMaker автоматически копирует данные в Amazon S3, а экземпляр обработки извлекает данные из местоположения Amazon S3. Однако по завершении задания процесс управляемой очистки не выполняется, а скопированные данные по-прежнему остаются в Amazon S3, и за их хранение может взиматься дополнительная плата. Поэтому при использовании источников данных Athena и Amazon Redshift обязательно реализуйте процедуру очистки, например функцию Lambda, которая работает по расписанию или в Лямбда-шаг как часть конвейера SageMaker.

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

Экземпляры заданий обработки нужного размера

Выбор правильного типа и размера экземпляра является основным фактором оптимизации стоимости заданий SageMaker Processing. Вы можете изменить размер экземпляра, перейдя на другую версию в том же семействе экземпляров или перейдя в другое семейство экземпляров. При миграции в рамках одного семейства экземпляров вам нужно учитывать только CPU/GPU и память. Для получения дополнительной информации и общих рекомендаций по выбору правильных ресурсов обработки см. Обеспечение эффективных вычислительных ресурсов в Amazon SageMaker.

Чтобы точно настроить выбор экземпляра, мы начинаем с анализа показателей задания обработки в CloudWatch. Для получения дополнительной информации см. Мониторинг Amazon SageMaker с помощью Amazon CloudWatch.

CloudWatch собирает необработанные данные из SageMaker и преобразует их в удобочитаемые показатели практически в реальном времени. Хотя эта статистика хранится в течение 15 месяцев, консоль CloudWatch ограничивает поиск метриками, которые были обновлены за последние 2 недели (это гарантирует отображение только текущих вакансий). Метрики заданий обработки можно найти в пространстве имен /aws/sagemaker/ProcessingJobs, а собранные метрики CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationи DiskUtilization.

На следующем снимке экрана показан пример задания обработки в CloudWatch, которое мы видели ранее.

В этом примере мы видим усредненные значения ЦП и памяти (это значение по умолчанию в CloudWatch): среднее использование ЦП составляет 0.04%, памяти 1.84% и использование диска 13.7%. Для правильного размера всегда учитывайте максимальное использование ЦП и памяти (в этом примере максимальное использование ЦП составляло 98% в первые 3 минуты). Как правило, если максимальное использование ЦП и памяти постоянно меньше 40%, вы можете безопасно разрезать машину пополам. Например, если вы использовали инстанс ml.c5.4xlarge, вы можете перейти на ml.c5.2xlarge, что сократит ваши затраты на 50 %.

Вакансии обработчика данных

Data Wrangler - это функция Студия Amazon SageMaker которое обеспечивает воспроизводимое и масштабируемое решение для исследования и обработки данных. Вы используете интерфейс Data Wrangler для интерактивного импорта, анализа, преобразования и придания характеристик своим данным. Эти шаги записываются в рецепт (файл .flow), который затем можно использовать в задании Data Wrangler. Это помогает вам повторно применять одни и те же преобразования данных к вашим данным, а также масштабировать их до распределенного задания пакетной обработки данных либо как часть конвейера машинного обучения, либо независимо.

Руководство по оптимизации приложения Data Wrangler в Studio см. во второй части этой серии.

В этом разделе мы сосредоточимся на оптимизации заданий Data Wrangler.

Data Wrangler использует SageMaker Spark обрабатывает задания с контейнером, управляемым Data Wrangler. Этот контейнер выполняет указания из файла .flow в задании. Как и в случае любых заданий обработки, Data Wrangler взимает плату за выбранные вами экземпляры в зависимости от продолжительности использования и предоставленного хранилища, подключенного к этому экземпляру.

В Cost Explorer вы можете отфильтровать стоимость заданий Data Wrangler, применив фильтр к типу использования. Названия этих типов использования:

REGION-processing_DW:instanceType (например, USE1-processing_DW:ml.m5.large)
REGION-processing_DW:VolumeUsage.gp2 (например, USE1-processing_DW:VolumeUsage.gp2)

Чтобы просмотреть стоимость Data Wrangler в Cost Explorer, отфильтруйте сервис для использования SageMaker, а для Тип использования, выбрать processing_DW префикс и выберите список в меню. Это покажет вам расходы, связанные как с использованием инстанса (в часах), так и с объемом хранилища (ГБ). (Если вы хотите увидеть затраты Studio Data Wrangler, вы можете отфильтровать тип использования по Studio_DW префикс.)

Правильный размер и расписание экземпляров заданий Data Wrangler

На данный момент Data Wrangler поддерживает только экземпляры m5 со следующими размерами экземпляров: ml.m5.4xlarge, ml.m5.12xlarge и ml.m5.24xlarge. Вы можете использовать функцию распределенной работы, чтобы точно настроить стоимость работы. Например, предположим, что вам нужно обработать набор данных, для которого требуется 350 ГиБ оперативной памяти. 4xlarge (128 ГиБ) и 12xlarge (256 ГиБ) могут не обрабатываться, и вам придется использовать экземпляр m5.24xlarge (768 ГиБ). Однако вы можете использовать два инстанса m5.12xlarge (2 * 256 ГиБ = 512 ГиБ) и снизить стоимость на 40 % или три инстанса m5.4xlarge (3 * 128 ГиБ = 384 ГиБ) и сэкономить 50 % ресурсов m5.24xlarge. стоимость экземпляра. Следует отметить, что это приблизительные значения, и что распределенная обработка может привести к некоторым накладным расходам, которые повлияют на общее время выполнения.

При изменении типа экземпляра обязательно обновите Конфигурация искры соответственно. Например, если у вас есть начальное задание экземпляра ml.m5.4xlarge, настроенное со свойствами spark.driver.memory установить на 2048 и spark.executor.memory установить на 55742, а затем масштабировать до ml.m5.12xlarge, эти значения конфигурации необходимо увеличить, иначе они станут узким местом в задании обработки. Вы можете обновить эти переменные в графическом интерфейсе Data Wrangler или в файле конфигурации, добавленном к пути конфигурации (см. следующие примеры).

Еще одна интересная особенность Data Wrangler — возможность установить запланированное задание. Если вы периодически обрабатываете данные, вы можете создать расписание для автоматического запуска задания обработки. Например, вы можете создать расписание, которое автоматически запускает задание обработки при получении новых данных (например, см. Экспорт в Amazon S3 or Экспорт в магазин функций Amazon SageMaker). Однако следует помнить, что при создании расписания Data Wrangler создает eventRule в EventBridge. Это означает, что с вас также будет взиматься плата за созданные вами правила событий (а также за экземпляры, используемые для запуска задания обработки). Для получения дополнительной информации см. Цены на Amazon EventBridge.

Заключение

В этом посте мы предоставили рекомендации по анализу затрат и передовым методам предварительной обработки.

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

SageMaker предлагает широкий и глубокий набор функций для облегчения каждого шага конвейера машинного обучения.

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

Об авторах

Анализ расходов на Amazon SageMaker и определение возможностей оптимизации затрат на основе использования. Часть 3. Задания по обработке и обработке данных | Веб-сервисы Amazon PlatoBlockchain Data Intelligence. Вертикальный поиск. Ай. Дипали Раджале является старшим специалистом по AI/ML в AWS. Она работает с корпоративными клиентами, предоставляя технические рекомендации с рекомендациями по развертыванию и обслуживанию решений AI/ML в экосистеме AWS. Она работала с широким кругом организаций над различными вариантами использования глубокого обучения, включающими НЛП и компьютерное зрение. Она увлечена тем, чтобы дать организациям возможность использовать генеративный ИИ для улучшения их опыта использования. В свободное время любит кино, музыку и литературу.

Ури Розенберг является техническим менеджером специалиста по искусственному интеллекту и машинному обучению в Европе, на Ближнем Востоке и в Африке. Находясь в Израиле, Ури работает над тем, чтобы предоставить корпоративным клиентам все, что связано с машинным обучением, для проектирования, создания и эксплуатации в масштабе. В свободное время любит кататься на велосипеде, ходить в походы и наблюдать за закатами (минимум раз в день).