Spark
Nivel medio¿Cómo despliego un job de Spark - client mode vs cluster mode?
spark-submit tiene exactamente una bandera que decide dónde corre el driver - y equivocarse no falla ruidosamente, simplemente hace que la supervivencia de su job dependa de algo de lo que no debería.
Todo despliegue de Spark corre un proceso driver y cierto número de executors - client mode y cluster mode solo difieren en dónde vive el driver. Esa única diferencia tiene consecuencias más grandes de lo que suena.
Qué mueve realmente --deploy-mode
En client mode, el driver corre en la máquina que emitió spark-submit - su laptop,
un servidor de notebook, un runner de CI - y solo los executors corren en el cluster. En cluster mode,
el cluster manager (YARN, Kubernetes, standalone) lanza el driver como su propio proceso en un nodo del
cluster, así que la máquina que corrió spark-submit puede desconectarse por completo una vez
que el job es aceptado.
Por qué client mode es el valor por defecto equivocado para algo desatendido
El driver coordina cada tarea y guarda el estado final del job - si muere, el job muere, sin importar cuán saludables estén los executors. En client mode, eso significa que una laptop que se pone en suspensión, un kernel de notebook que se reinicia, o el timeout del job de un runner de CI matan un job de Spark que de otro modo estaría corriendo bien. No es un caso extremo teórico; es la forma más común en que empieza un ticket de "por qué este job simplemente desapareció sin error". Client mode es genuinamente la elección correcta para trabajo interactivo - un notebook donde quiere que la salida del driver se transmita en vivo - solo que no para algo que necesite sobrevivir después de que cierre la laptop.
La señal: si la respuesta a "¿este job necesita seguir corriendo si me desconecto?" es sí, la
respuesta para --deploy-mode es cluster. No hay una configuración intermedia.
Qué cambia operacionalmente una vez que cambia
Cluster mode mueve dónde viven los logs del driver - están en un nodo del cluster, no en su
terminal, así que los lee vía yarn logs -applicationId ... o kubectl logs en vez
de ver el stdout desplazarse. También cambia cómo recupera el estado de salida del job: client mode lo
devuelve directamente al shell que corrió spark-submit; cluster mode requiere consultar al
cluster manager (yarn application -status, o la Spark UI/history server) ya que el proceso que
envía termina tan pronto el job es aceptado, no cuando termina. Ninguno es más difícil, pero un script de
deploy escrito asumiendo el comportamiento síncrono de client mode reportará mal el éxito en cluster mode
si no se actualiza para consultar en su lugar.
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.