Устранение неполадок отставших в вашем приложении Spark

Отставание в вашем приложении Spark влияет на общую производительность приложения и тратит ресурсы премиум-класса.

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

Что такое задержка в приложении Spark?

Отставание относится к очень-очень медленно выполняющейся Задаче, принадлежащей определенному этапу приложения Spark (Каждый этап в Spark состоит из одной или нескольких Задач, каждая из которых вычисляет один раздел из общего числа разделов, назначенных для этапа) . Задача отставшего требует исключительно много времени для завершения по сравнению со средним или средним временем, затрачиваемым другими задачами, принадлежащими той же стадии. Несколько отставших в задании Spark могут присутствовать либо на одном этапе, либо на нескольких этапах.

Как страдают отставшие?

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

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

Как их идентифицировать?

Присутствие отставших можно почувствовать, когда вы заметите, что индикатор выполнения этапа (доступный в пользовательском интерфейсе Spark), соответствующий выполненному этапу, застревает в конце. Чтобы подтвердить то же самое, вы можете открыть подробные сведения, относящиеся к этапу, со сводкой метрик задач, выполненных на этапе. Если показатель «Задача» показывает, что «максимальная продолжительность» среди выполненных задач исключительно выше, чем значение «медиана» или «75-й процентиль», то это указывает на вероятность отставания в соответствующем задании. Вот пример, показывающий моментальный снимок метрик задачи на этапе Задания, вызванном отставшим.

На приведенном выше снимке ясно видно, что соответствующая стадия пострадала от отставших, поскольку «максимальная» продолжительность задачи, которая составляет 28 минут, исключительно выше, чем значение «75-го процентиля», которое составляет всего лишь скудные 14 секунд. Кроме того, отдельных отставших можно определить в подробном разделе описания задачи на странице, посвященной конкретному этапу. Все задачи, продолжительность выполнения которых превышает значение «75-го процентиля», могут быть отнесены к отстающим по этапу.

Причины отставания. Вот некоторые из распространенных причин проблем, связанных с отставанием:

Неправильное разбиение: это одна из распространенных и наиболее частых причин отставания. Перекосное разбиение приводит к перекошенному разбиению (асимметрии по отношению к размеру данных, отображаемому в каждый из разделов). И, если данные раздела напрямую отражают данные, которые должны быть вычислены, то искаженные разделы приводят к асимметричному распределению времени вычислений между назначенными для них задачами, что приводит к отставанию.

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

Неравномерное разбиение на разделы может также произойти, когда группа неразделимых файлов, искаженных по размеру, считывается в набор данных / RDD.

Искаженные вычисления: это еще одна распространенная причина, по которой возникают отставания. Если вы выполняете специальные вычисления для данных разделов, может случиться так, что вычисления будут искажены между разделами из-за зависимости от определенных атрибутов / свойств данных (находящихся в разделе), даже если данные между разделами распределены достаточно хорошо. Теперь, когда вычисления искажаются, это снова может потенциально привести к отставанию.

Несбалансированные / асимметричные вычисления могут возникать в сценариях, где вычислительная работа в вычислительной программе раздела прямо пропорциональна определенным свойствам записей данных в разделе. Примером может служить случай, когда набор данных указывает на коллекцию объектов FileWrappers, и в конкретном разделе этого набора данных все соответствующие объекты FileWrapper относятся к относительно большим файлам по сравнению с объектами FileWrapper, находящимися в других разделах. Таким образом, конкретный раздел в примере может вызвать отставание.

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

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

Большее количество ядер на исполнителя. Выделение большего количества ядер на исполнителя в диапазоне от 4 до 8 также может иногда приводить к потенциальным отставаниям. Это может произойти из-за возможности одновременного выполнения сложных вычислительных / ресурсоемких задач на всех ядрах исполнителя. Ситуация одновременного выполнения может привести к борьбе за общие ресурсы, такие как память, внутри исполнителя хоста, что может привести к событиям снижения производительности, таким как интенсивная сборка мусора, что, в свою очередь, потенциально может привести к отставанию на этапе.

Возможные средства правовой защиты:

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

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

Увеличенное количество разделов: увеличение количества разделов может уменьшить величину потери производительности, налагаемой отставшими. Однако это помогло бы лишь до определенной степени. (Чтобы узнать больше о настройке разбиения Spark, вы можете обратиться к Руководство по разбиению на разделы Spark: подробное объяснение разбиения Spark »)

Включение функции предположения Spark: функция предположения Spark, которая активно определяет медленно выполняющиеся задачи, убивает их и снова запускает те же самые, при желании может быть включена для борьбы с отставшими. Это помогает справиться с отставанием, которое возникает из-за нехватки ресурсов у исполнителей или из-за медленного чтения / записи диска / сети на сервере хостинга. По умолчанию функция отключена, ее можно включить, установив конфигурацию spark, ‘ spark. спекуляция ’ в истинное значение. Кроме того, функция спекуляции также предоставляет различные другие ручки (с точки зрения конфигурации искры) для точной настройки идентификации отставшего и убивающего поведения. Вот описание этих ручек:

a) spark.speculation.interval (по умолчанию: 100 мс): как часто Spark будет проверять наличие заданий для предположений. Вам не нужно прикасаться к тому же.

б) spark.speculation.multiplier (по умолчанию: 1.5): во сколько раз задача медленнее, чем медиана, которая должна рассматриваться для предположений. Это используется в качестве критерия для выявления отставших и может быть настроено в зависимости от поведения приложения Spark.

c) spark.speculation.quantile (по умолчанию: 0,75): часть задач, которые должны быть выполнены, прежде чем спекуляция будет включена для определенного этапа. Это используется, чтобы решить, когда начать атаку и убить отставших, а затем повторно запустить их, это также можно настроить в зависимости от поведения приложения Spark.

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

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

Как видно из снимка, максимальное время было уменьшено до 1,7 минуты с 28 минут ранее. Исходная статья была опубликована здесь.

В случае, если вы столкнулись с отставшим (и) по другой причине, пожалуйста, укажите в комментарии о том же самом и о первопричине / способе устранения, которые вы предприняли для их устранения. Также вы можете принять участие в опросе отставших:

Https://www.linkedin.com/feed/update/urn:li:ugcPost:6736664776048418816/