надо забить просто на пар коллекции)

есть компат с ними кстати

официальный

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

шедулер назначит пересчёт партиций, шафл файлы которых утрачены, и выполнение продолжится

это будет видно в Spark UI, стейджи будут ретраиться, но не полностью, а только несколько тасков

Привет, Володя!

с этого, конечно, мне стоило начать ))

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

редюсер - что ты имеешь в виду под этим термином?

@Ryabusha и тебе )

Экзекьютер в который льются пошафленые данные

тоже так думаю, мне кажется видел такое иногда

на лонг раннинг жобах

давно ток было ничего не помню и это не правда

Это может быть тот же самый экзекутор, который эти данные записал. Всё дело в том, какой стейдж он выполняет. И к моменту начала стейдж все шафл-файлы уже записаны предыдущим стейджем, ExchangeCoordinator (тут я могу ошибаться с названием класса, если что, потом исправлю) держит инфу о файлах, и знает, какие надо пересчитать. Проще говоря, спарк готов к тому, что некоторые экзекуторы будут убиты или погашены динамической аллокацией

И есть, наверняка, какое-то максимальное число попыток пересчитать утерянные шафл-файлы?

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

В пределах стейджа это число 4 по умолчанию, между стейджами - не могу сейчас точно сказать