apache-spark - examples - apache spark wikipedia

Apache Spark: diferencias entre los modos de implementación de cliente y clúster

Question

TL; DR: en un clúster independiente de Spark, ¿cuáles son las diferencias entre los modos de implementación de clúster y cliente? ¿Cómo configuro en qué modo se ejecutará mi aplicación?

Tenemos un clúster independiente de Spark con tres máquinas, todas ellas con Spark 1.6.1:

• Una máquina maestra, que también es donde se ejecuta nuestra aplicación usando spark-submit
• 2 máquinas de trabajo idénticas

De la documentación de Spark , leí:

(...) Para los clústeres independientes, Spark actualmente admite dos modos de implementación. En modo cliente, el controlador se inicia en el mismo proceso que el cliente que envía la aplicación. Sin embargo, en el modo de clúster, el controlador se inicia desde uno de los procesos de Worker dentro del clúster, y el proceso del cliente se cierra tan pronto como cumple con su responsabilidad de enviar la solicitud sin esperar a que la aplicación finalice.

Sin embargo, realmente no entiendo las diferencias prácticas al leer esto, y no entiendo cuáles son las ventajas y desventajas de los diferentes modos de implementación.

Además, cuando inicio mi aplicación usando start-submit, incluso si configuro la propiedad spark.submit.deployMode en "cluster", la interfaz de usuario de Spark para mi contexto muestra la siguiente entrada:

Por lo tanto, no puedo probar ambos modos para ver las diferencias prácticas. Dicho esto, mis preguntas son:

1) ¿Cuáles son las diferencias prácticas entre el modo de implementación de cliente autónomo de Spark y el modo de implementación de clúster ? ¿Cuáles son las ventajas y desventajas de usar cada una?

2) ¿Cómo elijo en cuál se ejecutará mi aplicación, usando spark-submit ?

Answer 1

¿Cuáles son las diferencias prácticas entre el modo de implementación de cliente autónomo de Spark y el modo de implementación de clúster? ¿Cuáles son las ventajas y desventajas de usar cada una?

Intentemos ver las diferencias entre el modo cliente y el modo de clúster.

Cliente:

• El controlador se ejecuta en un servidor dedicado (nodo maestro) dentro de un proceso dedicado. Esto significa que tiene todos los recursos disponibles a su disposición para ejecutar el trabajo.
• Driver abre un servidor Netty HTTP dedicado y distribuye los archivos JAR especificados a todos los nodos de Worker (gran ventaja).
• Debido a que el nodo maestro tiene recursos propios dedicados, no necesita "gastar" recursos de trabajo para el programa Driver.
• Si el proceso del controlador muere, necesita un sistema de monitoreo externo para restablecer su ejecución.

Racimo:

• El controlador se ejecuta en uno de los nodos de trabajo del clúster. El trabajador es elegido por el líder maestro
• El controlador se ejecuta como un proceso independiente dedicado dentro del trabajador .
• Los programas de controlador ocupan al menos 1 núcleo y una cantidad dedicada de memoria de uno de los trabajadores (esto se puede configurar).
• El programa del controlador se puede monitorear desde el nodo Maestro usando el indicador --supervise y se puede restablecer en caso de que muera.
• Cuando se trabaja en modo Cluster, todos los JAR relacionados con la ejecución de su aplicación deben estar disponibles públicamente para todos los trabajadores. Esto significa que puede colocarlos manualmente en un lugar compartido o en una carpeta para cada uno de los trabajadores.

¿Cuál es mejor? No estoy seguro, eso es realmente para que experimentes y decidas. Aquí no es una mejor decisión, obtienes cosas de lo primero y lo último, depende de ti ver cuál funciona mejor para tu caso de uso.

Cómo elegir en cuál se va a ejecutar mi aplicación, usando spark-submit

La forma de elegir en qué modo ejecutar es usando el --deploy-mode . Desde la página de Configuración de Spark :

/bin/spark-submit /
--class <main-class>
--master <master-url> /
--deploy-mode <deploy-mode> /
--conf <key>=<value> /
... # other options
<application-jar> /
[application-arguments]

Answer 2

Digamos que va a realizar un envío de chispa en EMR haciendo SSH al nodo maestro. Si está proporcionando la opción --desplegar en modo clúster, entonces sucederá lo siguiente.

1. No podrá ver los registros detallados en la terminal.
2. Dado que el controlador no se crea en el maestro mismo, no podrá finalizar el trabajo desde el terminal.

Pero en el caso del cliente --deploy-mode:

1. Podrá ver los registros detallados en la terminal.
2. Podrá terminar el trabajo desde la propia terminal.

Estas son las cosas básicas que he notado hasta ahora.

Answer 3

También estoy teniendo el mismo escenario, aquí el nodo maestro usa un clúster ec2 independiente. En esta configuración, el modo cliente es apropiado. En este controlador se inicia directamente con el proceso de envío de chispas que actúa como un cliente para el clúster. La entrada y salida de la aplicación está conectada a la consola, por lo que este modo es especialmente adecuado para aplicaciones que involucran REPL.

De lo contrario, si su solicitud se envía desde una máquina lejos de las máquinas de trabajo, entonces es bastante común usar el modo de clúster para minimizar la latencia de red en blanco y negro del controlador y el ejecutor.