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

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

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

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

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

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

--- ОБНОВИТЬ ---

Пробовал писать на локальный диск, а не на s3a, симптомы те же - 2 из 32 задач на финальном этапе saveAsTextFile "зависают" на несколько часов:

введите здесь описание изображения


amazon-ec2 apache-spark spark-csv
person twiz911    schedule 18.11.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

person stevel    schedule 18.11.2016
comment
Привет, Стив. Большое спасибо за ответ. Да, я слышал о проблемах с переименованием, но наши 4 с лишним часа бездействия означали бы выходной файл размером 100 ГБ — мы ожидаем около 5 ГБ. К сожалению, восходящие и нисходящие процессы находятся вне нашего контроля, и оба используют CSV. Мы используем Spark 1.6. Возможно, нам следует попробовать обновиться до 2.0, если запись в HDFS, а затем загрузка не решит проблему? - person twiz911; 21.11.2016
comment
Я также попробовал слайды 21-22 на: slideshare.net/steve_l/apache -spark-and-object-stores, что не имело значения. - person twiz911; 21.11.2016
comment
вы можете попробовать обновление — оно того стоит по другим причинам (подсказка: DataFrames), но оно не меняет низкоуровневые соединения s3 или коммиттера вывода файлов. Пока загрузка заблокирована, выполните команду kill -QUIT, чтобы отобразить стеки всех заблокированных потоков. - person stevel; 21.11.2016
comment
Привет, Стив. Спасибо за совет. Мы изменили запись в локальную файловую систему, и все равно последние 2 задачи зависают в работе в течение нескольких часов, пока коробка ничего не делает. - person twiz911; 22.11.2016
comment
Просто интересно, есть ли у вас или у кого-нибудь другие идеи? Большое спасибо за ваше время и совет. - person twiz911; 25.11.2016
comment
Вы находитесь в режиме диагностики. включи дебиггинг и посмотри что творится в логах; используйте jstack, чтобы увидеть, чем занимаются потоки. - person stevel; 25.11.2016
comment
С тех пор мы обновились до Spark 2.0.2, но по-прежнему имеем ту же проблему: две задачи на этапе 32 задач никогда не завершаются, а коробка простаивает в течение нескольких часов. - person twiz911; 30.11.2016

arrow_upward
0
arrow_downward

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

spark.speculation=true

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

Дайте нам знать, если это решит проблему.

person WestCoastProjects    schedule 18.11.2016
comment
Спасибо. Я пробовал это, но симптомы те же, без заметных изменений. - person twiz911; 21.11.2016