Поделиться через

Оптимизация хранилища данных для 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 в качестве хранилища по умолчанию для этого кластера. Оба варианта позволяют вам долговременно хранить переходные кластеры. Поэтому данные не удаляются автоматически при удалении кластера. Вы можете повторно создать временный кластер и по-прежнему получить доступ к данным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on