задержка запуска задания при попытке сохранить как таблицу в aws emr

#amazon-web-services #apache-spark #pyspark #amazon-emr

#amazon-web-services #apache-spark #pyspark #amazon-emr

Вопрос:

Мы создали выделенный кластер для нашего приложения в AWS.

Это конфигурация ядер (у нас 2 ядра)

 m5.xlarge
4 vCore, 16 GiB memory, EBS only storage
EBS Storage:64 GiB
 

Текущий набор данных —

Мы пытаемся запустить задание spark, которое включает в себя множество объединений и работает с 80 миллионами записей, каждая запись содержит более 60 полей

Проблема, с которой мы сталкиваемся —

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

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

Текущая конфигурация

 Executor Memory : 2G
Dynamic Allocation Enabled : true
Number of Executor Cores : 1
Number of Executors : 8
spark.dynamicAllocation.executorIdleTimeout : 3600
spark.sql.broadcastTimeout : 36000
 

Комментарии:

1. У меня была такая же проблема, и она была решена путем добавления дополнительных разделов в конечный фрейм данных перед записью таблицы. Вы записываете эту таблицу на S3? Хорошей отправной точкой является сохранение 1 ГБ на раздел в формате parquet.

Ответ №1:

Глядя на вашу конфигурацию, некоторые наблюдения —

Вы используете

m5.xlarge у которого 4 vCore, 16 гигабайт памяти

Конфигурация исполнителя

Количество исполнительных ядер: 1
Исполнительная память: 2 ГБ

Таким образом, может быть запущено не более 4 исполнителей, а память, требуемая для 4 исполнителей, равна 8. Таким образом, в конце вы не используете весь ресурс.


Также, как сказал @Shadowtrooper, сохраните данные в разделе (если возможно, в формате Parquet), если сможете, это также сэкономит затраты при запросе в Athena.

Комментарии:

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