Spark Stand Alone - Last Stage saveAsTextFile занимает много времени, используя очень мало ресурсов для записи файлов CSV-файлов

Question

Мы запускаем Spark в автономном режиме с 3 узлами в 240-дюймовом «большом» EC2-окне для объединения трех файлов CSV, которые считываются в DataFrames для JavaRDD в выводить файлы частей CSV на S3 с помощью s3a.

Мы можем видеть из пользовательского интерфейса Spark, первые этапы чтения и слияния, чтобы обеспечить окончательный запуск JavaRDD на 100% CPU, как и ожидалось, но заключительный этап, записываемый в виде файлов CSV с использованием saveAsTextFile at package.scala:179, «застревает» в течение многих часов 2 из 3 узлов с 2 из 32 задач, занимающих часы (коробка находится на 6% CPU, память 86%, Network IO 15kb/s, Disk IO 0 на весь период).

Мы читаем и записываем несжатый CSV (мы обнаружили, что несжатый был намного быстрее, чем CSV с CSV) с re partition 16 на каждом из трех входных DataFrames и не коушинг записи.

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

Большое спасибо

--- UPDATE ---

Я пытался писать на локальный диск, а не S3A и симптомы одинаковы - 2 из 32 задач на заключительном этапе saveAsTextFile «застревает "в течение нескольких часов:

Answer 1

Я видел подобное поведение. В октябре 2016 года в HEAD имеется исправление ошибки, которое должно иметь значение , возможно,. Но теперь вы можете включить

spark.speculation=true 

в SparkConf или в spark-defaults.conf.

Сообщите нам, если это смягчит проблему.

Answer 2

Если вы пишете на S3, через s3n, s3a или иначе, не устанавливайте spark.speculation = true, если вы не хотите подвергать риску поврежденный выход. Я подозреваю, что последний этап процесса заключается в переименовании выходного файла, который в хранилище объектов включает в себя копирование лотов (много GB?) Данных. Переименование происходит на сервере, при этом клиент просто держит соединение HTTPS открытым до завершения. Я бы оценил время переименования S3A примерно в 6-8 мегабайт в секунду ... будет ли этот номер связан с вашими результатами?

Запись на местный HDFS затем, затем, выгрузка результатов.

1. сжатие gzip не может быть разделено, поэтому Spark не будет назначать части обработки файла различным исполнителям. Один файл: один исполнитель.
2. Попробуйте избежать CSV, это уродливый формат. Embrace: Avro, Parquet или ORC. Avro отлично подходит для других приложений, которые могут транслироваться, а другие лучше для последующей обработки в других запросах. Значительно лучше.
3. И подумайте о сжатии файлов в формате lzo или snappy, оба из которых можно разделить.

смотри также слайды 21-22 на: http://www.slideshare.net/steve_l/apache-spark-and-object-stores