#apache-spark #apache-spark-sql #compressed-files
#apache-spark #apache-spark-sql #сжатые файлы
Вопрос:
Я запускаю свою оболочку spark с помощью команды «start_pyspark_shell» и предоставляю параметры cli как — 4 исполнителя, 2 ядра на исполнителя и 4 ГБ памяти для рабочих узлов и 4 ГБ для главного
Хранилище: HDFS
Входной файл: сжатый.csv.gz файл размером 221,3 МБ (2 блока на HDFS) и
версия Spart: 2.4.0
Задача проста — подсчитать количество записей в файле. Единственная загвоздка в том, что это сжатый файл. Я загрузил файл с помощью
df = spark.read.format("com.databricks.spark.csv").load(hdfs_path)
Когда я это сделал df.count() , я вижу, что существует единственная задача исполнителя и, вероятно, ожидается (?), Поскольку я работаю со сжатым файлом, который не может быть разделен и будет обрабатываться с помощью одного раздела?
Я проверил количество разделов — df.rdd.getNumPartitions() и он вернул 1, вероятно, как и ожидалось.
Время обработки составляло около 15-17 секунд при многократном выполнении одной и той же команды.
Я думаю, мы можем заключить, что здесь не было большого параллелизма для вышеупомянутой обработки?
Теперь я попытался сделать df.repartition(10).count() с ожиданием, что данные будут перераспределены на 10 новых разделов и, возможно, на рабочих узлах. Я мог видеть, что количество ЗАДАЧ теперь соответствует количеству разделов, которые я указываю. Я надеялся на некоторое улучшение производительности с точки зрения времени выполнения. Теперь оказалось, что прошло 25-26 секунд.
Когда я использовал .repartition(20) , он работал более 4 минут, и мне пришлось его отключить.
Производительность снижается. Я сделал что-то не так или пропустил какой-либо шаг для повышения производительности?
Примечание: Я видел несколько хороших существующих сообщений по этому вопросу, но все еще не получил ясности. Следовательно, публикуем новый запрос.
Комментарии:
1. можете ли вы проверить в пользовательском интерфейсе Spark, запущены ли все задачи или запущена только одна, а остальные находятся только в dead_state . пожалуйста, проверьте статус задач один раз.
2. также проверьте временную шкалу событий spark в spark UI для вашей работы и проверьте, какая фаза занимает больше времени.
Ответ №1:
Сжатые файлы, похоже, загружены в один раздел на одном исполнителе. При попытке повторного разделения мы получаем больше задач, выполняющихся параллельно на разных рабочих узлах, однако повторное разделение также требует дополнительного времени для перетасовки / копирования данных на несколько рабочих узлов.
Это, по-видимому, является причиной увеличения времени обработки.
Вывод: а) Если задача / действие простое, не стоит повторно разделять данные сжатого файла. б) Если нам предстоит много обработки в будущем, стоимость повторного разделения составляет только один раз, но могут быть использованы несколько операций обработки, и это стоит дополнительного времени обработки.