Оптимизация конфигурации кластера для Apache Spark

  • Статья

В этой статье описано, как оптимизировать конфигурацию кластера Apache Spark, чтобы обеспечить наилучшую производительность в Azure HDInsight.

Обзор

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

Ниже приведены некоторые общие параметры, которые можно изменить:

Параметр Описание
--num-executors Задает нужное количество исполнителей.
--executor-cores Задает количество ядер для каждого исполнителя. Обычно используются исполнители среднего размера, так как некоторые процессы используют доступную память.
--executor-memory Задает объем памяти для каждого исполнителя, что влияет на размер кучи в YARN. Оставьте некоторый запас памяти на издержки при выполнении.

Выбор правильного размера исполнителя

При выборе конфигурации исполнителя предусмотрите лимит переполнения памяти при сборке мусора Java.

  • Факторы, которые стоит учесть, чтобы выбрать исполнитель меньшего размера:

    1. Уменьшите размер кучи менее чем до 32 ГБ, чтобы издержки на сборку мусора не превысили 10 %.
    2. Сократите число ядер, чтобы издержки на сборку мусора не превысили 10 %.

  • Факторы, которые стоит учесть, чтобы выбрать исполнитель большего размера:

    1. Уменьшите лимит переполнения памяти при обмене данными между исполнителями.
    2. Сократите число открытых соединений между исполнителями (N2) в более крупных кластерах (> 100 исполнителей).
    3. Увеличьте размер кучи для обработки задач с интенсивным потреблением ресурсов памяти.
    4. Необязательное действие: уменьшите лимит переполнения памяти каждого исполнителя.
    5. Необязательное действие: увеличьте потребление и параллелизм, перегружая доступные ЦП.

При выборе размера исполнителя можно руководствоваться следующим эмпирическим правилом:

  1. Начните с 30 ГБ на каждый исполнитель и распределите доступные ядра компьютера.
  2. Увеличьте число ядер исполнителя для более крупных кластеров (> 100 исполнителей).
  3. Измените размеры в зависимости от пробных запусков и предшествующих факторов, например лимита переполнения памяти при сборке мусора.

При выполнении параллельных запросов действуйте так:

  1. Начните с 30 ГБ на каждый исполнитель и для всех ядер компьютера.
  2. Создайте несколько параллельных приложений Spark, увеличив число назначенных ЦП (уменьшение задержки приблизительно на 30 %).
  3. Распределите запросы между параллельными приложениями.
  4. Измените размеры в зависимости от пробных запусков и предшествующих факторов, например лимита переполнения памяти при сборке мусора.

Дополнительные сведения об использовании Ambari для настройки исполнителей см. в разделе Настройка исполнителей Spark.

Отслеживайте производительность запросов по представлению временной шкалы, чтобы выявлять нетипичные действия и другие проблемы. Также вам помогут диаграммы SQL, статистика заданий и т. д. Сведения об отладке заданий Spark с помощью YARN и сервера журнала Spark см. в статье Отладка заданий Apache Spark в Azure HDInsight. Рекомендации по использованию YARN Timeline Server см. в статье Доступ к журналам приложений Apache Hadoop YARN в HDInsight под управлением Linux.

На некоторых исполнителях или узлах задачи выполняются медленнее

Иногда один или несколько исполнителей работают медленнее по сравнению с другими, и выполнение задач занимает гораздо больше времени. Такое замедление часто происходит в больших кластерах (> 30 узлов). В этом случае разделите работу на большое число задач, чтобы планировщик мог компенсировать их медленное выполнение. Например, создайте как минимум в два раза больше задач по сравнению с количеством ядер исполнителя в приложении. Можно также включить упреждающее выполнение задач с помощью conf: spark.speculation = true.

Дальнейшие действия