Оптимизация хранилища данных для Apache Spark

  • Статья

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

Обзор

Spark поддерживает многие форматы, такие как CSV, JSON, XML, PARQUET, ORC и AVRO. С помощью внешних источников данных его можно расширить для поддержки большего количества форматов. Дополнительные сведения см. на странице пакетов Apache Spark.

Лучший формат для повышения производительности — PARQUET со сжатием Snappy, который является стандартным форматом в кластере Spark 2.x. В формате PARQUET данные хранятся в столбцах. Этот формат высоко оптимизирован в Spark.

Выбор абстракции данных

В более ранних версиях Spark используются наборы RDD для абстракции данных. В Spark версии 1.3 и 1.6 были представлены DataFrames и DataSets соответственно. Рассмотрим следующие относительные характеристики:

  • Кадры данных
    • Оптимальный вариант в большинстве случаев.
    • Предоставляет оптимизацию запросов через Catalyst.
    • Комплексное создание кода.
    • Прямой доступ к памяти.
    • Низкие накладные расходы при сборке мусора.
    • Не настолько удобны для разработчиков, как наборы данных, так как отсутствуют проверки со временем компиляции или программирование на основе объекта домена.
  • Наборы данных
    • Подходят для использования в сложных конвейерах ETL, где допустимо влияние производительности.
    • Не подходят для использования в статистических функциях, где весомо влияние производительности.
    • Предоставляет оптимизацию запросов через Catalyst.
    • Удобны для разработчиков, так как обеспечивают программирование на основе объекта домена и проверки со временем компиляции.
    • Увеличивают нагрузку при десериализации и сериализации.
    • Высокие накладные расходы при сборке мусора.
    • Разбивают комплексное создание кода на этапы.
  • Устойчивые распределенные наборы данных (RDD)
    • Вам необязательно использовать наборы RDD, если только вам не нужно создать пользовательский RDD.
    • Отсутствует оптимизация запросов через Catalyst.
    • Отсутствует комплексное создание кода.
    • Высокие накладные расходы при сборке мусора.
    • Необходимо использовать устаревшие API-интерфейсы Spark 1.x.

Выбор хранилища по умолчанию

При создании кластера Spark вы можете выбрать хранилище BLOB-объектов Azure или Azure Data Lake Storage в качестве хранилища кластера по умолчанию. Оба варианта предоставляют возможность долговременного хранения промежуточных кластеров. Это означает, что данные не будут автоматически удаляться при удалении кластера. Вы можете повторно создать промежуточный кластер и по-прежнему иметь доступ к данным.

Тип хранилища данных Файловая система Speed Промежуточный Варианты использования
хранилище BLOB-объектов Azure wasb: //url/ Standard Edition Да Промежуточный кластер
Хранилище BLOB-объектов (защищенное) wasbs: //url/ Standard Edition Да Промежуточный кластер
Azure Data Lake Storage 2-го поколения abfs: //url/ Более быстрая Да Промежуточный кластер
Azure Data Lake Storage 1-го поколения adl: //url/ Более быстрая Да Промежуточный кластер
Локальная система HDFS hdfs: //url/ Самая быстрая нет Интерактивный постоянно доступный кластер

Полный список вариантов хранилища см. в статье Сравнение вариантов хранения для использования с кластерами Azure HDInsight.

Использование кэша

Spark обеспечивает собственные механизмы кэширования, которые можно использовать с помощью различных методов, например .persist(), .cache() и CACHE TABLE. Такое встроенное кэширование эффективно при работе с небольшими наборами данных, а также в конвейерах ETL, где требуется кэшировать промежуточные результаты. Однако встроенное кэширование Spark в настоящее время не подходит для работы с секционированием, так как в кэшированнной таблице не хранятся секционированные данные. Более универсальным и надежным способом кэширования является кэширование на уровне хранилища.

  • Встроенное кэширование Spark (не рекомендуется)

    • Подходит для небольших наборов данных.
    • Не подходит для работы с секционированием, но в следующих выпусках Spark это может измениться.

  • Кэширование на уровне хранилища (рекомендуется)

  • Локальная система HDFS (рекомендуется)

    • Путь hdfs://mycluster.
    • Использует кэширование SSD.
    • Кэшированные данные будут потеряны при удалении кластера, что требует перестроения кэша.

Оптимизация сериализации данных

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

  • Сериализация Java, используемая по умолчанию.
  • Сериализация Kryo (новый формат), которая может ускорить сериализацию и сделать ее компактнее по сравнению с сериализацией Java. При использовании сериализации Kryo необходимо зарегистрировать классы в программе. Пока что поддерживаются не все сериализуемые типы.

Использование группирования

Группирование аналогично секционированию данных, но каждая группа может содержать не одно значение столбца, а набор. Этот метод подходит для секционирования большого количества значений (миллионов и более), например идентификаторов продукта. Контейнер определяется хэшированием ключа контейнера строки. Таблицы в контейнерах предлагают уникальную оптимизацию, так как в них хранятся метаданные о способах группирования и сортировки.

Ниже приведены некоторые расширенные функции группирования.

  • Оптимизация запросов на основе группирования метасведений.
  • Оптимизированные статистические функции.
  • Оптимизированные соединения.

Вы можете одновременно использовать секционирование и группирование.

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