Архитектурные уроки, извлеченные из исследований данных

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

Масштабная оптимизация затрат на вычисления для машинного обучения

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

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

Эталонный конвейер машинного обучения

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

· Этап 1. Создание образца набора данных из источников данных

· Этап 2. Выбор объектов с использованием образца данных

· Этап 3. Создание набора данных для обучения с выбранными функциями

· Этап 4. Обучение модели машинного обучения на обучающем наборе данных

· Этап 5. Создание набора данных юниверса для оценки

· Этап 6. Набор данных юниверса оценок

Масштабируемая реализация конвейера машинного обучения

В эталонной реализации конвейер машинного обучения масштабируется для обработки больших наборов данных с использованием комбинации традиционных методов науки о данных и масштабируемых архитектур. Горизонтально масштабируемые архитектуры оказались лучше, чем вертикальные, поскольку они предлагают более высокую гибкость, отказоустойчивость и почти неограниченное масштабирование. Конвейер использует Apache Spark в качестве горизонтально масштабируемого распределенного механизма обработки данных для масштабирования всех этапов машинного обучения. Статистически адекватная выборка оказалась проверенным методом уменьшения размера больших данных. На этапах подготовки данных собираются репрезентативные образцы для выбора признаков. Этапы обучения и оценки конвейера масштабируются с использованием распределенного XGBoost в качестве модели.

Сквозной конвейер создается, запускается и управляется с помощью корпоративной платформы Data Science, реализованной с помощью IBM Cloud Pak for Data. Cloud Pak for Data предлагает гибкие варианты развертывания для локальной или любой облачной платформы. Конвейер выполняется как серия запланированных заданий, управляющих обработкой на внешних кластерах Spark. Архитектурный выбор использования внешних вычислительных кластеров для Spark может обеспечить огромную гибкость для управления масштабированием с возможностью оптимизации затрат.

Оптимизация экономики Spark Computing

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

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

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

Динамическое выделение кластеров Spark с автоматическим масштабированием

Первым естественным шагом по снижению затрат является динамическое выделение кластеров Spark, включение автомасштабирования и завершение работы кластера по завершении задания. Облачные платформы позволяют программно инициализировать и завершить кластеры Spark с поддержкой Python SDK и API. Они также интегрируют автоматическое выделение ресурсов и немедленное завершение кластера в задания конвейера машинного обучения, чтобы минимизировать затраты на простой. Автоматическое динамическое выделение ресурсов гарантирует, что затраты основаны на использовании / потреблении.

Размер узлов кластера в соответствии с потребностями в ресурсах для Spark Job

Вычислительные ресурсы определяют емкость ЦП, памяти и ввода-вывода. Как правило, все задания Spark конвейера машинного обучения не идентичны по потребностям в ресурсах. Некоторые задания требуют интенсивного использования памяти, а другие - ЦП или операций ввода-вывода. Серия тестовых запусков поможет профилировать потребности в ресурсах заданий Spark на каждом этапе машинного обучения. Оптимизируйте вычислительные затраты, подготовив кластер, который точно соответствует требованиям к ресурсам на каждом этапе. В эталонном конвейере машинного обучения этапы 1, 3 и 5 связаны с памятью больше, чем с ЦП, в отличие от других этапов. Автоматизация этапов машинного обучения с использованием кластеров подходящего размера может обеспечить экономию средств.

Используйте дешевые временные вычислительные узлы для кластера Spark

Облачные платформы предлагают временные вычислительные узлы, такие как спотовые экземпляры EC2 на AWS или временные узлы в IBM Cloud. Переходные узлы предоставляются по привлекательной цене, обычно со значительными скидками в 60% или более, чтобы стимулировать использование избыточной емкости, доступной в облаке. Эти вычислительные узлы дают возможность значительно сократить эксплуатационные расходы для вычислений Spark.

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

Создавайте задания Spark для повышения отказоустойчивости

Spark повторно запускает задачи, назначенные потерянным исполнителям, на восстановленных переходных узлах. Для длительных заданий это приводит к ситуации «все или ничего». Каждый этап машинного обучения в эталонном конвейере реализует обработку с использованием одного сеанса Spark. Неудачное задание Spark требует повторного выполнения всех вычислений этапа машинного обучения. Разбивая каждый этап на цепочку гораздо меньших заданий Spark, мы повышаем уровень отказоустойчивости. Параллельно мы настраиваем повторные попытки Spark до того, как он завершит работу. Благодаря высоконадежным заданиям Spark мы можем добиться экономии на переходных узлах для большинства рабочих нагрузок.

Эффективное управление заданиями Spark в общем кластере

Выполнение заданий Spark в общих кластерах оптимизирует расходы. Каждая реализация Spark использует диспетчер ресурсов для управления заданиями в кластере, например, Spark в Hadoop использует YARN, а Spark в Mesos использует Mesos в качестве диспетчера ресурсов. Возможности управления рабочей нагрузкой различаются в зависимости от каждого менеджера ресурсов.

IBM Spectrum Conductor (часть WML Accelerator) использует EGO (Enterprise Grid Orchestrator) в качестве диспетчера ресурсов для управления рабочими нагрузками Spark, Deep Learning и Mongo на кластерах HPC. Conductor предлагает лучшее управление рабочими нагрузками с поддержкой сложных политик для совместного использования ресурсов, управления параллельными рабочими нагрузками с приоритетными группами и передачи любому облачному провайдеру для динамической вычислительной мощности. Вот эталонный конвейер машинного обучения с заданиями Spark, направленными в кластер Conductor.

Conductor размещает несколько групп экземпляров Spark (SIG). Каждому SIG назначаются ресурсы кластера, оптимизированные для выполнения различных типов заданий Spark. Каждый этап конвейера машинного обучения отправляет задания Spark в SIG, оптимизированные для этого этапа. SIG использует возможность облачного всплеска для предоставления дешевых и временных вычислительных узлов от IBM, AWS или Azure. Уникальные возможности корпоративного класса в Conductor обеспечивают значительную экономию средств при выполнении рабочих нагрузок Spark в масштабах для локальных, облачных или гибридных облачных сред. Для эталонной рабочей нагрузки машинного обучения конфигурация Conductor обычно обеспечивает 40% -ную экономию затрат на вычисления при больших объемах.

Использование бессерверных вычислений для обработки Spark

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

В эталонном конвейере машинного обучения обработка данных по этапам в основном представляет собой сочетание операций SQL и машинного обучения. На этапах 1, 3 и 5 подготавливаются и преобразуются наборы данных с помощью операций Spark SQL. Этап 4 обучает, а этап 6 оценивает модель, управляющую операциями машинного обучения. И этапы 3 и 5 могут выполняться параллельно для оптимизации времени выполнения конвейера.

IBM Cloud предлагает бессерверную обработку SQL с помощью SQL Query Service по цене в несколько долларов за ТБ обработанных данных. Стоимость услуги зависит от объемов обрабатываемых данных. Для сравнения, кластер Spark среднего размера может стоить в несколько раз больше в час, при этом общая стоимость возрастает в зависимости от времени выполнения задания. Реализация этапов 1, 3, 5 конвейера для использования бессерверной обработки SQL в сочетании с параллельным выполнением этапов 3 и 5 может привести к сокращению времени выполнения и экономии затрат по сравнению с использованием подготовленных кластеров Spark. Вот реализация конвейера машинного обучения с этапами обработки SQL с использованием службы SQL Query и этапами обработки машинного обучения, нацеленными на кластер Spark.

Для эталонной рабочей нагрузки машинного обучения реализация SQL-запроса может снизить вычислительные затраты в 8-20 раз на всех трех этапах. В качестве руководящего принципа проектирование конвейеров машинного обучения для использования бессерверных вычислений для сквозной обработки поможет создать наиболее экономически эффективные решения.

Резюме

Apache Spark стал естественным выбором для масштабируемой обработки данных в конвейерах машинного обучения. Масштабирование рабочих нагрузок машинного обучения требует больших вычислительных затрат. Предприятия сталкиваются с ограничениями бюджета по сдерживанию затрат на вычисления Spark для масштабного выполнения рабочих нагрузок машинного обучения. Вычислительные кластеры подходящего размера с динамическим выделением ресурсов и значительной скидкой на переходные вычислительные узлы в облаке помогают оптимизировать затраты. Эффективные менеджеры ресурсов кластера, такие как IBM Spectrum Conductor, и службы бессерверных вычислений, такие как служба IBM SQL Query, помогают добиться максимальной экономии.