Apache Spark - Как избежать неудачи медленных задач

Question

Дорогих братий Apache Спарк энтузиастов

Я недавно стартовал проект боковой линии с целью превратить пару компьютеров ODROID XU4 в автономном Спарке кластер.

После настройки кластера я столкнулся с проблемой, которая, по-видимому, специфична для гетерогенных многопроцессорных процессоров. Задачи исполнителей Spark выполняются очень медленно на XU4 при использовании всех 8 процессоров. Причина, о которой упоминается в комментарии к моему сообщению ниже, заключается в том, что Spark не ждет, когда исполнители будут выпущены на медленных процессорах.

http://forum.odroid.com/viewtopic.php?f=98&t=21369&sid=4276f7dc89a8d7825320e7f705011326&p=152415#p152415

Одно из решений состоят в использовании меньшего количества ядер исполнителя и установить сродство CPU не использовать маленькие процессоры. Это, однако, не идеальное решение.

Есть ли способ попросить Спарка подождать немного дольше для обратной связи от более медленных исполнителей? Очевидно, что ожидание слишком долго будет отрицательно влиять на производительность. Положительный эффект использования всех сердечников должен, однако, сбалансировать отрицательный эффект.

Заранее благодарим за любую помощь!

Answer 1

@ Ответ Dikei выделяет две потенциальные причины, но, оказывается, проблема не в том, что он подозревает. У меня такая же настройка, что и @TJVR, и оказывается, что драйверу не хватает битов от исполнителей.Для решения этой проблемы, я добавил следующее spark-env.sh:

export SPARK_DAEMON_JAVA_OPTS="-Dspark.worker.timeout=600 -Dspark.akka.timeout=200 -Dspark.shuffle.consolidateFiles=true" 
export SPARK_JAVA_OPTS="-Dspark.worker.timeout=600 -Dspark.akka.timeout=200 -Dspark.shuffle.consolidateFiles=true" 

Это изменяет время ожидания по умолчанию для ИСПОЛНИТЕЛЬ сердцебиений. Также установите для параметра spark.shuffle.consolidateFiles значение true для улучшения производительности файловой системы ext4. Эти изменения по умолчанию позволили мне увеличить базовое использование выше одного и не часто терять исполнителей.

Answer 2

Спарк не убивает медленно исполнителей, но ознаменует исполнитель, как мертвые в двух случаях:

1. Если водитель не получает сигнал пульса в то время (по умолчанию: 120 с): Исполнителем (по умолчанию: 10 с) посылать сообщение с биением, чтобы уведомить водителя о том, что он все еще жив. Проблемы с сетью или большая пауза GC могут предотвратить такое сердцебиение.

2. Ошибка выполнения исполнителем из-за исключения из-за ошибки кода или ошибки JVM, что, скорее всего, связано с GC-паузой.

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

Во-вторых, вы не должны устанавливать spark.speculation на «истину» без тестирования. По умолчанию это «ложь» по умолчанию, я видел, что в некоторых случаях это приносит больше вреда, чем пользы.

И, наконец, следующее предположение может быть недействительным.

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

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