Spark иногда запускает вторую попытку задачи, которая ещё не завершилась. Разбираем смысл спекулятивного выполнения, его цену и причины, по которым оно не помогает.
Большинство задач закончились, одна ещё работает
Представим обработку большой пачки документов. Почти все участники закончили свои части, но последний заметно отстаёт. Общий результат пока нельзя собрать. Если дело в случайно медленном рабочем месте, можно поручить ту же часть другому участнику и принять первый успешно полученный результат.
В Spark похожая идея называется спекулятивным выполнением. Спекуляция здесь означает предположение: ещё одна попытка, возможно, завершится раньше. Это не обязательный повтор всей работы и не автоматическое исправление её логики. Разбираем отдельную ситуацию — повтор медленной задачи, которая ещё выполняется, а не повтор после уже подтверждённой ошибки.
Две попытки одной части
В документации Apache Spark механизм описан как повторный запуск задач, которые работают медленно относительно других в этапе. Этап — группа связанных задач внутри вычисления. Возможность применяется только при соответствующей настройке; считать её постоянно включённой в любой системе нельзя.
Microsoft поясняет, что дополнительная попытка запускается на другом узле. Когда одна из попыток успешно заканчивает работу, другую останавливают. Задача остаётся одной по смыслу, но попыток её исполнения становится две. Именно это различие помогает читать журнал и не принимать каждый повтор за новый пользовательский запрос.
Условный пример времени ожидания
Допустим, основная часть задач закончилась к первой минуте. Одна продолжает работать. На третьей минуте система запускает дополнительную попытку этой же части, и через минуту та успешно заканчивается. Результат становится доступен на четвёртой минуте от начала наблюдения. Всё это вымышленные времена, выбранные для объяснения последовательности, а не настройки Spark.
Первоначальная попытка при этом уже потратила ресурсы до появления результата. Поэтому сокращение ожидания, если оно произошло, не равно уменьшению общего объёма вычислений. Мы также не знаем, когда закончилась бы первая попытка без вмешательства. Чтобы оценить пользу в реальной системе, нужны наблюдения, а не одно красивое сравнение условных минут.
Когда повтор сталкивается с той же причиной
Если последней задаче досталось значительно больше данных, новое рабочее место может получить ту же тяжёлую часть. Тогда ещё одна попытка не устранит перекос. В руководстве Microsoft это отдельно названо ограничением: повтор расходует дополнительные ресурсы, а неравномерность данных требует собственного разбора.
Аналогичная осторожность нужна, когда обе попытки ждут общий медленный источник. Это уже вывод из устройства нашего условного примера: дублирование читателя не делает единственный источник быстрее. Прежде чем рассчитывать на механизм, полезно различить случайное отставание отдельного исполнителя и закономерно более трудную часть. Сам факт наличия второй попытки не раскрывает причину задержки.
Почему условия нельзя свести к одному числу
Spark учитывает длительность задач и готовность других задач этапа, а конкретные правила зависят от конфигурации и версии. Для первого знакомства не требуется запоминать значения параметров. Важно понять принцип: система должна получить основания считать задачу отстающей, а дополнительной попытке нужны доступные ресурсы.
Если этап состоит из очень коротких задач, расходы на повтор могут оказаться существенными относительно оставшейся работы. Если все исполнители заняты, дополнительная попытка тоже не появляется из ничего. Поэтому решение о применении механизма следует принимать по наблюдаемой нагрузке. Обещание «включим повторы и всё ускорится» не учитывает ни цену дублирования, ни характер задержки.
Что проверить в результате и интерфейсе
В интерфейсе наблюдения Spark есть сведения о задачах и попытках выполнения. Для разбора полезно найти исходную задачу, время появления второй попытки и состояние обеих. Затем уточнить, что произошло с общим временем и не возникли ли дополнительные ошибки.
Отдельный вопрос — безопасность повторения действий. Microsoft предупреждает о возможности дубликатов в определённых сочетаниях повторов и отказов. Команда должна проверить, не приведёт ли повторная обработка к повторному нежелательному результату. Например, внешнее уведомление нельзя считать безопасным только потому, что оно отправляется из вычислительной задачи. Для новичка полезный итог разбора — объяснить, что именно повторилось, почему это произошло и какие ограничения остались.
Следующий шаг
На курсе «PySpark для инженеров и аналитиков данных» можно знакомиться с выполнением обработки данных последовательно. При изучении наблюдайте не только итоговое время, но и связь между задачей, её попытками и полученным результатом.
