Spark
Средний уровеньКак развернуть задачу Spark — client mode или cluster mode?
У spark-submit есть ровно один флаг, решающий, где запускается драйвер — и ошибиться с ним не значит громко упасть, это значит, что выживание вашей задачи начинает зависеть от того, от чего не должно.
Каждый деплой Spark запускает процесс драйвера и некоторое число executor'ов — client mode и cluster mode расходятся только в том, где живёт драйвер. Эта единственная разница имеет более серьёзные последствия, чем кажется.
Что на самом деле переключает --deploy-mode
В client mode драйвер запускается на той машине, которая вызвала spark-submit — ваш
ноутбук, сервер notebook'а, раннер CI — и только executor'ы работают на кластере. В cluster mode
менеджер кластера (YARN, Kubernetes, standalone) запускает драйвер как отдельный процесс на узле кластера,
так что машина, запустившая spark-submit, может полностью отключиться, как только задача
принята.
Почему client mode — неверный выбор по умолчанию для чего-либо без присмотра
Драйвер координирует каждую задачу и хранит финальное состояние job — если он умирает, умирает и job, независимо от того, насколько здоровы executor'ы. В client mode это означает, что уснувший ноутбук, перезапустившееся ядро notebook'а или таймаут CI-раннера убивают Spark-задачу, которая иначе работала бы нормально. Это не теоретический краевой случай — это самый частый способ, которым начинается тикет «почему эта задача просто исчезла без ошибки». Client mode — действительно правильный выбор для интерактивной работы, notebook'а, где вы хотите видеть вывод драйвера в реальном времени — просто не для чего-либо, что должно пережить закрытие ноутбука.
Признак: если ответ на «должна ли эта задача продолжать работать, если я отключусь» — да, ответ
на --deploy-mode — cluster. Промежуточной настройки не существует.
Что меняется операционно после переключения
Cluster mode переносит место, где живут логи драйвера — они на узле кластера, а не в вашем терминале,
так что вы читаете их через yarn logs -applicationId ... или kubectl logs, а не
наблюдаете за прокруткой stdout. Это также меняет то, как вы получаете обратно статус выхода задачи: client
mode возвращает его напрямую в shell, запустивший spark-submit; cluster mode требует опроса
менеджера кластера (yarn application -status или Spark UI/history server), поскольку
отправляющий процесс завершается, как только задача принята, а не когда она закончена. Ни то, ни другое не
сложнее, но скрипт деплоя, написанный в расчёте на синхронное поведение client mode, будет неверно
докладывать об успехе в cluster mode, если его не обновить на опрос.
Посмотрите, как это выглядит на вашем собственном пайплайне.
Загрузите реальный event log Spark, run_results.json от dbt или экспорт метрик Flink — и получите конкретные рекомендации, которые нужно одобрить, а не ещё одно эмпирическое правило.