Влияет ли размер файлов деталей на производительность Spark SQL?

Я пытаюсь запросить hdfs, в котором много файлов деталей (avro). Недавно мы внесли изменение, чтобы уменьшить параллелизм, и, таким образом, размер файлов деталей увеличился, размер каждого из этих файлов деталей находится в диапазоне от 750 МБ до 2 ГБ (мы используем потоковую передачу искр для записи даты в hdfs с 10-минутными интервалами, поэтому размер этих файлов зависит от объема данных, которые мы обрабатываем из восходящего потока). Число файлов деталей будет около 500. Мне было интересно, будет ли размер этих файлов деталей / количество файлов деталей играть какую-либо роль в производительности Spark SQL?

При необходимости я могу предоставить дополнительную информацию.


apache-spark apache-spark-sql spark-avro query-performance
person user3679686    schedule 29.11.2018    source источник
comment
В общем, чем больше файлы, тем лучше. Что меньше 2 ГБ?   -  person thebluephantom    schedule 29.11.2018
comment
Размер каждого файла детали составляет от 750 МБ до 2 ГБ, поэтому я упомянул, что размер файлов детали не превышает 2 ГБ.   -  person user3679686    schedule 29.11.2018
comment
Но это было расплывчатое заявление.   -  person thebluephantom    schedule 29.11.2018
comment
добавил дополнительную информацию к вопросу.   -  person user3679686    schedule 30.11.2018
comment
Может быть идея принять или проголосовать за ответы.   -  person thebluephantom    schedule 07.01.2019

Ответы (2)


arrow_upward
2
arrow_downward

HDFS, Map Reduce и SPARK предпочитают файлы большего размера, а не множество небольших файлов. У S3 тоже есть проблемы. Я не уверен, имеете ли вы здесь в виду HDFS или S3.

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

В общем, проблема с маленькими файлами, о которой есть что почитать. Например. https://www.infoworld.com/article/3004460/application-development/5-things-we-hate-about-spark.html. Чтобы было ясно, я фанат Spark.

person thebluephantom    schedule 29.11.2018

arrow_upward
2
arrow_downward

Как правило, чем меньше файлов, тем лучше,

Одна из проблем заключается в том, можно ли разделить файл и как это сделать.

  • Файлы, сжатые с помощью .gz, не могут быть разделены: вы должны читать от начала до конца, поэтому не более чем одному рабочему за раз назначается один файл (за исключением того, что около конца запроса и предположений может сработать второй). Используйте сжатие, например snappy, и все будет хорошо
  • очень маленькие файлы неэффективны, поскольку преобладают накладные расходы на запуск / фиксацию
  • в HDFS небольшие файлы создают нагрузку на namenode, поэтому операционная группа может быть недовольна
person stevel    schedule 30.11.2018