Подтвердить что ты не робот

Spark: длительная задержка между заданиями

Таким образом, мы запускаем искровое задание, которое извлекает данные и выполняет обширное преобразование данных и записывает их в несколько разных файлов. Все работает нормально, но я получаю случайные огромные задержки между завершением ресурсоемкой работы и началом следующей работы.

На рисунке ниже мы видим, что задание, которое было запланировано на 17:22:02, заняло 15 минут, что означает, что я ожидаю, что следующая работа будет намечена на 17:37:02. Однако следующая работа была назначена на 22:05:59, то есть +4 часов после успешной работы.

Когда я копаюсь в следующем интерфейсе искры задания, он показывает задержку планировщика <1 сек. Поэтому я не понимаю, откуда берется эта 4-часовая задержка.

enter image description here

(Spark 1.6.1 с Hadoop 2)

Обновлено:

Я могу подтвердить, что ответ Дэвида ниже о том, как обрабатываются операции ввода-вывода в Spark, немного неожидан. (Имеет смысл, что запись файла по сути "собирает" за кулисами перед тем, как записывать, учитывая порядок и/или другие операции.) Но меня немного смущает тот факт, что время ввода-вывода не входит во время выполнения задания. Полагаю, вы можете увидеть его на вкладке "SQL" в пользовательском интерфейсе spark, поскольку запросы по-прежнему выполняются даже при успешном выполнении всех заданий, но вы вообще не можете в них углубиться.

Я уверен, что есть и другие способы улучшения, но для меня было достаточно двух методов:

  1. уменьшить количество файлов
  2. установите для parquet.enable.summary-metadata значение false
4b9b3361

Ответ 1

Операции ввода-вывода часто сопровождаются значительными накладными расходами на главном узле. Поскольку эта работа не распараллелена, это может занять довольно много времени. И поскольку это не работа, она не отображается в пользовательском интерфейсе менеджера ресурсов. Некоторые примеры задач ввода-вывода, выполняемых главным узлом

  • Spark запишет во временные каталоги s3, затем переместит файлы, используя главный узел
  • Чтение текстовых файлов часто происходит на главном узле
  • При записи файлов паркета мастер-узел сканирует все файлы после записи, чтобы проверить схему

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

Обсуждение написания I/O Overhead с Parquet и s3

Обсуждение чтения I/O Overhead "s3 не файловая система"

Ответ 2

Проблема:

Я столкнулся с подобной проблемой при записи данных паркета на s3 с pyspark на EMR 5.5.1. Все работники закончили бы записывать данные во _temporary в выходной папке, а пользовательский интерфейс Spark показал бы, что все задачи выполнены. Но пользовательский интерфейс Hadoop Resource Manager не освободит ресурсы для приложения и не пометит его как завершенный. При проверке сегмента s3 казалось, что драйвер spark перемещает файлы 1 на 1 из _temporary в выходной _temporary который был очень медленным, и весь кластер простаивал, за исключением узла Driver.

Решение:

Решение, которое работало для меня, состояло в том, чтобы использовать класс EmrOptimizedSparkSqlParquetOutputCommitter AWS (EmrOptimizedSparkSqlParquetOutputCommitter), установив для свойства конфигурации spark.sql.parquet.fs.optimized.committer.optimization-enabled значение true.

например:

spark-submit....... --conf spark.sql.parquet.fs.optimized.committer.optimization-enabled = true

или же

pyspark....... --conf spark.sql.parquet.fs.optimized.committer.optimization-enabled = true

Обратите внимание, что это свойство доступно в EMR 5.19 или выше.

Результат:

После запуска задания spark на EMR 5.20.0 с использованием вышеприведенного решения, он не создал никакого _temporary и все файлы были напрямую записаны в выходной сегмент, поэтому задание завершилось очень быстро.

Для более подробной информации:
https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-s3-optimized-committer.html