Обзор некоторых наиболее распространенных проблем с производительностью Spark и способов их решения.

Введение

Apache Spark в настоящее время является одной из самых популярных технологий обработки больших данных, используемых в отрасли, которую поддерживают такие компании, как Databricks и Palantir.

Одной из ключевых обязанностей инженеров данных при использовании Spark является написание высокооптимизированного кода, чтобы в полной мере использовать возможности распределенных вычислений Spark (рис. 1).

В рамках этой статьи вы познакомитесь с некоторыми из наиболее распространенных проблем с производительностью при использовании Spark (например, 5 S) и способами их решения. Если вы совсем новичок в Apache Spark, вы можете найти дополнительную информацию об этом в моей предыдущей статье.

5 СС

5 Ss (Spill, Skew, Shuffle, Storage, Serialization) — это 5 наиболее распространенных проблем с производительностью в Spark. Два ключевых общих подхода, которые можно использовать для повышения производительности Spark при любых обстоятельствах:

  • Уменьшение количества принимаемых данных.
  • Сокращение времени, затрачиваемого Spark на чтение данных (например, использование Predicate Pushdown с разбиением диска/кластеризацией Z-порядка).

Теперь мы углубимся в каждую из проблем, связанных с 5 S.

Проливать

Разлив вызван записью временных файлов на диск при нехватке памяти (раздел слишком велик, чтобы поместиться в ОЗУ). В этом случае RDD сначала перемещается из ОЗУ на диск, а затем обратно в ОЗУ, чтобы избежать ошибок нехватки памяти (OOM). Дисковые операции чтения и записи могут быть довольно дорогими для вычислений, поэтому их следует по возможности избегать.

Разрушение можно лучше понять при выполнении заданий Spark, изучив пользовательский интерфейс Spark на предмет значений Разлив (память) и Разлив (диск).

  • Spill (Memory): размер данных в памяти для разлитого раздела.
  • Разлив (Диск): размер данных на диске для разлитого раздела.

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

перекос

При использовании Spark данные обычно считываются равномерно распределенными разделами по 128 МБ. Применение различных преобразований к данным может привести к тому, что некоторые разделы станут намного больше или меньше их среднего значения.

Перекос является результатом дисбаланса в размерах между различными разделами. Небольшое количество перекосов может быть вполне приемлемым, но в некоторых случаях перекос может привести к ошибкам Spill и OOM.

Два возможных подхода к уменьшению перекоса (рис. 2):

  • Добавление перекошенного столбца со случайными числами для перераспределения размеров разделов.
  • Использование адаптивного выполнения запросов (Spark 3).

Перемешать

Перетасовка результатов перемещения данных между исполнителями при выполнении широких преобразований (например, соединений, groupBy и т. д.) или некоторых действий, таких как подсчет (рис. 3). Неправильное решение проблем с перемешиванием может привести к перекосу.

Вот некоторые подходы, которые можно использовать для уменьшения количества перетасовок:

  • Создание меньшего количества и более крупных рабочих процессов (таким образом, сокращая накладные расходы на сетевой ввод-вывод).
  • Предварительно фильтруйте данные, чтобы уменьшить их размер перед перемешиванием.
  • Денормализация задействованных наборов данных.
  • Отдавайте предпочтение твердотельным накопителям, а не жестким дискам для более быстрого выполнения.
  • При работе с небольшими таблицами широковещательный хэш присоединяется к меньшей таблице. Для больших таблиц используйте вместо этого SortMergeJoin (широковещательное хэш-соединение может привести к проблемам с нехваткой памяти для больших таблиц).

Хранилище

Проблемы с хранением возникают, когда данные хранятся на диске неоптимальным образом. Проблемы, связанные с хранилищем, потенциально могут привести к чрезмерному перемешиванию. Три основные проблемы, связанные с хранилищем: крошечные файлы, сканирование и схемы.

  • Маленькие файлы:обработка файлов разделов размером менее 128 МБ.
  • Сканирование: при сканировании каталогов у нас может быть либо длинный список файлов в одном каталоге, либо, в случае сильно разделенных наборов данных, многоуровневые папки. Чтобы уменьшить объем сканирования, мы можем зарегистрировать его как таблицу.
  • Схема: в зависимости от используемого формата файла могут быть разные проблемы со схемой. Например, при использовании JSON и CSV необходимо прочитать все данные, чтобы сделать вывод о типах данных. Вместо этого для Parquet требуется чтение только одного файла, но необходимо прочитать весь список файлов Parquet, если нам нужно обрабатывать возможные изменения схемы с течением времени. Чтобы улучшить производительность, можно заранее предоставить определения схемы.

Сериализация

Сериализация охватывает все проблемы, связанные с распределением кода по кластерам (код сериализуется, отправляется исполнителям, а затем десериализуется).

В случае Python этот процесс может быть даже более сложным, поскольку код должен быть обработан и каждому исполнителю должен быть выделен экземпляр интерпретатора Python.

Проблемы с сериализацией могут возникнуть при интеграции кодовых баз с устаревшими системами (например, Hadoop), сторонними библиотеками и пользовательскими платформами. Один из ключевых подходов, который мы можем использовать для уменьшения проблем с сериализацией, заключается в том, чтобы избегать использования UDF или Vectorized UDF (которые действуют как черный ящик для Catalyst Optimizer).

Заключение

Даже с последним выпуском Apache Spark 3 оптимизация Spark остается одной из основных областей, в которых опыт и знания специалистов имеют основополагающее значение для успешного использования возможностей Spark. В рамках этой статьи были рассмотрены некоторые ключевые проблемы, с которыми можно столкнуться в проекте Spark, хотя в некоторых случаях эти проблемы могут быть сильно связаны друг с другом, что затрудняет отслеживание основной причины.

Контакты

Если вы хотите быть в курсе моих последних статей и проектов, подпишитесь на меня на Medium и подпишитесь на мой список рассылки. Вот некоторые из моих контактных данных: