По мере масштабирования модели мы начали запускать распределенные задания обучения с большим количеством данных и работников, и все более распространенными становятся более сложные шаблоны распределенного обучения. Таким образом, мы обнаружили ряд проблем, связанных с распределенным машинным обучением и глубоким обучением в масштабе:
- Отказоустойчивость и эластичное обучение. По мере того, как распределенные задания машинного обучения используют больше данных и рабочих процессов, вероятность сбоев компьютеров также увеличивается. Поскольку большинство распределенных механизмов выполнения, включая 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 ориентирован на рабочие процессы, специфичные для науки о данных.