Как обрабатывается аварийное завершение драйвера для приложения Spark в режиме кластера пряжи - PullRequest
Новая
       7

Как обрабатывается аварийное завершение драйвера для приложения Spark в режиме кластера пряжи

0 голосов
/ 08 апреля 2020

Мы используем AWS EMR для наших искровых работ. Все наши задания отправляются в режиме кластера пряжи, поэтому драйвер будет работать на одном из узлов кластера. Мы используем узел по требованию для главного и точечные экземпляры для основных узлов. Теперь, хотя мы почти всегда выбираем экземпляры с частотой прерывания <5%, иногда случается так, что значительная часть узлов нашего кластера преждевременно завершается (возможно, из-за более высоких требований). </p>

Итак, мне было интересно, что произойдет в вышеприведенной ситуации, если узел, содержащий процесс драйвера, выйдет из строя? Есть ли шансы на восстановление для искровой работы в этом случае? Или работа ушла навсегда?

Ответы [ 2 ]

1 голос
/ 08 апреля 2020

Драйвер Spark представляет собой единую точку отказа, поскольку он содержит все состояния кластера для работающего приложения.

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

Итак, восстановление означает, что вы сами свернули вещи или приняли повторный запуск. Так как я в последний раз оценивал EMR, я вижу, что драйвер может работать на Master, и это может быть переключено при сбое, но это не то же самое, насколько я вижу, и то, что вы будете sh.

0 голосов
/ 19 апреля 2020

EMR имеет выравнивание узлов для узлов CORE в Yarn. Ваш искровой драйвер / Мастер приложений создается только в узлах CORE. И HDFS также находится только в узлах CORE. Таким образом, чтобы справиться с ситуацией наилучшим образом, вы можете рассмотреть возможность использования группы CORE и TASK. Что вы можете сделать, чтобы решить эту проблему -

  1. MASTER: по требованию
  2. CORE: по требованию. Минимальное количество экземпляров не может быть 1.
  3. ЗАДАЧА: Точечный с автоматическим масштабированием с минимальным объемом EBS. Минимальное количество экземпляров может быть 0 в этом случае.

Это также сократит ваши затраты и гарантирует, что узел, содержащий процесс драйвера, никогда не отключится.

https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html

...