Правильный размер файла паркета при хранении в S3? - PullRequest
Новая
       29

Правильный размер файла паркета при хранении в S3?

0 голосов
/ 22 января 2019

Я читал несколько вопросов по этой теме, а также несколько форумов, и во всех них, похоже, упоминается, что каждый из полученных .parquet файлов, выходящих из Spark, должен иметь размер 64 МБ или 1 ГБ, но все же можетЯ не думаю, какие сценарии относятся к каждому из этих размеров файлов, и причины, помимо HDFS, разделяют их на блоки по 64 МБ.

Мой текущий сценарий тестирования следующий: 

dataset
  .coalesce(n) # being 'n' 4 or 48 - reasons explained below.
  .write
  .mode(SaveMode.Append)
  .partitionBy(CONSTANTS)
  .option("basepath", outputPath)
  .parquet(outputPath)

В настоящее время я обрабатываю от 2,5 до 3 ГБ ежедневных данных, которые будут разбиты и сохранены в ежедневные сегменты в год. Причины, по которым 'n' равно 4 или 48, просто для целей тестирования , так как я заранее знаю размер своего набора тестирования, я стараюсь получить число, максимально приближенное к 64 МБ или 1 ГБ.Я не реализовал код для буферизации необходимых данных до тех пор, пока не получу точный размер, который мне нужен до сохранения.

Поэтому мой вопрос здесь ...

Должен ли я взять размер так много весли я не планирую использовать HDFS и просто хранить и извлекать данные из S3?

А также, какой оптимальный размер для ежедневных наборов данных составляет около 10 ГБ максимум , если япланируете использовать HDFS для хранения моих полученных файлов .parquet?

Любой другой совет по оптимизации был бы очень признателен!

1 Ответ

0 голосов
/ 22 января 2019

Вы можете контролировать размер разделения файлов паркета, при условии, что вы сохраняете их с разделяемым сжатием, например snappy . Для разъема s3a просто установите fs.s3a.block.size на другое количество байтов.

Меньший размер сплита

  • Больше рабочих могут работать с файлом одновременно. Ускорение, если у вас есть свободные рабочие.
  • Дополнительные работы по планированию накладных расходов при запуске, начало обработки, выполнение задач
  • Создает больше файлов из вывода, если вы не переделите.

Маленькие файлы против больших файлов

Маленькие файлы:

  • вы получите этот небольшой сплит, хотите вы этого или нет.
  • , даже если вы используете нерасщепляемое сжатие.
  • занимает больше времени для просмотра списка файлов. Перечисление деревьев каталогов на s3 очень медленно
  • невозможно запросить больший размер блока, чем длина файла
  • проще сохранить, если ваш клиент s3 не выполняет инкрементную запись в блоки. (Hadoop 2.8+ делает, если вы установите spark.hadoop.fs.s3a.fast.upload true.

Лично и это мнение, и некоторые ориентиры - но не с вашими запросами

Запись

  • сохранить в больших файлах.
  • с мгновенно.
  • более мелкие + широкие деревья каталогов над глубокими и узкими

Чтение

  • игра с разными размерами блоков; обрабатывать как минимум 32-64 МБ
  • Hadoop 3.1, используйте коммиттеры с нулевым переименованием. В противном случае переключитесь на v2
  • если ваш разъем FS поддерживает это, убедитесь, что включен случайный ввод-вывод (hadoop-2.8 + spark.hadoop.fs.s3a.experimental.fadvise random
  • сохранить в больших файлах через .repartion().
  • Следите за тем, сколько данных вы собираете, так как очень легко запустить большие счета из-за хранения большого количества старых данных.

см. Также Улучшение производительности Spark с S3 / ADLS / WASB

...