#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 полностью использует ресурсы, программа не только работает быстро, но и значительно экономит облачные затраты.