Как настроить оборудование для ускорения работы Apache Spark

Зачем размещать задания Apache Spark на узлах HDFS, какую пропускную способность сети передачи данных выбрать, почему не рекомендуется использовать RAID для жестких дисков, сколько выделить памяти и ядер ЦП.

Рекомендации по настройке оборудования для Spark-приложений

На практике большинство заданий Spark считывает входные данные из внешней системы хранения, например, файловой системы Hadoop HDFS или HBase. Поэтому важно размещать задания Spark как можно ближе к системе хранения данных. Для этого можно запускать Spark на тех же узлах, что и HDFS. Проще всего запустить кластер Spark в автономном режиме на одних и тех же узлах и настроить использование памяти и ЦП. Чтобы избежать конфликтов между Spark и Hadoop, для последнего следует настроить параметры памяти для каждой задачи mapred.child.java.opts, а также количество задач MapReduce mapreduce.tasktracker.map.tasks.maximum, mapreduce.tasktracker.reduce.tasks.maximum. Вместо этого можно запустить Hadoop и Spark на обычном диспетчере кластера, таком как Mesos или Hadoop YARN. Если это невозможно, можно запустить Spark в той же локальной сети, что и HDFS. Для хранилищ данных с низкой задержкой, таких как HBase, можно запускать вычислительные задания на других узлах, а не в системе хранения.

Хотя Spark выполняет большую часть вычислений в памяти, он все-таки использует локальные диски для хранения данных, которые не помещаются в ОЗУ, а также для сохранения промежуточных результатов между этапами. Поэтому рекомендуется иметь 4-8 дисков на узел, настроенных без RAID, т.е. как отдельные точки монтирования. В Linux-системах надо монтировать диски с настройкой noatime, чтобы уменьшить количество операций ненужной записи. Параметр noatime полностью отключает запись времени доступа к файлу, позволяя улучшить производительность доступа к данным, а также уменьшить число операций ввода-вывода. Особенно это важно при использовании HDD-дисков, а для SSD почти не заметно. Для настройки этого используется переменная spark.local.dir. Если данные хранятся в HDFS, можно использовать те же диски, чтобы сократить задержку на передачу данных по сети.

В целом распределенные приложения, разработанные с помощью этого фреймворка, могут хорошо работать с объемом памяти от 8 до нескольких сотен ГБ на машину. Во всех случаях рекомендуется выделять для Spark не более 75% памяти, поскольку нужно место для операционной системы и буферного кэша.

Сколько памяти понадобится, зависит от приложения. Посмотреть, сколько приложение использует памяти для определенного размера набора данных, можно в GUI, доступном по URL-адресу http://<driver-node>:4040. Потребление памяти сильно зависит от уровня хранения и формата сериализации.

Поскольку исполнитель Spark представляет собой виртуальную машину Java (JVM), о чем мы писали здесь, надо учитывать, как эта технология влияет на потребление ресурсов. JVM сама по себе потребляет много оперативной памяти, поэтому ее должно быть не менее 200 ГБ. При использовании узлов с большим объемом оперативной памяти, можно запускать несколько исполнителей на одной машине. В автономном режиме исполнитель отвечает за запуск нескольких исполнителей в соответствии с доступной ему памятью и ядрами, и каждый исполнитель будет запускаться на отдельной виртуальной машине Java.

Распределенный характер приложений предполагает обмен данными по сети при выполнении операций перемешивания. Поэтому рекомендуется использовать 10-гигабитную сеть, чтобы ускорить работу распределенных приложений. Увидеть, какой объем данных перемещается по сети, можно в GUI фреймворка по URL-адресу http://<driver-node>:4040.

Spark хорошо масштабируется до десятков ядер ЦП на машину, поскольку обеспечивает минимальное совместное использование потоков между собой. Обычно рекомендуется выделить не менее 8–16 ядер на машину. В зависимости от затрат ЦП на рабочую нагрузку, может потребоваться больше вычислительных ресурсов: как только данные находятся в памяти, большинство приложений привязаны либо к ЦП, либо к сети.

Например, в кластере с 32 ядрами ЦП и 256 ГБ оперативной памяти целесообразно использовать 2 ядра ЦП для YARN и системной обработки, оставив 30 ядер ЦП для непосредственных вычислений. Таким образом, 5-ядерный исполнитель с 34 ГБ памяти также будет работать на таком узле. А в кластере с 8 или менее ядрами на узле, можно использовать только 8 основных узлов, если задания выполняются только на одном узле. Однако, когда задания занимают два 8-ядерных узла или четыре 4-ядерных, лучше выполнять их на 16-ядерном узле. Подробнее об этом мы рассказываем здесь.

Узнайте больше про возможности Apache Spark для разработки приложений аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

• Основы Apache Spark для разработчиков
• Потоковая обработка в Apache Spark
• Анализ данных с Apache Spark
• Машинное обучение в Apache Spark
• Графовые алгоритмы в Apache Spark
• Архитектура данных с Apache Spark

Источники

1. https://spark.apache.org/docs/latest/hardware-provisioning.html
2. https://sparkbyexamples.com/spark/spark-performance-tuning/