Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается оптимизация конфигурации кластера Apache Spark для повышения производительности в Azure HDInsight.
Обзор
В зависимости от рабочей нагрузки кластера Spark можно определить, что конфигурация Spark не по умолчанию приведет к более оптимизированного выполнения задания Spark. Выполните тестирование производительности с примерами рабочих нагрузок, чтобы проверить все нестандартные конфигурации кластера.
Ниже приведены некоторые распространенные параметры, которые можно настроить:
| Параметр | Описание |
|---|---|
| --num-executors | Задает соответствующее количество исполнителей. |
| --executor-cores | Задает количество ядер для каждого исполнителя. Как правило, у вас должен быть исполнитель среднего размера, так как другие процессы используют некоторую доступную память. |
| --executor-memory | Задает размер памяти для каждого исполнителя, определяющий размер кучи в YARN. Оставьте достаточно памяти для накладных расходов на выполнение. |
Выберите правильный размер исполнителя
При выборе конфигурации исполнителя рассмотрите издержки сборщика мусора Java (GC).
Факторы для уменьшения размера исполнителя:
- Уменьшите размер кучи ниже 32 ГБ, чтобы нагрузка на сборщик мусора оставалась менее 10%.
- Уменьшите количество ядер, чтобы сохранить нагрузку < на сборку 10%.
Факторы для увеличения размера исполнителя:
- Уменьшите затраты на обмен данными между исполнителями.
- Уменьшите количество открытых подключений между исполнителями (N2) в больших кластерах (>100 исполнителей).
- Увеличьте размер кучи для выполнения задач с интенсивным объемом памяти.
- Необязательный вариант. Сокращение затрат на память для каждого исполнителя.
- Опционально: Повышение использования и параллелизма путём перегрузки ЦП.
Как правило, при выборе размера исполнителя:
- Начните с 30 ГБ на исполнителя и распределите доступные ядра компьютера.
- Увеличьте число ядер исполнителя для больших кластеров (> 100 исполнителей).
- Измените размер, основываясь как на пробных запусках, так и на таких факторах, как накладные расходы на сборку мусора.
При выполнении параллельных запросов следует учитывать:
- Начните с 30 ГБ на исполнителя и все ядра компьютера.
- Создавайте несколько параллельных приложений Spark, перераспределяя ресурсы ЦП (улучшение задержки на около 30%).
- Распределяйте запросы между параллельными приложениями.
- Измените размер на основе пробных запусков и предыдущих факторов, таких как накладные расходы сборки мусора.
Дополнительные сведения об использовании Ambari для настройки исполнителей см. в параметрах Apache Spark — исполнителях Spark.
Отслеживайте производительность запросов для излиев или других проблем с производительностью, просматривая представление временной шкалы. Также граф SQL, статистика работы и т. д. Сведения об отладке заданий Spark с помощью YARN и сервера журнала Spark см. в статье Отладка заданий Apache Spark, выполняемых в Azure HDInsight. Советы по работе с сервером временной шкалы YARN см. в разделе доступ к журналам приложений Apache Hadoop YARN.
На некоторых узлах или исполнителях задачи могут быть медленнее.
Иногда один или несколько исполнителей медленнее, чем другие, и задачи занимают гораздо больше времени для выполнения. Это замедление часто происходит на больших кластерах (> 30 узлов). В этом случае делите работу на большее количество задач, чтобы планировщик может компенсировать медленные задачи. Например, у вас есть по крайней мере в два раза больше задач, чем число ядер исполнителя в приложении. Вы также можете включить спекулятивное выполнение задач с помощью conf: spark.speculation = true.