Spark Executor низкая производительность при записи данных в паркет - PullRequest
0 голосов
/ 28 сентября 2018

Версия Spark: 2.3 hadoop dist: azure Hdinsight 2.6.5 Платформа: Azure Хранилище: BLOB

Узлы в кластере: 6 Экземпляры исполнителя: 6 ядер на исполнителя: 3 Память на исполнителя: 8 ГБ

Попытка загрузить CSV-файл (размер 4,5 г - 280 столбцов, 2,8 млн строк) в формате Azure BLOB-объектов (wasb) для форматирования паркета через фрейм данных spark на той же учетной записи хранения.Я перераспределил файл с другим размером, то есть 20, 40, 60, 100, но столкнулся со странной проблемой, когда 2 из 6 исполнителей, которые обрабатывают очень маленькое подмножество записей (<1%), продолжают работать в течение 1 часа или около тогои в конце концов завершить.</p>

Вопрос:

1) разделы, обрабатываемые этими двумяу исполнителей меньше всего записей для обработки (менее 1%), но на это уходит почти час.Что является причиной этого.Это противоположно сценарию перекоса данных?

2) папки локального кэша на узлах, на которых работают эти исполнители, заполняются (50-60 ГБ).Не уверен в причине этого.

3) Увеличение количества разделов приводит к сокращению общего времени выполнения до 40 минут, но хотелось бы узнать причину низкого уровня только с этими двумя исполнителями.

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

1 Ответ

0 голосов
/ 19 февраля 2019

Какую кластерную среду hadoop вы используете?

1) Ответ: Вы поете файл partitionColumnBy при записи файла?еще попробуйте и проверьте.

2) Ответ: увеличьте количество разделов, т.е. используйте "spark.sql.shuffle.partitions"

3) Ответ: Требуется более конкретная информация, например, данные примеров ии т.д., чтобы дать ответ.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...