Flink
Nivel medio¿Cómo despliego un job de Flink - session mode vs application mode?
Flink le da dos formas genuinamente distintas de correr un job, y el tradeoff es en exactamente una dimensión: si un job problemático puede tumbar a otros con él.
Un cluster de sesión es un JobManager de larga duración que acepta múltiples jobs, enviados uno a la vez o concurrentemente. Un cluster de aplicación se levanta fresco para el main() de exactamente un job y se destruye cuando termina. Mismo runtime de Flink por debajo, aislamiento de fallos muy diferente.
Qué le da realmente cada modo
En session mode, envía jars a un JobManager ya corriendo, que los agenda en los TaskManagers
que estén registrados - rápido para iterar (sin arranque de cluster por envío), y encaja naturalmente en
un ambiente compartido de dev/staging donde levantar infraestructura por job es un desperdicio. En
application mode, el JobManager mismo corre el main() de su job - el cluster existe
solo para ese job, desde el arranque hasta el apagado, y nada más puede agendarse en él.
El tradeoff de aislamiento de fallos que realmente importa
El JobManager de un cluster de sesión es un recurso compartido: un job cuyo main() tiene
una fuga de memoria, registra demasiadas clases, o de otro modo se comporta mal a nivel de JobManager puede
degradar o tumbar a cada otro job en esa misma sesión - no solo el suyo. Application mode le da a cada job
su propio JobManager, así que el radio de impacto de un job problemático se detiene en ese job. Esto casi
nunca es sobre rendimiento crudo (la ejecución a nivel de tarea es la misma de cualquier forma) - es
enteramente sobre si el mal deploy de un equipo puede hacer sonar la alarma de otro equipo.
El valor por defecto práctico: session mode para desarrollo interactivo y jobs ad hoc donde el overhead de un cluster por job no vale la pena; application mode para cualquier cosa corriendo desatendida en producción, específicamente por el aislamiento, no porque sea más rápido.
Dónde esto todavía necesita criterio
El arranque de cluster por job de application mode agrega latencia real antes de que un job realmente empiece a procesar - bien para un job de streaming de larga duración donde el tiempo de arranque es insignificante frente al tiempo total de ejecución, más notorio para jobs de Flink tipo batch cortos corridos frecuentemente, donde el arranque del cluster puede ser una fracción significativa del tiempo total del job. No hay una respuesta universal aquí; depende de cómo se compara el tiempo de ejecución del job con su propio costo de arranque, que vale la pena medir realmente en vez de asumir.
Vea cómo se ve esto en su propio pipeline.
Suba un event log real de Spark, un run_results.json de dbt o una exportación de métricas de Flink y obtenga recomendaciones concretas, que debe aprobar antes de aplicar - no otra regla general.