Оптимизация пакетного задания Spark на EMR - PullRequest
Новая
       77

Оптимизация пакетного задания Spark на EMR

0 голосов
/ 13 февраля 2020

Мы запускаем искровое задание на кластере EMR с конфигурацией кластера, как указано ниже. 

Resources:
Node Type:CORE - 2 INSTANCES OF
r4.8xlarge
32 vCore, 244 GiB memory, EBS only storage
EBS Storage:32 GiB

Node Type: MASTER
1 Instance of r4.4xlarge
16 vCore, 122 GiB memory, EBS only storage
EBS Storage:32 GiB

Node Type: TASK- 
2 INSTANCES Of 
r4.4xlarge
16 vCore, 122 GiB memory, EBS only storage
EBS Storage:32 GiB

Мы выполняем spark-submit, используя следующие аргументы на консоли EMR: 

/usr/bin/spark-submit --deploy-mode cluster --conf spark.sql.parquet.fs.optimized.committer.optimization-enabled=true --conf spark.sql.files.ignoreCorruptFiles=true --driver-memory 5g --master yarn --class class_name s3://location_of_jar -c s3://location of input to jar -w xyz.json

Мы считаем, что эти аргументы не используют использование доступных полностью доступных ресурсов. Кто-нибудь может предложить, пожалуйста, есть ли какой-либо другой оптимизированный способ сделать spark-submit в EMR, изменив любой из файлов spark-defaults.conf или передав больше аргументов, чтобы обеспечить оптимальное использование всех доступных ресурсов? Мы выполняем одну работу одновременно. В кластере нет параллельных заданий

Ответы [ 2 ]

0 голосов
/ 14 февраля 2020

Первый шаг для анализа spark job - spark-ui. так что используйте tracking url и посмотрите на l ogs, jobs, executors, streaming. 

http://cluster_manager_host:8088/

Для более подробного анализа использования памяти и процессора вы также можете использовать инструмент Gangalia. 

http://cluster_manager_host/Gangalia

После этого вы можете сделать следующее:

  • Вам необходимо go для пользовательских конфигураций, таких как

    (i) Нет исполнителей --conf num-executors x

    (ii) Память исполнителей --conf executor-memory y

    (iii) Нет ядер -- conf executor-cores z

    (iv) Включить динамическое c распределение ресурсов --conf spark.dynamicAllocation.enabled=true

    (v) Включить максимальное распределение ресурсов --conf maximizeResourceAllocation=true

    (vi) Измените serialisation по умолчанию на Kryo, --conf org.apache.spark.serializer.KryoSerializer

    (vii) Измените номер раздела по умолчанию на пользовательский в зависимости от вашей конфигурации rdd=rdd.repatition(sparkConf.defaultParalallism*2)

  • Если после правильной настройки выше, ваша работа все еще медленная, пожалуйста, измените свой код и используйте надлежащие функции и объекты. например,

    (i) Если вы отправляете данные в любой внешний пункт назначения, например, Kinesis, DB или Kafka, используйте mapPartitions или foreachPatitions и не уменьшайте количество созданий объектов.

    (ii) Если вы звоните Затем внешний API также следует приведенной выше стратегии.

    (iii) Использование надлежащих структур данных.

Для получения дополнительной информации вы можете обратиться: здесь

Надеюсь, это поможет вам.

0 голосов
/ 14 февраля 2020

Не зная ресурсов, выделенных для исполнителя, характера работы, объема обрабатываемых вами данных и т. Д. c., Очень трудно дать правильное предложение. Я думаю, что лучшее, что вы можете сделать сейчас, это также установить ganglia при создании кластера EMR. Веб-интерфейс ganglia доступен через http://master-public-dns-name/ganglia/

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

Количество исполнителей, память исполнителя и ядра могут быть установлены в вашей свече. Отправьте команду, используя следующий способ (это примеры значений): 

--num-executors 10
--executor-cores 1
--executor-memory 5g

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

Если вы не хотите поиграться с этими числами, и пусть spark определит, какая комбинация является наилучшей, возможно, стоит установить динамическое c распределение ресурсов в значение true, используя следующие строки: 

--conf spark.shuffle.service.enabled=true
--conf spark.dynamicAllocation.enabled=true

Следует отметить, что пряжа будет получать 75% всей памяти, выделенной для узлов ядра + задачи. Кроме того, с драйвером и каждым исполнителем связаны накладные расходы памяти. Посмотрите искры документации для этого. Помните об этом при ручном выделении ресурсов для драйвера и исполнителя.

...