Отказоустойчивость Spark для широких зависимостей

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

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

Чего на самом деле недостаточно для понимания происходящего.

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


apache-spark distributed-computing fault-tolerance
person Dezi    schedule 18.04.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Зависимости RDD на самом деле связаны с разделами и тем, как они создаются из разделов других RDD.

Широкая зависимость означает, что данные, необходимые для создания раздела, получены из нескольких разделов (из одного или разных RDD). Каждому разделу назначается исполнитель.

Теперь предположим, что мы соединяем два RDD R1 и R2, которые имеют разделы n и m соответственно. Кроме того, для простоты предположим, что и R1, и R2 были рассчитаны (n x m) разными исполнителями. Мы собираемся создать третий RDD R3, объединив R1 и R2.

При вычислении R3 предположим, что узел, содержащий x исполнителей (из (n x m) исполнителей), по какой-то причине вышел из строя. Это не влияет на остальных исполнителей и их данные на других узлах.

Затрагиваются только те разделы в R3, которые должны были быть созданы из данных этого отказавшего исполнителя x. И заново создаются только те разделы x.

Доступно более подробное визуальное объяснение здесь

Обновлено: о кэшировании Spark Приведенные ниже URL-адреса должны помочь вам понять всю функцию сохранения Spark.

person code    schedule 03.05.2017
comment
Возвращаясь к примеру, с которого я начал: сортировка. Если раздел RDD R2, созданный путем сортировки R1, потерян, есть ли способ избежать сортировки всего RDD R1, чтобы получить отсутствующий раздел R2? Или из приведенного вами примера: если раздел G потерян, что точно здесь пересчитывается? Без сохранения какой-либо дополнительной информации во время groupBy и соединения, я думаю, все должно быть пересчитано? - person Dezi; 04.05.2017
comment
Ты прав! Но Spark отслеживает всю родословную для каждого из разделов и RDD, поэтому нет необходимости повторно выполнять все нетронутые разделы. Я сомневаюсь в случае сортировки, хотя. Вот где в игру вступают кэширование и постоянство Spark. Чтобы избежать ненужного пересчета RDD в случае сбоев. - person code; 04.05.2017
comment
Значит, Spark кэширует некоторые данные, которые можно использовать для восстановления разделов после сортировки? Вы не знаете, где я могу найти информацию об этом? - person Dezi; 04.05.2017
comment
Я обновил ответ полезными ресурсами. Дайте мне знать, если этих ссылок было достаточно - person code; 04.05.2017
comment
Спасибо! Spark может восстановиться после сбоя после сортировки, если отсортированный RDD сохраняется с использованием одного из уровней хранения _2. Я предполагаю, что это означает, что без каких-либо действий со стороны пользователя Spark придется пересчитывать все RDD, ведущие к отсортированному RDD. - person Dezi; 05.05.2017