Исполнители Apache Spark и локальность данных

Question

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

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

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

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

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

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

Я проверил связанный с этим вопрос. Имеет ли Spark на пряже отношение к данным при запуске исполнителей?

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

Answer 1

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

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

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

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

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

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