Ресурсы / документация о том, как работает процесс аварийного переключения для драйвера Spark (и его контейнера YARN) в режиме пряжи-кластера

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

Я знаю, что драйвер Spark будет работать в мастере приложений Spark внутри контейнера пряжи. При необходимости мастер приложения Spark запросит ресурсы у диспетчера ресурсов YARN. Но мне не удалось найти документ с достаточно подробной информацией о процессе отработки отказа в случае отказа контейнера YARN мастера приложений Spark (и драйвера Spark).

Я пытаюсь найти некоторые подробные ресурсы, которые могут позволить мне ответить на некоторые вопросы, относящиеся к следующему сценарию: Если хост-компьютер контейнера YARN, на котором работает Spark Application Master / Spark Driver, теряет сеть подключение на 1 час:

  1. Создает ли YARN Resource Manager новый контейнер YARN с другим Spark Application Master / Spark Driver?

  2. В этом случае (порождение нового контейнера YARN) запускает ли он драйвер Spark с нуля, если хотя бы 1 этап из 1 из Executors был завершен и уведомлен как таковой исходному драйверу до того, как он потерпел неудачу? Имеет ли значение здесь опция, используемая в persist ()? И будет ли новый Spark Driver знать, что исполнитель выполнил 1 этап? Поможет ли Тахион в этом сценарии?

  3. Запускается ли процесс восстановления после сбоя, если сетевое подключение восстанавливается на хост-машине YARN Container исходного Spark Application Master? Я предполагаю, что этим поведением можно управлять из YARN, но я не знаю, что используется по умолчанию при развертывании SPARK в кластерном режиме.

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


apache-spark hadoop yarn alluxio
person MiguelPeralvo    schedule 18.01.2015    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Мы только начали работать над YARN, так что я мало что знаю. Но я почти уверен, что у нас не было автоматического переключения при отказе на уровне водителя. (Мы реализовали некоторые самостоятельно.)

Я бы не ожидал, что для драйвера будет какое-либо решение для аварийного переключения по умолчанию. Вы (автор драйвера) единственный, кто знает, как проверить работоспособность вашего приложения. И состояние, которое живет в драйвере, не может быть автоматически сериализовано. Когда SparkContext уничтожается, все созданные в нем RDD теряются, потому что они бессмысленны без работающего приложения.

Что ты можешь сделать

Реализованная нами стратегия восстановления очень проста. После каждой дорогостоящей операции Spark мы производим контрольную точку вручную. Мы сохраняем RDD на диск (подумайте saveAsTextFile) и сразу же загружаем обратно. Это стирает происхождение RDD, поэтому оно будет перезагружено, а не пересчитано, если раздел потерян.

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

person Daniel Darabos    schedule 19.01.2015
comment
Привет, Даниэль, то, что ты сказал, имеет смысл. Но я получил некоторую документацию / ресурсы об архитектуре вокруг: как драйвер работает в yarn-cluster, его процесс аварийного переключения в этом контексте (что бы ни было предоставлено из коробки), как сохраняется происхождение, если Tachyon или сохраняется ( DISK_ONLY) предоставляют некую контрольную точку, которую можно использовать, то, что происходит с сиротскими этапами и исполнителями после смерти исходного драйвера, ... определенно поможет мне в процессе разработки более гибкого настраиваемого процесса аварийного переключения для драйвера. Спасибо! - person MiguelPeralvo; 20.01.2015
comment
Извините, я не знаю такой документации. Исходный код Spark довольно читабелен. К ответу я добавил описание нашего (действительно простого) решения. Надеюсь, это поможет! - person Daniel Darabos; 20.01.2015
comment
Справедливо. Большое спасибо, Дэниел. - person MiguelPeralvo; 20.01.2015
comment
Привет, Даниэль. Что касается перезапуска драйвера, он может продолжить работу с того места, где он остановился, на уровне детализации таких операций, я этого не совсем понимаю. Если с драйвером ничего не происходит, то после того, как rdd_a получает контрольную точку для HDFS, и каждый раз, когда rdd_a запрашивается, он считывает данные из HDFS, а не повторно вычисляет данные. Однако, если драйвер все-таки выходит из строя и новый драйвер запускается после сбоя, на этот раз rdd_a еще не имеет контрольной точки для подтверждения нового драйвера, хотя в HDFS есть файл контрольной точки. Объясните, пожалуйста, как новый драйвер немного подхватывает? :) - person Kurtt.Lin; 10.02.2015
comment
Боюсь, это слишком сложно, чтобы подробно объяснять здесь. Схема такова, что у нас есть список операций (составленный пользователем). У каждого из них есть код для выполнения вычислений по входным RDD и создания выходных RDD. Когда нам нужен результат, мы проверяем для каждой операции, находится ли ее вывод на диске. Если он на диске, мы его загружаем, если его нет на диске, мы запускаем код (затем сохраняем вывод на диск). В любом случае мы получаем выходной RDD и переходим к следующей операции. Надеюсь, в этом есть смысл! - person Daniel Darabos; 10.02.2015