Basta ya de investigar en internet porque estás al lugar necesario, tenemos la respuesta que quieres pero sin complicarte.
Solución:
Una estrategia de implementación común es enviar su aplicación desde una máquina de puerta de enlace que está ubicada físicamente junto con sus máquinas de trabajo (por ejemplo, nodo maestro en un clúster EC2 independiente). En esta configuración, el modo cliente es apropiado. En el modo de cliente, el controlador se inicia directamente dentro del proceso de envío de chispa que actúa como un cliente para el clúster. La entrada y salida de la aplicación se adjunta a la consola. Por lo tanto, este modo es especialmente adecuado para aplicaciones que involucran REPL (por ejemplo, Spark shell).
Alternativamente, si su aplicación se envía desde una máquina lejos de las máquinas de los trabajadores (por ejemplo, localmente en su computadora portátil), es común usar el modo de clúster para minimizar la latencia de la red entre los controladores y los ejecutores. Tenga en cuenta que el modo de clúster actualmente no es compatible con los clústeres de Mesos. Actualmente, solo YARN admite el modo de clúster para las aplicaciones de Python”. — Envío de solicitudes
Lo que entiendo de esto es que ambas estrategias usan el clúster para distribuir tareas; la diferencia es dónde se ejecuta el “programa controlador”: localmente con Spark-Submit, o también en el clúster.
Cuándo debe usar cualquiera de ellos se detalla en la cita anterior, pero también hice otra cosa: para frascos grandes, usé rsync para copiarlos al clúster (o incluso al nodo maestro) con 100 veces la velocidad de la red y luego enviarlos desde el clúster. Esto puede ser mejor que el “modo de clúster” para frascos grandes. Tenga en cuenta que el modo de cliente probablemente no transfiera el jar al maestro. En ese punto la diferencia entre los 2 es mínima. Probablemente el modo cliente sea mejor cuando el programa del controlador está inactivo la mayor parte del tiempo, para hacer un uso completo de los núcleos en la máquina local y quizás evitar transferir el jar al maestro (incluso en la interfaz de bucle invertido, un jar grande tarda bastantes segundos) . Y con el modo cliente puede transferir (rsync) el jar en cualquier nodo del clúster.
Por otro lado, si el controlador es muy intensivo, en CPU o E/S, el modo de clúster puede ser más apropiado para equilibrar mejor el clúster (en modo de cliente, la máquina local ejecutaría tanto el controlador como tantos trabajadores como sea posible). , lo que hace que se sobrecargue y que las tareas locales sean más lentas, lo que hace que todo el trabajo termine esperando un par de tareas de la máquina local).
Conclusión :
- En resumen, si estoy en la misma red local que el clúster, usaría el modo cliente y lo enviaría desde mi computadora portátil. Si el clúster está lejos, lo enviaría localmente con el modo de clúster o
rsync
el jar al clúster remoto y enviarlo allí, en modo de cliente o de clúster, según la cantidad de recursos del programa controlador.*AFAIK Con el programa del controlador ejecutándose en el clúster, es menos vulnerable a las desconexiones remotas que bloquean el controlador y todo el trabajo de chispa. Esto es especialmente útil para trabajos de ejecución prolongada, como cargas de trabajo de tipo de procesamiento de flujo.
Trabajos de Spark que se ejecutan en YARN
Cuando se ejecuta Spark en YARN, cada ejecutor de Spark se ejecuta como un contenedor de YARN. Donde MapReduce programa un contenedor y activa una JVM para cada tarea, Spark aloja varias tareas dentro del mismo contenedor. Este enfoque permite un tiempo de inicio de tareas más rápido en varios órdenes de magnitud.
Spark admite dos modos para ejecutarse en YARN, “grupo de hilosmodo ” y “hilo-cliente” modo. En términos generales, el modo de clúster de hilo tiene sentido para trabajos de producción, mientras que el modo de cliente de hilo tiene sentido para usos interactivos y de depuración en los que desea ver el resultado de su aplicación de inmediato.
Comprender la diferencia requiere una comprensión del concepto del maestro de aplicaciones de YARN. En YARN, cada instancia de aplicación tiene un proceso maestro de aplicación, que es el primer contenedor iniciado para esa aplicación. La aplicación es responsable de solicitar recursos del ResourceManager y, cuando los asigna, de decirle a los NodeManagers que inicien contenedores en su nombre. Los maestros de aplicaciones evitan la necesidad de un cliente activo: el proceso que inicia la aplicación puede desaparecer y la coordinación continúa desde un proceso administrado por YARN que se ejecuta en el clúster.
En modo de grupo de hilos, el controlador se ejecuta en Application Master. Esto significa que el mismo proceso es responsable tanto de impulsar la aplicación como de solicitar recursos de YARN, y este proceso se ejecuta dentro de un contenedor de YARN. El cliente que inicia la aplicación no necesita quedarse durante toda su vida útil.
modo de grupo de hilos
El modo de clúster de hilo es no muy adecuado para usar Spark de forma interactiva, pero el modo de hilo-cliente es. Las aplicaciones de Spark que requieren la entrada del usuario, como spark-shell y PySpark, necesitan que el controlador de Spark se ejecute dentro del proceso del cliente que inicia la aplicación de Spark. En el modo de cliente de hilo, el maestro de aplicaciones simplemente está presente para solicitar contenedores de ejecutor de YARN. El cliente se comunica con esos contenedores para programar el trabajo después de que comiencen:
modo de hilo-cliente
Esta tabla ofrece una lista concisa de las diferencias entre estos modos:
Referencia: https://blog.cloudera.com/blog/2014/05/apache-spark-resource-management-and-yarn-app-models/ – Apache Spark Resource Management y YARN App Models (web.archive.com mirror )
Si crees que te ha resultado de provecho este post, sería de mucha ayuda si lo compartes con más programadores y nos ayudes a extender este contenido.