Преимущества и скрытые проблемы перехода от пилотной версии к производственной в Spark

Продукты и конвейеры машинного обучения - это рискованное вложение. Хотя внедрение ERP и развертывание программного обеспечения, скорее всего, увенчаются успехом при наличии достаточного количества времени и внимания, есть много причин, по которым концепция машинного обучения может потерпеть неудачу. Если вы превзойдете все шансы и разработаете работающий пилотный проект, который понравится пользователям, первым вопросом, который будет у всех на уме, будет: Будет ли он масштабироваться?. Обычно ответ - теоретически да, но трудно предсказать, с какими препятствиями интеграции вы столкнетесь на практике. Пройдя через этот процесс один или два раза, вы учитесь заранее отвечать на их вопрос, создавая свой пилотный проект с учетом масштаба. К счастью, наши друзья из Apache Foundation разработали архитектуру именно для этого: Apache Spark.

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

Почему Spark?

Spark так популярен в компьютерном сообществе по нескольким причинам:

Легко использовать

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

Spark написан на Scala, но его оболочки Python, R и Java позволяют широкому кругу пользователей легко запускать распределенные задания на их любимом языке. Этим же людям не нужно бороться за место, работая независимо: Spark может одновременно управлять несколькими разрозненными рабочими нагрузками, не заставляя вашу команду платить за отдельные кластеры.

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

Это быстро (очень быстро) и хорошо масштабируется

Под капотом оптимизатор Spark's Catalyst преобразует вводимые пользователем данные в направленный ациклический граф (DAG) преобразований перед распределением оптимизированной «работы» по сети компьютеров (например, узлам) для обработки в памяти. Визуально этот процесс выглядит примерно так:

Если эта концепция кажется сбивающей с толку, не беспокойтесь об этом: Spark обрабатывает эти оптимизации на сервере, позволяя Spark достигать эталонных скоростей более чем в 100 раз быстрее, чем его предшественник, не усложняя взаимодействие с пользователем в 90% + случаев использования. . Если вам когда-нибудь понадобится больше памяти или вычислительной мощности, вы можете легко обновить существующие узлы или добавить новые узлы в свою сеть.

Это гибкий

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

  • Храните структурированные данные в устойчивых распределенных наборах данных (RDD) или фреймах данных Spark SQL для оптимизации запросов.
  • Используйте Spark GraphX ​​API для обработки и анализа графовых баз данных
  • Преобразуйте и очистите свои данные с помощью одного из многих языковых API Spark.
  • Создавайте и развертывайте алгоритмы машинного обучения с помощью MLlib
  • Агрегируйте и анализируйте потоки данных с помощью Spark Streaming

Другие архитектуры могут быть более эффективными при выполнении одной или двух из этих задач (например, Apache Storm для потоковой передачи; Flink для пакетной обработки), но никакое другое предложение не может владеть сквозным производственным конвейером так, как Spark.

Он имеет импульс

Когда вы создаете что-то долговечное, вы не можете тратить время на беспокойство, сохранится ли ваша архитектура в ближайшее десятилетие. Учитывая внушительный список компаний, которые в настоящее время используют Spark, справедливо предположить, что Spark не уйдет в ближайшее время. Даже если бы архитектура Spark исчезла в пользу конкурирующего фреймворка, было бы относительно легко запустить существующий код Python, R или Scala на новом сервере (этого нельзя сказать о SAS).

Скрытые проблемы для масштабной работы

Spark - мощный инструмент, но его оказалось не так легко освоить, как мы с моей командой изначально ожидали. Хотя к некоторым различиям просто нужно было привыкнуть, сегодня сохраняются три основные проблемы:

Большие штрафы за неэффективный код

Чтобы избежать прерывания работы с терабайтами данных, необходимо уделять особое внимание эффективности кода. Когда вы играете в Jupyter с менее чем двадцатью миллионами строк, вам не о чем беспокоиться; большинство ячеек запустятся мгновенно, и худшее, что вы можете сделать, - это убить ядро ​​и выполнить тридцатисекундный сброс. Сбой из-за нехватки памяти в кластере Spark гораздо более разрушителен. Одно плохо спроектированное соединение может привести к получасовой задержке, поскольку вы ждете, пока кластер Spark автоматически масштабируется, умирает и перезагружается. Чтобы еще больше усугубить неудобства, эти сбросы могут оказаться чрезвычайно дорогостоящими, если в вашем кластере не установлены правильные ограждения.

Инженеры, как правило, обладают этим мышлением, ориентированным на эффективность: мы привыкли разбивать проблемы на модульные части и критически относиться к коду перед его отправкой. С другой стороны, статистики и аналитики склонны отлаживать свой код только после того, как они выдают ошибку или исключение. Эти группы, как правило, борются со Spark, потому что он заставляет их предупреждать потенциальные проблемы так, как они не привыкли. Неспособность обнаружить второстепенные подсказки (например, ненужную пользовательскую функцию или непреднамеренный метод .collect ()) часто приводит к огромным задержкам для всех, кто использует кластер.

Ограниченные библиотеки и коммунальная поддержка

Большинство пользователей Python и R (включая меня) испорчены совместными сообществами, поддерживающими эти языки. Мы привыкли искать библиотеки в Google для решения наших проблем, а когда их нет, мы обычно можем собрать решение, быстро посетив Stack Overflow или Medium. Когда нам нужно просмотреть документацию, мы ожидаем найти чистую, лаконичную формулировку, адаптированную для нетехнической аудитории за десятилетия разработки. Мы редко сталкиваемся с проблемой, которая еще не была решена кем-то другим.

Этих общих костылей для Spark пока нет. Не всегда существует абстракция высокого уровня для решения той или иной проблемы, а количество и качество поддержки ошибок, которую вы получите в Интернете, намного слабее, чем в документах Python или R. Spark, полезны, если вы знаете, как их читать, но они явно написаны для компьютерных ученых; статистики и менее технических специалистов не будут самодостаточными, пока они не изучат несколько основ CS.

Невыразительные языковые API

Изначально нашей команде понравилась идея беспрепятственного перемещения данных между Python, R и Scala. Однако после нескольких недель в окопах эта функция была больше похожа на костыль, чем на улучшение. Проблема в том, что PySpark и SparkR еще не работают сами по себе: хотя вы можете найти в Google Spark-эквиваленты ваших наиболее часто используемых функций в pandas или dplyr, многие из интуитивно понятных методов, которые делают эти библиотеки волшебными, не сделали их путь в Искру. Пока вы ждете обновления этих API, вы можете писать на Scala вспомогательные средства, но это увеличивает время, сложность и технический долг вашей сборке.

"Да, это будет"

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