РУКОВОДСТВО ПО ИСПОЛНЕНИЮ ИСКРЫ

Fetch Failed Exception в Apache Spark: расшифровка наиболее распространенных причин

Большинство разработчиков Spark тратят много времени на устранение неполадок с ошибками выборки, наблюдаемыми во время операций перемешивания. Эта история послужит вам для наиболее распространенных причин исключения Fetch Failed Exception и покажет результаты недавнего опроса, проведенного для исключения.

Операции перемешивания являются основой почти всех заданий Spark, направленных на агрегацию, объединение или реструктуризацию данных. Во время операции перемешивания данные перемешиваются между различными узлами кластера с помощью двухэтапного процесса:

a) Запись в случайном порядке: задачи отображения в случайном порядке записывают данные, которые необходимо перемешать, в файл на диске, данные упорядочиваются в файле в соответствии с задачами сокращения в случайном порядке. Пачка данных тасования, соответствующая задаче уменьшения тасования, записанной задачей отображения тасования, называется блоком тасования. Кроме того, каждая из задач отображения тасования информирует драйвер о записанных данных тасования.

б) Чтение в случайном порядке: задачи Shuffle Reduce запрашивают драйвер о расположении их блоков в случайном порядке. Затем эти задачи устанавливают соединение с исполнителями, на которых размещены их блоки тасования, и начинают выборку требуемых блоков тасования. Как только блок получен, он доступен для дальнейших вычислений в задаче уменьшения.

Чтобы узнать больше о процессе перемешивания, вы можете обратиться к моей предыдущей истории под названием Выявление магии перемешивания Apache Spark.

Двухэтапный процесс перемешивания звучит просто, но требует больших усилий в работе, поскольку включает в себя сортировку данных, запись / чтение с диска и передачу по сети. Следовательно, всегда есть вопросительный знак относительно надежности операции перемешивания, и свидетельством этой ненадежности является часто встречающееся «исключение FetchFailed Exception» во время операции перемешивания. Большинство разработчиков Spark тратят много времени на устранение этого широко распространенного исключения. Сначала они пытаются выяснить основную причину исключения, а затем, соответственно, исправляют ее.

Исключение Fetch Failed Exception, сообщаемое в задаче уменьшения случайного воспроизведения, указывает на сбой при чтении одного или нескольких блоков перемешивания от исполнителей размещения. Отладка исключения FetchFailed довольно сложно, поскольку может возникнуть по нескольким причинам. Найти и узнать правильную причину очень важно, потому что это поможет вам установить правильное исправление, чтобы преодолеть Исключение.

Устранение неполадок сотен заданий Spark за последнее время я понял, что исключение Fetch Failed Exception в основном возникает по следующим причинам:

  • Недостаточно памяти кучи у исполнителей
  • Низкие накладные расходы памяти на исполнителей
  • Перемешать блок размером более 2 ГБ
  • Сеть TimeOut.

Чтобы понять частоту этих причин, я также недавно провел опрос в самой популярной группе LinkedIn на Spark, Apache Spark. К моему удивлению, довольно много людей приняли участие в опросе и представили свое мнение, что еще раз подтверждает тот факт, что люди часто сталкиваются с этим исключением в своих заданиях Spark. Вот результаты опроса:

Согласно результатам опроса, «Недостаточно памяти кучи на исполнителе» и «Перемешать блок размером более 2 ГБ» являются наиболее популярными причинами. Затем следуют «Тайм-аут сети» и «Низкие накладные расходы памяти на Executor».

Давайте подробно разберемся с каждой из этих причин:

«Недостаточно памяти кучи на Executor»: Эта причина указывает на то, что исключение Fetch Failed возникло из-за того, что Executor, на котором размещены соответствующие блоки перемешивания, потерпел крах из-за ошибки Java «Out of memory». «Ошибка нехватки памяти» может возникнуть, когда у исполнителя не хватает места в куче или когда сборщик мусора у него тратит больше времени на сборку мусора, чем на реальную полезную работу.

Чтобы сопоставить эту причину, вам необходимо проверить данные исполнителя хостинга (имя хоста / IP-адрес / порт), упомянутые в исключении Fetch Failed Exception. Как только вы получите сведения об исполнителе, вы можете заметить следующие сбои задач для исполнителей хостинга:

  • «ExecutorLostFailure» из-за кода выхода 143
  • «ExecutorLostFailure» из-за истечения времени ожидания пульса исполнителя.

Эти сбои задач в отношении исполнителей хоста указывают на то, что исполнитель, на котором размещены блоки перемешивания, был убит из-за ошибки Java «Недостаточно памяти». Кроме того, можно было явно подтвердить ошибку в журналах контейнера исполнителя. Поскольку исполнитель хоста был убит, размещенные блоки перемешивания не могли быть извлечены и, следовательно, могли привести к ошибкам извлечения исключений в одной или нескольких задачах сокращения перемешивания.

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

«Низкие накладные расходы памяти на Executor»: Эта причина указывает на то, что возникла исключительная ситуация Fetch Failed Exception, потому что Executor, на котором размещены соответствующие блоки перемешивания, вышел из строя из-за «Low memory overhead». Ошибка «Низкие накладные расходы памяти» возникает, когда объем физической ОЗУ исполнителя превышает указанные пределы физической памяти. Этот сценарий может произойти, когда память кучи исполнителя интенсивно используется, а также есть хороший спрос на память вне кучи.

Чтобы сопоставить эту причину, вам необходимо проверить данные исполнителя хостинга (имя хоста / IP-адрес / порт), упомянутые в исключении Fetch Failed Exception. Как только вы получите сведения об исполнителе, вы можете заметить следующий сбой задачи для исполнителей хостинга:

  • ‘ExecutorLostFailure, # ГБ из # ГБ физической памяти. Попробуйте увеличить spark.yarn.executor.Overhead ’

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

По результатам опроса, эта причина набрала самый низкий процент голосов. Но я был свидетелем большей части этой причины. Фактически, пропорция аналогична причине «Недостаточно памяти у исполнителя».

«Перемешать блок размером более 2 ГБ»: исключение Fetch Failed Exception с упоминанием «Слишком большой кадр», «Превышение размера кадра» или «размер, превышающий Integer.MaxValue» в качестве причины ошибки указывает на то, что соответствующая задача уменьшения перемешивания пытался получить случайный блок размером более 2 ГБ. В основном это происходит из-за ограничения Integer.MaxValue (2 ГБ) в абстракции структуры данных (ByteBuffer), используемой для хранения блока тасования в памяти.

Однако, начиная с версии 2.4 Spark, эта конкретная причина в значительной степени устранена.

По результатам опроса, эта причина получила второй по величине процент голосов. Но из-за этого я редко сталкивался с ошибкой Fetch Failed в своей работе.

«Сетевой тайм-аут»: выборка блоков в случайном порядке обычно повторяется настраиваемое количество раз (spark.shuffle.io.maxRetries) с настраиваемыми интервалами (spark.shuffle.io.retryWait). Когда все удаления исчерпаны при выборке блока тасования от его хост-исполнителя, в задаче уменьшения тасования возникает исключение Fetch Failed Exception. Эти исключения из-за сбоя выборки обычно относятся к категории «Тайм-аут сети».

Такие исключения Fetch Failed трудно коррелировать. Кроме того, эти исключения могут возникать из-за проблем с сетью или из-за перегруженности исполнителей, размещающих соответствующие блоки тасования.

По результатам опроса, эта причина получила третий по величине процент голосов. Я тоже часто был свидетелем этой причины.

Я надеюсь, что после прочтения этой статьи вы, должно быть, имеете четкое представление о различных причинах Fetch Failed Exceptions. Я планирую рассказать о возможных решениях каждой причины в отдельном рассказе. В случае, если вам нужно срочно исправить ошибку Fetch Failed Exception, вы можете оставить сообщение.

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

Если у вас есть отзывы или вопросы по этой истории, пишите в разделе комментариев. Надеюсь, вам это пригодится. Вот ссылка на другие опубликованные мной подробные истории об Apache Spark.