Apache Spark: различия между режимами развертывания клиента и кластера

TL; DR: В автономном кластере Spark, каковы различия между режимами развертывания клиентов и кластеров? Как установить, в каком режиме будет работать мое приложение?

У нас есть автономный кластер Spark с тремя машинами, все из которых с Spark 1.6.1:

Мастер-машина, в которой также выполняется наше приложение с помощью spark-submit
2 идентичных рабочих машины

Из Искра документация, я читал:

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

Однако я не понимаю практических различий, читая это, и я не понимаю, каковы преимущества и недостатки различных режимов развертывания.

Кроме того, когда я запускаю свое приложение, используя start-submit, даже если я устанавливаю свойство spark.submit.deployMode в "cluster", интерфейс Spark для моего контекста показывает следующую запись:

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

1) Каковы практические различия между режимом развертывания клиента Spark Standalone и режимом развертывания кластера? Что такое pro и con для использования каждого из них?

2) Как выбрать, какое приложение будет запущено, используя spark-submit?

Ответ 1

Каковы практические различия между Spark Standalone client режим развертывания и режим развертывания кластера? Что такое pro и con используя каждый из них?

Попробуем посмотреть на различия между клиентом и кластерным режимом.

Клиент:

Драйвер запускается на выделенном сервере (мастер node) внутри выделенного процесса. Это означает, что у него есть все доступные ресурсы для выполнения работы.
Драйвер открывает выделенный HTTP-сервер Netty и распространяет файлы JAR, указанные для всех узлов Worker (большое преимущество).
Поскольку мастер node имеет собственные ресурсы, вам не нужно "тратить" рабочие ресурсы на программу Driver.
Если процесс драйвера умирает, вам нужна внешняя система мониторинга для выполнения reset.

Кластер:

Драйвер работает на одном из узлов Workstation. Работник выбирается лидером-руководителем.
Драйвер работает как отдельный автономный процесс внутри Рабочего.
Программы-драйверы занимают не менее одного ядра и выделенного объема памяти от одного из рабочих (это можно настроить).
Драйвер программы можно отслеживать с помощью мастера node с использованием флага --supervise и быть reset в случае его смерти.
При работе в режиме кластеров все JAR, связанные с исполнением вашего приложения, должны быть общедоступными для всех работников. Это означает, что вы можете вручную разместить их в общем месте или в папке для каждого из рабочих.

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

Как выбрать, к какому моему приложению будет работать, используя spark-submit

Способ выбора режима, в котором выполняется запуск, - это использовать флаг --deploy-mode. На странице Spark Configuration:

/bin/spark-submit \
  --class <main-class>
  --master <master-url> \
  --deploy-mode <deploy-mode> \
  --conf <key>=<value> \
  ... # other options
  <application-jar> \
  [application-arguments]

Ответ 2

Исправленные режимы развертывания - режим кластеров и режим клиента

Режимы развертывания искры определяют, где будет запускаться программа драйвера.

Когда мы отправляем искровое задание для выполнения на локальный или на кластер, поведение искрового задания полностью зависит от одного параметра, то есть от компонента " Драйвер ".

В принципе, можно двумя способами представить Spark Job:

1. Режим клиента искры:

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

Чтобы запустить приложение Spark в режиме клиента:

Пример:

$ ./bin/spark-submit --class org.apache.spark.examples.SparkPi \
--master yarn \
--deploy-mode client \
--driver-memory 4g \
--executor-memory 2g \
--executor-cores 1 \
--queue thequeue \
examples/jars/spark-examples*.jar \
10

2. Режим работы с искровым кластером:

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

Note: For using spark interactively, cluster mode is not appropriate. Since applications which require user input need the spark driver to run inside the client process, for example, spark-shell and pyspark. That initiates the spark application.

Чтобы запустить приложение Spark в режиме кластера:

Пример:

$ ./bin/spark-submit --class org.apache.spark.examples.SparkPi \
    --master yarn \
    --deploy-mode cluster \
    --driver-memory 4g \
    --executor-memory 2g \
    --executor-cores 1 \
    --queue thequeue \
    examples/jars/spark-examples*.jar \
    10

Вывод: в режиме клиента драйвер Spark (и SparkContext) запускается на клиентском узле вне кластера YARN, тогда как в режиме кластера он запускается внутри кластера YARN, то есть внутри контейнера YARN вместе с ApplicationMaster (который действует как приложение Spark в YARN),

Ответ 3

У меня тоже такой же сценарий, здесь мастер node использует автономный кластер ec2. В этом режиме настроен клиентский режим. В этом драйвере запускается непосредственно с процессом spark-submit, который действует как клиент для кластера. Вход и выход приложения подключены к консоли. Таким образом, этот режим особенно подходит для приложений, которые включают REPL.

Иначе, если ваше приложение отправлено с машины далеко от рабочих машин, довольно распространено использование режима кластера, чтобы свести к минимуму драйвер и исполнитель b/w задержки в сети.

Ответ 4

Скажем, вы собираетесь выполнить иск в EMR, выполнив SSH на главный узел. Если вы предоставляете опцию -deploy-mode cluster, то произойдет следующее.

Вы не сможете просмотреть подробные журналы в терминале.
Поскольку драйвер не создан в самом Мастере, вы не сможете завершить работу с терминала.

Но в случае клиента -deploy-mode:

Вы сможете просмотреть подробные журналы в терминале.
Вы сможете завершить работу с самого терминала.

Это основные вещи, которые я заметил до сих пор.