По мере масштабирования модели мы начали запускать распределенные задания обучения с большим количеством данных и работников, и все более распространенными становятся более сложные шаблоны распределенного обучения. Таким образом, мы обнаружили ряд проблем, связанных с распределенным машинным обучением и глубоким обучением в масштабе:

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

Apache Spark, Dask и Ray — три самых популярных фреймворка для распределенных вычислений.

Апач Спарк

Spark был запущен в 2009 году Матеем Захарией из AMPLab Калифорнийского университета в Беркли. Основной целью проекта было ускорение выполнения распределенных задач больших данных, которые на тот момент обрабатывались Hadoop MapReduce. MapReduce был разработан с учетом масштабируемости и надежности, но производительность или простота использования никогда не были его сильной стороной. Постоянная потребность MapReduce в сохранении промежуточных результатов на диск — ключевое препятствие, которое Spark стремится преодолеть. Внедрив парадигму Resilient Distributed Dataset (RDD) и воспользовавшись преимуществами кэширования в памяти и отложенных вычислений, Spark смог сократить задержку на несколько порядков по сравнению с MapReduce. Это позволило Spark установить свое господство в качестве стандарта де-факто для крупномасштабной отказоустойчивой параллельной обработки данных. В дальнейшем проект был дополнен такими дополнениями, как GraphX ​​(для распределенной обработки графов), MLlib (для машинного обучения), SparkSQL (для структурированных и полуструктурированных данных) и другими.
Стоит отметить, что Spark написан на Scala с поддержкой Python и R, добавленной позже, поэтому взаимодействие с ним обычно не похоже на Pythonic. Понимание парадигмы RDD и того, как все делается в Spark, требует некоторого времени, чтобы привыкнуть, но обычно это не проблема для тех, кто знаком с экосистемой Hadoop.

Даск

Dask — это библиотека с открытым исходным кодом для параллельных вычислений, выпущенная в 2015 году, поэтому она является относительно новой по сравнению со Spark. Этот фреймворк изначально был разработан в Continuum Analytics (теперь Anaconda Inc.), которая является создателем многих других пакетов Python с открытым исходным кодом, включая популярный дистрибутив Anaconda Python. Первоначальной целью Dask было просто распараллелить NumPy, чтобы он мог использовать преимущества компьютеров рабочих станций с несколькими процессорами и ядрами. В отличие от Spark, одним из первоначальных принципов дизайна, принятых при разработке Dask, было «ничего не изобретать». Идея этого решения заключается в том, что работа с Dask должна быть знакома разработчикам, использующим Python для анализа данных, а время разгона должно быть минимальным. По словам его создателей, принципы проектирования Dask развивались с годами, и сейчас он разрабатывается как универсальная библиотека для параллельных вычислений.

Первоначальная идея параллельного NumPy в дальнейшем расширилась до включения полноценного, но также легкого планировщика задач, который может отслеживать зависимости и поддерживать распараллеливание больших многомерных массивов и матриц. Позже была добавлена ​​​​дополнительная поддержка для параллельных Pandas DataFrames и scikit-learn. Это позволило фреймворку устранить некоторые основные проблемы в Scikit, такие как ресурсоемкий поиск по сетке и рабочие процессы, которые слишком велики, чтобы полностью поместиться в памяти. Первоначальная цель распараллеливания одной машины была позже превзойдена введением распределенного планировщика, который теперь позволяет Dask комфортно работать в проблемном пространстве с несколькими машинами и несколькими ТБ.

Рэй

Ray — еще один проект Калифорнийского университета в Беркли, целью которого является «упрощение распределенных вычислений». Ray состоит из двух основных компонентов — Ray Core, который представляет собой распределенную вычислительную среду, и Ray Ecosystem, которая, в широком смысле, представляет собой ряд специализированных библиотек, поставляемых вместе с Ray (например, Ray Tune — инфраструктура оптимизации гиперпараметров, RaySGD для распределенных вычислений). глубокое обучение, RayRLib для обучения с подкреплением и т. д.)

Ray похож на Dask тем, что позволяет пользователю запускать код Python параллельно и на нескольких машинах. Однако, в отличие от Dask, Ray не пытается имитировать API-интерфейсы NumPy и Pandas — его основная цель разработки заключалась не в том, чтобы заменить рабочие нагрузки Data Science, а в том, чтобы предоставить общую низкоуровневую структуру для распараллеливания кода Python. Это делает его более универсальной средой кластеризации и параллелизации, которую можно использовать для создания и запуска любых типов распределенных приложений. Из-за архитектуры Ray Core его часто считают основой для построения фреймворков. Также растет число проектов, которые интегрируются с Ray для использования ускоренного графического процессора и параллельных вычислений. spaCy, Hugging Face и XGBoost — все это примеры сторонних библиотек, которые представили интероперабельность Ray.

Правильный выбор фреймворка

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

Искра

Плюсы

  • Устоявшаяся и зрелая технология (первоначальный выпуск в мае 2014 г.).
  • Множество компаний, предоставляющих коммерческую поддержку/услуги.
  • Идеально подходит для задач типа Data Engineering / ETL для больших наборов данных.
  • Предоставляет абстракции SQL более высокого уровня (Spark SQL).

Минусы

  • Крутая кривая обучения, включающая новую модель выполнения и API.
  • Отладка может быть сложной.
  • Сложная архитектура, которую сложно поддерживать только ИТ-специалистам, поскольку надлежащее обслуживание требует понимания парадигм вычислений и внутренней работы Spark (например, распределения памяти).
  • Отсутствие богатой экосистемы визуализации данных.
  • Нет встроенного ускорения графического процессора. Требуется RAPIDS Accelerator для доступа к ресурсам GPU.

Даск

Плюсы

  • Фреймворк Pure Python — очень легко наращивать.
  • Готовая поддержка массивов Pandas DataFrames и NumPy.
  • Простой исследовательский анализ данных на основе миллиардов строк с помощью Datashader.
  • Предоставляет Dask Bags — Pythonic-версию PySpark RDD с такими функциями, как map, filter, группировать и т. д.
  • Dask может привести к впечатляющим улучшениям производительности. В июне 2020 года Nvidia сообщила о поразительных результатах тестов TPCx-BB с использованием RAPIDS, Dask и UCX на 16 системах DGX A100 (128 графических процессоров A100). Тем не менее, возьмите это с щепоткой соли. В январе 2021 года TPC вынудила Nvidia удалить результаты, поскольку они нарушают политику добросовестного использования TPC.

Минусы

  • Доступно не так много коммерческой поддержки (но несколько компаний начинают работать в этом пространстве, например, Coiled и QuanSight).
  • Нет встроенной поддержки графического процессора. Используется RAPIDS для ускорения графического процессора.

Рэй

Плюсы

  • Минимальная конфигурация кластера
  • Лучше всего подходит для рабочих нагрузок с большим объемом вычислений. Уже было показано, что Ray превосходит Spark и Dask в некоторых задачах машинного обучения, таких как NLP, нормализация текста и другие. В довершение всего, похоже, что Ray работает примерно на 10% быстрее, чем стандартная многопроцессорность Python, даже на одном узле.
  • Поскольку Ray все чаще используется для масштабирования различных библиотек машинного обучения, вы можете использовать их все вместе масштабируемым и распараллеленным образом. Spark, с другой стороны, ограничивает вас существенно меньшим количеством фреймворков, доступных в его экосистеме.
  • Уникальные абстракции на основе акторов, в которых несколько задач могут работать в одном кластере асинхронно, что приводит к лучшему использованию (в отличие от этого модель вычислений Spark менее гибкая, основанная на синхронном выполнении параллельных задач).
  • Минусы
  • Относительно новый (первоначальный выпуск в мае 2017 г.)
  • Не совсем приспособлен для распределенной обработки данных. Ray не имеет встроенных примитивов для секционированных данных. Проект только что представил Ray Datasets, но это совершенно новое дополнение, и оно все еще совершенно новое и голое.
  • Поддержка GPU ограничена планированием и резервированием. Фактически удаленная функция может использовать GPU (обычно через внешние библиотеки, такие как TensorFlow и PyTorch).

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

  • Если рабочие нагрузки ориентированы на данные и больше связаны с ETL/предварительной обработкой, нашим лучшим выбором будет Spark. Особенно, если организация имеет институциональные знания Spark API.
  • Выбор Dask/Ray не так однозначен, но общее правило заключается в том, что Ray предназначен для ускорения любого типа кода Python, где Dask ориентирован на рабочие процессы, специфичные для науки о данных.