Spark + EMR с использованием настройки «maximizeResourceAllocation» от Amazon не использует все ядра/vcores

Question

Я запускаю кластер EMR (версия emr-4.2.0) для Spark, используя флаг Amazon maximizeResourceAllocation, как задокументировано here. Согласно этим документам, «эта опция вычисляет максимальные ресурсы вычислений и памяти, доступные для исполнителя на узле в группе основных узлов, и устанавливает соответствующие параметры искрового значения по умолчанию с помощью этой информации».

Я запускаю кластер, используя экземпляры m3.2xlarge для рабочих узлов. Я использую один m3.xlarge для мастера YARN - самый маленький экземпляр m3, который я могу заставить запустить, поскольку он не делает многого.

Ситуация такова: когда я запускаю задание Spark, количество запрошенных ядер для каждого исполнителя составляет 8. (Я получил это после настройки "yarn.scheduler.capacity.resource-calculator": "org.apache.hadoop.yarn.util.resource.DominantResourceCalculator", который фактически не находится в документации, но я отвлекаюсь). Это, по-видимому, имеет смысл, потому что согласно these docs m3.2xlarge имеет 8 "vCPUs". Однако в самих фактических экземплярах в /etc/hadoop/conf/yarn-site.xml каждый узел настроен так, что yarn.nodemanager.resource.cpu-vcores установлен на 16. Я бы предположил, что это должно быть связано с гиперпотоком или, возможно, с какой-то другой аппаратной привязанностью.

Таким образом, проблема заключается в следующем: когда я использую maximizeResourceAllocation, я получаю количество «vCPU», которое имеет тип экземпляра Amazon, который, по-видимому, составляет лишь половину от числа настроенных «VCores», которые YARN работает на узел; в результате исполнитель использует только половину фактических вычислительных ресурсов экземпляра.

Это ошибка в Amazon EMR? Другие люди испытывают одну и ту же проблему? Есть ли какая-то другая магическая недокументированная конфигурация, которую мне не хватает?

Answer 1

С помощью этой настройки вы должны получить 1 исполнитель на каждом экземпляре (кроме главного), каждый с 8 ядрами и около 30 ГБ ОЗУ.

Является ли интерфейс Spark по адресу http: //: 8088/не отображается это распределение?

Я не уверен, что настройка действительно очень важна по сравнению с другой, упомянутой на этой странице, «Включение динамического распределения исполнителей». Это позволит Spark управлять собственным количеством экземпляров для задания, и если вы запустите задачу с двумя ядрами процессора и 3G-оперативной памятью на одного исполнителя, вы получите довольно хорошее соотношение CPU и памяти для размеров экземпляров EMR.

Answer 2

Хорошо, после много экспериментов я смог отследить проблему. Я собираюсь сообщить о своих выводах здесь, чтобы помочь людям избежать разочарования в будущем.

• Несмотря на то, что существует 8 несоответствий между 8 ядрами и 16 VCores, о которых знает YARN, это, похоже, не имеет значения. YARN не использует группы или что-либо, что действительно позволяет ограничить количество процессоров, которые фактически может использовать исполнитель.
• «Ядра» на исполнителе на самом деле немного неправильное. На самом деле, сколько одновременных задач исполнитель будет охотно запускать в любой момент времени; по существу сводится к тому, сколько потоков выполняет «работу» над каждым исполнителем.
• Когда maximizeResourceAllocation установлен, при запуске программы Спарк, она устанавливает свойство spark.default.parallelism быть количество ядер экземпляра (или «виртуальных процессоров») для всех неглавного экземпляров, которые были в кластере во время создание. Это, вероятно, слишком мало даже в обычных случаях; Я слышал, что рекомендуется установить это на 4x количество ядер, которые вам нужно будет выполнять. Это поможет убедиться, что на любом данном этапе имеется достаточно задач, чтобы поддерживать работу ЦП на всех исполнителях.
• Когда у вас есть данные, которые поступают из разных серий различных программ искры, ваши данные (в формате RDD или Parquet или что-то еще), скорее всего, будут сохранены с различным количеством разделов. При запуске программы Spark убедитесь, что вы перепечатываете данные либо во время загрузки, либо перед задачей, требующей особо интенсивного процессора. Поскольку у вас есть доступ к настройке spark.default.parallelism во время выполнения, это может быть удобное число для перераспределения.

TL; DR

1. maximizeResourceAllocation будет делать почти все, что для вас правильно, за исключением ...
2. Вы, вероятно, хотите явно установить spark.default.parallelism в 4 раза количество ядер, например, вы хотите работу в (в режиме EMR говорить)/«приложение» (на языке YARN), т.е. установить его каждый раз и ...
3. Удостоверьтесь, что в вашей программе, чтобы ваши данные были соответствующим образом разделены (т. хочу много разделов), чтобы искра распараллелить это правильно

Answer 3

в версии 3.х ЭМИ, это maximizeResourceAllocation был реализован с помощью справочной таблицы: https://github.com/awslabs/emr-bootstrap-actions/blob/master/spark/vcorereference.tsv

он используется сценарий оболочки: maximize-spark-default-config, в то же самое репо, вы можете посмотреть, как они это реализовали.

возможно в новых ЭХ версиях 4, эта справочная таблица была как-то неправильна ... я верю, что вы можете найти весь этот скрипт AWS EC2 в вашем экземпляре ОГО, должно быть расположены в /USR/Lib/искре или /opt/aws или что-то в этом роде.

в любом случае, по крайней мере, вы можете написать свои собственные bootstrap action скриптов для этого в ЭХ 4, с правильной ссылочной таблицей, подобной реализацией в ОМ 3.x

кроме того, так как мы будем использовать STUPS инфраструктуры, стоит принять посмотреть STUPS прибор для Спарка: https://github.com/zalando/spark-appliance

вы можете явно указать количество ядер, установив параметр Senza DefaultCores при развертывании искрового кластера

некоторой изюминки этого аппарата по сравнению с ЭМ является:

возможности использовать его даже t2 тип экземпляра, авто-масштабируемые на основе ролей, как и другой STUPS устройство и т.д.

и вы можете легко развернуть кластера в Режим HA с zookeeper, поэтому SPOF на главном узле, режим HA в EMR в настоящее время по-прежнему невозможен, и я считаю, что EMR в основном предназначена для «больших кластеров на временных рабочих местах», а не для «выделенных кластер, который постоянно включен ", поэтому режим HA не будет возможен в ближайшем будущем с помощью EMR.