Flink
Средний уровеньКак развернуть задачу Flink — session mode или application mode?
Flink даёт два по-настоящему разных способа запускать задачу, и они расходятся ровно в одном измерении: может ли плохая задача утянуть с собой другие.
Session-кластер — это долгоживущий JobManager, принимающий несколько задач, отправленных по одной или одновременно. Application-кластер поднимается заново ровно под один main() задачи и уничтожается по её завершении. Один и тот же рантайм Flink внутри, очень разная изоляция сбоев.
Что реально даёт каждый режим
В session mode вы отправляете jar'ы уже работающему JobManager'у, который планирует их на любые
зарегистрированные TaskManager'ы — быстро для итераций (без старта кластера на каждую отправку) и
естественно подходит для общей dev/staging-среды, где поднимать инфраструктуру на каждую задачу
расточительно. В application mode сам JobManager запускает main() вашей задачи —
кластер существует только для этой одной задачи, от старта до остановки, и ничего другого на него нельзя
запланировать.
Компромисс изоляции сбоев, который реально важен
JobManager session-кластера — общий ресурс: задача, чей main() течёт по памяти,
регистрирует слишком много классов или иначе плохо себя ведёт на уровне JobManager'а, может деградировать
или уронить каждую другую задачу на том же session'е — не только свою. Application mode даёт каждой задаче
собственный JobManager, так что радиус поражения плохо ведущей себя задачи ограничивается ею самой. Это
почти никогда не про сырую производительность (исполнение на уровне задач одинаково в обоих случаях) — это
целиком про то, может ли плохой деплой одной команды разбудить по звонку другую.
Практический выбор по умолчанию: session mode для интерактивной разработки и разовых задач, где накладные расходы на кластер per-job того не стоят; application mode для всего, что работает без присмотра в продакшене — именно из-за изоляции, а не потому что быстрее.
Где здесь всё ещё нужно суждение
Старт кластера per-job в application mode добавляет реальную задержку до того, как задача реально начинает обрабатывать данные — нормально для долгоживущей стриминговой задачи, где время старта незначимо на фоне общего времени работы, заметнее для коротких batch-подобных Flink-задач, запускаемых часто, где старт кластера может быть значимой долей общего времени задачи. Универсального ответа здесь нет — всё зависит от того, как время работы задачи соотносится с её же стоимостью старта, а это стоит реально измерить, а не предполагать.
Посмотрите, как это выглядит на вашем собственном пайплайне.
Загрузите реальный event log Spark, run_results.json от dbt или экспорт метрик Flink — и получите конкретные рекомендации, которые нужно одобрить, а не ещё одно эмпирическое правило.