Оптимальный размер файла и размер паркетного блока - PullRequest
Новая
       10

Оптимальный размер файла и размер паркетного блока

0 голосов
/ 23 мая 2019

У меня около 100 ГБ данных в день, которые я записываю в S3 с помощью Spark.Формат записи - паркет.Приложение, которое пишет это, запускает Spark 2.3

. Данные объемом 100 ГБ дополнительно разбиваются, где самый большой раздел составляет 30 ГБ.Для этого случая давайте просто рассмотрим раздел размером 30 ГБ.

Мы планируем перенести все эти данные и переписать их на S3 в Spark 2.4.Изначально мы не определяли размер файла и размер блока при записи в S3.Теперь, когда мы собираемся переписать все, мы хотим принять во внимание оптимальный размер файла и размер блока паркета.

  1. Каков оптимальный размер файла для записи в S3 в паркете?
  2. Можем ли мы записать 1 файл размером 30 ГБ и паркетом размером 512 МБ?Как будет работать чтение в этом случае?
  3. То же, что # 2, но размер паркетного блока равен 1 ГБ?

1 Ответ

0 голосов
/ 23 мая 2019

Прежде чем говорить о паркетной стороне уравнения, нужно рассмотреть одну вещь - как данные будут использоваться после сохранения их в паркет. Если он будет часто читаться / обрабатываться, вы можете подумать о том, каковы шаблоны доступа, и решить соответствующим образом разделить его. Одним из распространенных шаблонов является разбиение по дате, поскольку большинство наших запросов имеют временной диапазон. Правильное разбиение ваших данных окажет гораздо большее влияние на производительность при использовании этих данных после их записи.

Теперь, на Parquet, эмпирическое правило заключается в том, что размер блока паркет должен быть примерно равным размеру базовой файловой системы. Это важно, когда вы используете HDFS, но это не имеет большого значения, когда вы используете S3.

Опять же, размер паркетного блока учитывает, как вы читаете данные. Поскольку паркетный блок должен быть в основном реконструирован в памяти, чем он больше, тем больше памяти требуется в нисходящем направлении. Вам также понадобится меньше работников, поэтому, если у ваших нижестоящих работников достаточно памяти, у вас могут быть большие паркетные блоки, так как это будет немного более эффективно.

Однако для лучшей масштабируемости обычно лучше иметь несколько меньших объектов - особенно в соответствии с некоторой схемой разбиения - по сравнению с одним крупным объектом, который может выступать в качестве узкого места производительности, в зависимости от вашего варианта использования.

Подводя итог:

  • больший размер паркетного блока означает немного меньший размер файла (поскольку сжатие работает лучше для больших файлов), но больший объем памяти при сериализации / десериализации
  • оптимальный размер файла зависит от ваших настроек
  • если вы храните 30 ГБ с размером паркетного блока 512 МБ, так как Parquet - это разделяемая файловая система, и в искре используется HDFS getSplits(), на первом этапе вашей работы с искрой будет 60 задач. Они будут использовать выборки из байтового диапазона, чтобы параллельно получать разные части одного и того же объекта S3. Тем не менее, вы получите более высокую производительность, если разбить ее на несколько более мелких (желательно разделенных) объектов S3, поскольку они могут быть записаны параллельно (один большой файл должен быть записан последовательно), а также, скорее всего, будут иметь лучшую производительность чтения при доступе большое количество читателей.
...