подскажите, в какую сторону искать решение

spark on yarn, streaming - рабоатет стрим и всё хорошо, но если одна из машинок на кластере зависает, спарк выставляет всем екзекьютерам на ней DEAD и потом никогда больше не использует её. Даже если перезагрузить машину - в стрим она не возвращается.
для того что бы заново использовать эту машину - нужно полностью перезапускать стрим

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

если выводить yarn node -list то машина в списке есть но число контейнеров на ней 0

я бы копнул логи Node Manager'а

ибо очень похоже что NM отваливается и после этого спарк не будет на этой ноде разворачивать роботов

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

для самого спарк сабмит пробовал разные настройки, типа spark.yarn.am.attemptFailuresValidityInterval,
spark.yarn.executor.failuresValidityInterval, spark.yarn.max.executor.failures но все они не дают ожидаемый результат

более подробное рассмотрев происходящее - стало понятно, что на самом деле при падении машинок, спарк перераспределяет экзекьюторы и продолжает стрим
но теперь непонятно почему nodemanager не равномерно распределяет нагрузку на машины
в данном случае, почти все машины получают повышенную нагрузку, и число свободных ядер становится отрицательным, а одна из машин простаивает без нагрузки

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

спасибо, попробую

если просто восстановление после падения, то тут должно быть достаточно хранения оффсетов на стороне кафки

у нас был постгрес

аккумуляторы тоже хранили

проще руками двигать оффсеты

на уровне тестов. дальше понадобилось делать откат на конкретную точку по времени и тут пошли велосипеды

конкретно этот кейс не вряд ли - тут нам нужно было либо продолжать чтение, либо начинать его с последнего сообщения, но на флинке сброс оффсетов работал

больше возможностей в работе с потоками (например, более удобные оконные функции), быстрее обработка на уровне отдельной записи (поскольку спарк работает с mini batch, а flink с отдельными объектами) и в целом апи удобнее, чем в spark streaming, но готовых коннекторов меньше, более сырой, а с выходом structured streaming разница в удобстве совсем сокращается. я в свое время переписал просто кусок потоковой обработки с флинка на batch-обработку на спарке ради простоты и производительности. хотя есть пара  приложений, которые крутятся до сих пор на флинке и работают без проблем. имхо: если нужен более универсальный и распространенный инструмент, нет требований по доставке с задержкой менее 2 сек, то нужно использовать спарк. если есть время разобраться и допиливать иногда нужные интеграции , а задачи стоят только для потоковой обработки, то лучше флинк.

Не очень понял вопроса видимо, а чтл чекпоинты эту проблему не решают?

всем привет. я тут начал копаться со structured streaming и есть несколько вещей, которые меня смущают в его работе. кто-то уже использовал это в проде?

кто-то в https://t.me/hadoopusers точно пользовался // не реклама что-то такое помню