Проаналізуйте витрати Amazon SageMaker і визначте можливості оптимізації витрат на основі використання, частина 3: Обробка та вакансії Data Wrangler

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

читають: 0

У 2021 році ми запустили AWS Support Proactive Services як частина Підтримка AWS Enterprise планувати. З моменту його появи ми допомогли сотням клієнтів оптимізувати їхні робочі навантаження, встановити захисні огородження та покращити видимість витрат і використання робочих навантажень машинного навчання (ML).

У цій серії публікацій ми ділимося уроками щодо оптимізації витрат у Amazon SageMaker. У цій публікації ми зосередимося на попередній обробці даних за допомогою Обробка Amazon SageMaker та Amazon SageMaker Data Wrangler робочих місць.

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

Крім того, окрім звичайних завдань вилучення, трансформації та завантаження (ETL), командам ML іноді потрібні більш розширені можливості, як-от створення швидких моделей для оцінки даних і отримання показників важливості функцій або оцінювання моделі після навчання в рамках конвеєра 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 Cost Explorer щоб визначити можливості оптимізації витрат у 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 (Amazon S3), Амазонка Афіна та Амазонська червона зміна. Для отримання додаткової інформації див Обробка S3Input, AthenaDatasetDefinition та RedshiftDatasetDefinition, відповідно.

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

Щоб краще зрозуміти продуктивність обробки та виявити можливості оптимізації, ми рекомендуємо наступне найкращі практики журналювання у вашому сценарії обробки. SageMaker публікує ваші журнали обробки на Amazon CloudWatch.

У наступному прикладі журналу завдань ми бачимо, що обробка сценарію тривала 15 хвилин (між Start custom script та End custom script).

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

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

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

Як згадувалося раніше, 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. Ви можете змінити розмір екземпляра, перейшовши до іншої версії в межах того самого сімейства екземплярів або перейшовши до іншого сімейства екземплярів. Під час міграції в рамках одного сімейства екземплярів потрібно враховувати лише ЦП/ГП та пам’ять. Щоб отримати додаткову інформацію та загальні вказівки щодо вибору правильних ресурсів обробки, див Забезпечте ефективні обчислювальні ресурси на 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

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

Щоб отримати вказівки щодо оптимізації програми Data Wrangler у Studio, зверніться до частини 2 цієї серії.

У цьому розділі ми зосередимося на оптимізації завдань 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 вартість екземпляра. Зверніть увагу, що це приблизні дані, і розподілена обробка може спричинити певні витрати, які вплинуть на загальний час виконання.

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

Ще одна переконлива функція Data Wrangler — це можливість встановити планове завдання. Якщо ви періодично обробляєте дані, ви можете створити розклад для автоматичного виконання завдання обробки. Наприклад, ви можете створити розклад, який автоматично запускає завдання обробки, коли ви отримуєте нові дані (приклади див Експорт до Amazon S3 or Експортуйте в Amazon SageMaker Feature Store). Однак слід зауважити, що коли ви створюєте розклад, Data Wrangler створює eventRule в EventBridge. Це означає, що з вас також стягується плата за правила подій, які ви створюєте (а також екземпляри, які використовуються для виконання завдання обробки). Для отримання додаткової інформації див Ціни Amazon EventBridge.

Висновок

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

даних за допомогою завдань SageMaker Processing і Data Wrangler. Подібно до попередньої обробки, існує багато параметрів і параметрів конфігурації під час створення, навчання та запуску моделей ML, які можуть призвести до непотрібних витрат. Тому, оскільки машинне навчання стає потужним інструментом у різних галузях, робочі навантаження ММ повинні залишатися економічно ефективними.

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

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

Про авторів

Проаналізуйте витрати Amazon SageMaker і визначте можливості оптимізації витрат на основі використання, Частина 3: Обробка та вакансії Data Wrangler | Amazon Web Services PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai. Діпалі Раджале є старшим спеціалістом зі штучного інтелекту та ML в AWS. Вона працює з корпоративними клієнтами, надаючи технічне керівництво з найкращими практиками для розгортання та підтримки рішень AI/ML в екосистемі AWS. Вона працювала з багатьма організаціями над різними сценаріями використання глибокого навчання, пов’язаними з НЛП та комп’ютерним зором. Вона захоплена розширенням можливостей організацій використовувати генеративний штучний інтелект для покращення досвіду використання. У вільний час вона захоплюється кіно, музикою та літературою.

Урі Розенберг є технічним менеджером зі штучного інтелекту та машинного навчання для Європи, Близького Сходу та Африки. Урі, що базується в Ізраїлі, працює над розширенням можливостей корпоративних клієнтів у всьому, що стосується машинного навчання, щоб проектувати, створювати та працювати в масштабі. У вільний час любить їздити на велосипеді, піти в походи та спостерігати захід сонця (мінімум раз на день).