Apache Spark permite configurar la manera en que se distribuyen las aplicaciones según el gestor de clúster utilizado. Existen dos configuraciones principales: Standalone y YARN, cada una con variantes de ejecución específicas que afectan la ubicación del Driver y la gestión de recursos.

1. Modo Standaolne

Este modo nativo de Spark ofrece dos estrategias para lanzar jobs: cliente (client) y clúster (cluster).

Ejecución en Modo Cliente

La instrucción para invocar este proceso es similar a la siguiente:

./bin/spark-submit --master spark://srv-master:7077 --deploy-mode client --class com.ejemplo.Main app.jar

El comportamiento interno sigue esta secuencai:

• Al inicializar el clúster, los workers registran sus capacidades (CPU, RAM) ante el Master.
• El Driver se instancia en la máquina local del usuario. Posteriormente, solicita recursos al Master.
• El Master asigna un Worker disponible para levantar un Executor. Este proceso actúa como contenedor de tareas, gestionando un pool de hilos.
• Una vez activo, el Executor se registra inversamente con el Driver, quien envía las tareas y monitoriza los resultados.

Esta configuración presenta un inconveniente notable: al mantener el Driver en el cliente, cada aplicación genera tráfico de red constante hacia los workers. Si se lanzan múltiples jobs simultáneos, la interfaz de red del cliente puede saturarse. Es ideal para fases de desarrollo donde se requiere visibilidad directa de los logs.

Ejecución en Modo Clúster

Para este escenario, el comando se ajusta:

./bin/spark-submit --master spark://srv-master:7077 --deploy-mode cluster --class com.ejemplo.Main app.jar

La dinámica cambia de la siguiente forma:

• El cliente solicita al Master el inicio del Driver.
• El Master selecciona un Worker aleatorio para ejecutar el Driver dentro del clúster.
• Este Driver interno solicita recursos para los Executors.
• Los Executors se registran con el Driver interno, quien gestiona el ciclo de vida de las tareas.

Al ejecutar el Driver dentro del clúster, la carga de red se distribuye entre los nodos workers en lugar de concentrarse en la máquina de origen. Esto es preferible para producción, aunque los logs deben consultarse vía UI web.

2. Integración con YARN

Spark también opera sobre Hadoop YARN, manteniendo las variantes client y cluster.

./bin/spark-submit --master yarn --class com.ejemplo.Main app.jar

El flujo operativo se basa en los componentes de YARN:

• Los NodeManagers reportan estado al ResourceManager (RM).
• El cliente inicia el Driver localmente y pide al RM un ApplicationMaster (AM).
• El RM asigna un contenedor para el AM. Este negocia recursos con el RM para levantar Executors en los NodeManagers.
• Los Executors se conectan al Driver local para recibir tareas.

Similar a Standalone Client, el tráfico de red afecta al cliente debido a la comunicación Driver-Executor. El AM se encarga de solicitar recursos y lanzar Executors, pero no schedulea tareas en este modo.

Modo YARN Cluster

Comando equivalente:

./bin/spark-submit --master yarn --deploy-mode cluster --class com.ejemplo.Main app.jar

Proceso de ejecución:

• El cliente solicita el AM al RM.
• El AM se ejecuta en un contenedor YARN y asume el rol de Driver (incluyendo la planificación de tareas).
• El AM solicita Executors al RM y los lanza en los NodeManagers.
• Los Executors se registrna con el AM para procesar el trabajo.

Este enfoque evita cuellos de botella en la red del cliente, distribuyendo la carga en el clúster. La visualización de logs depende de las herramientas de YARN. Para finalizar una ejecución activa se utiliza:

yarn application -kill <application_id>

En esta configuración, el ApplicationMaster centraliza la solicitud de recursos, el lanzamiento de Executors y la planificación de tareas.