Исполнители искры apache и местоположение данных

В искровой литературе говорится

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

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

  1. Если исполнители приобретаются на всех узлах и останутся выделенными для этого приложения в течение всего времени работы всего приложения, нет ли шанса, что многие узлы останутся бездействующими?

  2. В чем преимущество получения ресурсов при создании контекста Spark, а не в DAGScheduler? Я имею в виду, что приложение может быть сколь угодно длинным и просто удерживать ресурсы.

  3. Итак, когда DAGScheduler пытается получить предпочтительные местоположения, а исполнители на этих узлах выполняют задачи, отказывается ли он от исполнителей на других узлах?

Я проверил связанный с этим вопрос Искра на пряже работать с локацией данных при запуске экзекьюторов

Но я не уверен, что есть окончательный ответ


apache-spark executors
person user045213    schedule 28.07.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

  1. Если исполнители приобретаются на всех узлах и останутся выделенными для этого приложения в течение всего времени работы всего приложения, нет ли шанса, что многие узлы останутся бездействующими?

Да есть шанс. Если у вас есть перекос данных, это произойдет. Задача состоит в том, чтобы настроить исполнители и ядро ​​исполнителя так, чтобы получить максимальную загрузку. Spark также обеспечивает динамическое выделение ресурсов, что гарантирует удаление бездействующих исполнителей.

  1. В чем преимущество получения ресурсов при создании контекста Spark, а не в DAGScheduler? Я имею в виду, что приложение может быть сколь угодно длинным и просто удерживать ресурсы.

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

  1. Итак, когда DAGScheduler пытается получить предпочтительные местоположения, а исполнители на этих узлах выполняют задачи, отказывается ли он от исполнителей на других узлах?

Spark не может запустить задачу на исполнителе, если исполнитель не свободен. Теперь мастер приложения spark согласовывает с пряжей, чтобы получить предпочтительное местоположение. Это может получиться, а может и не получиться. Если он не получит, он запустит задачу в другом исполнителе.

person Avishek Bhattacharya    schedule 28.07.2018