О распределенной науке о данных

Что я думаю о различных распределенных фреймворках в науке о данных

В первый раз, когда я взглянул на набор данных, содержащий более миллиарда строк данных, я подумал, что мой COUNT (*) неверен.

Не было.

Это не избавило меня от необходимости анализировать данные. У бизнеса были данные (очевидно, много), бизнесу требовалось понимание этих данных, и бизнес не знал, как их получить. Итак, я проглотил комок в горле (это была моя первая настоящая работа в области науки о данных) и сделал то, что сделал бы в то время любой младший специалист по данным, - перенес набор данных в гигант корпоративной аналитики… SAS Enterprise Guide (EG; теперь Встречаюсь сам).

Мое беспокойство на этом не прекратилось. Не говоря уже о вертикально массивной памяти на сервере, который используется для поддержки нашего программного обеспечения SAS EG с функцией point-n-click. Он все еще был недостаточно надежен для обработки слишком сложной кластерной аналитики, которую я пытался выполнить. Ошибок памяти предостаточно. Итак, я сделал следующий шаг, который мог бы сделать любой младший специалист по данным на этом этапе своего проекта, - я начал поиск в Google.

И это было мое первое знакомство с распределенной наукой о данных.

С того времени я потратил значительную часть своей карьеры на поддержку аналитики больших данных с использованием различных распределенных фреймворков. Хотя сегодня мое беспокойство уменьшается, когда я сталкиваюсь с наборами данных, которые становятся все больше… спасибо IoT https://www.iotacommunications.com/blog/iot-big-data/ psht… мир распределенной науки о данных продолжает быстро меняться и развиваемся по сей день.

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

Распределенные данные в Vs. Распределенные данные на выходе

Самое большое различие, которое следует делать при рассмотрении распределенных фреймворков науки о данных, - это между исследовательским анализом данных (EDA) и развертыванием науки о данных. Или распределенные данные в сравнении с распределенными данными на выходе. Начнем с EDA.

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

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

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

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

Примером для работы с большими наборами данных является инфраструктура Apache Spark, которая поддерживает Python (язык науки о данных 😊) через реализацию PySpark. Хотя Spark позволяет специалистам по обработке данных возиться с большими наборами данных, распределяя набор данных по ядрам (по вертикали) и по серверам (по горизонтали), у нас все еще есть проблемы, когда дело доходит до моделей обучения.

Чтобы решить проблему обучения модели, Spark выпустил SparkML, библиотеку алгоритмов машинного обучения, которая будет обучать ограниченный набор типов моделей в кластерах на этих огромных наборах данных. Помимо SparkML, экосистема Spark включает ряд других инструментов для поддержки полного спектра «EDA» в конвейере обработки данных.

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

Менее популярным, но распределенным фреймворком на базе Python является Dask. Dask - это более легкий (с точки зрения вычислительных ресурсов) фреймворк для распараллеливания числовых вычислений. Dask работает с распространенными библиотеками Python, такими как numpy и Pandas, но ему не хватает некоторых функций инженерии данных, доступных в Spark, таких как SparkSQL. Более подробную информацию о различиях между ними можно найти здесь.

Как и Spark, у Dask также есть набор моделей машинного обучения, которые можно распараллелить с помощью фреймворка Dask, который, что неудивительно, называется Dask-ML.

Spark и Dask допускают как разработку данных, так и обучение модели, но есть и другие распределенные структуры, предназначенные только для распараллеливания обучения модели. Самыми популярными из них являются TensorFlow и PyTorch. Фактически, PyTorch только что выпустил 1.9, которая включает дополнительную поддержку обучения распределенной модели.

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

Новейший на сцене распределенной науки о данных - Ray. Ray без проблем работает с Python и содержит узкоспециализированные библиотеки для работы с двумя основными вариантами использования, с которыми не справились и другие фреймворки; обучение с подкреплением и обслуживание моделей. Первый - это особый случай, который решает Рэй, когда специалисты по данным могут использовать кластеры для обучения моделей подкрепления. Ray также интегрируется с PyTorch и TensorFlow, что делает его интересным фреймворком для дальнейшего развития.

Тот факт, что Ray также обеспечивает бесшовное обслуживание моделей с RayServe, делает Ray уникальной библиотекой для перехода от «EDA» к развертыванию.

Переход к распределенным данным (также известное как распределенное развертывание)

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

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

Все становится интереснее, когда данные нужно оценивать по запросу. Например, предположим, что вы обучаете модель, которая может принимать данные датчиков с телефона с помощью службы потоковой передачи данных, такой как Kafka, и прогнозировать вероятность того, что кто-то только что упал. Модель должна очень быстро оценивать небольшие объемы данных и поэтому не требует тех же вычислительных ресурсов, которые требуются для больших пакетных заданий. А теперь представьте, что эта модель получает данные с 1 миллиона смартфонов. Как лучше всего мы можем развернуть наши модели для удовлетворения требований к скорости и вычислительным ресурсам в этой ситуации?

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

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

Чем больше вариантов использования, тем сложнее

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

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

Хотите узнать больше о науке о данных, карьерном росте или неверных бизнес-решениях? "Присоединяйся ко мне".