Spark 2.x - сжатие gzip и snappy для файлов паркета - PullRequest
Новая
       50

Spark 2.x - сжатие gzip и snappy для файлов паркета

0 голосов
/ 22 октября 2018

Я (впервые) пытаюсь перераспределить данные, с которыми работает моя команда, для повышения производительности наших запросов.Наши данные в настоящее время хранятся в многораздельных файлах .parquet, сжатых с помощью gzip.Я читал, что использование snappy вместо этого значительно увеличит пропускную способность (мы ежедневно запрашиваем эти данные для нашего анализа).Я все еще хотел сравнить два кодека, чтобы увидеть разрыв производительности своими глазами.Я написал простое (Py) Spark 2.1.1 приложение для проведения некоторых тестов.Я сохранил 50 миллионов записей в памяти (десериализованных) в одном разделе, записал их в один файл паркета (в HDFS), используя разные кодеки, а затем снова импортировал файлы, чтобы оценить разницу.Моя проблема в том, что я не вижу существенной разницы как для чтения, так и для записи.

Вот как я записывал свои записи в HDFS (то же самое для файла gzip, просто замените 'snappy' на 'gzip').): 

persisted_records.write\
.option('compression', 'snappy')\
.mode("overwrite")\
.partitionBy(*partition_cols)\
.parquet('path_to_dir/test_file_snappy')

И вот как я читаю мой единственный файл .parquet (то же самое для файла gzip, просто замените 'snappy' на 'gzip'): 

df_read_snappy = spark.read\
.option('basePath', 'path_to_dir/test_file_snappy')\
.option('compression', 'snappy')\
.parquet('path_to_dir/test_file_snappy')\
.cache()

df_read_snappy.count()

Я посмотрел на продолжительность в интерфейсе Spark.Для информации, сохраненные (десериализованные) 50 миллионов строк составляют 317,4 млн.После записи в один файл паркета файл весит 60,5M и 105,1M с использованием gzip и snappy соответственно (это ожидается, поскольку gzip должен иметь лучшую степень сжатия).Spark тратит 1,7 минуты (gzip) и 1,5 минуты (snappy) для записи файла (один раздел, поэтому одно ядро ​​должно выполнять всю работу).Время чтения составляет 2,7 мин (gzip) и 2,9 мин (snappy) на одном ядре (поскольку у нас есть один блок файла / HDFS).Вот чего я не понимаю: где более высокая производительность snappy?

Что-то не так сделал?Является ли мой «протокол тестирования» ошибочным?Прирост производительности здесь, но я не смотрю на правильные метрики?

Я должен добавить, что я использую конф по умолчанию Spark.Я ничего не изменил, кроме указания количества исполнителей и т. Д.

Большое спасибо за вашу помощь!

Примечание: версия Spark parquet jar - 1.8.1

...