apache-spark - run - spark jars packages
¿Qué son los trabajadores, ejecutores, núcleos en el clúster independiente de Spark? (1)
Leí la Descripción general del modo de clúster y todavía no puedo entender los diferentes procesos en el clúster autónomo de Spark y el paralelismo.
¿Es el trabajador un proceso JVM o no?
bin/start-slave.sh
y descubrí que generó el trabajador, que en realidad es una JVM.
Según el enlace anterior, un ejecutor es un proceso lanzado para una aplicación en un nodo de trabajo que ejecuta tareas. Executor también es una JVM.
Estas son mis preguntas:
-
Los ejecutores son por aplicación. Entonces, ¿cuál es el papel de un trabajador? ¿Se coordina con el ejecutor y comunica el resultado al conductor? ¿o el conductor habla directamente con el albacea? Si es así, ¿cuál es el propósito del trabajador entonces?
-
¿Cómo controlar el número de ejecutores para una aplicación? 3. ¿Se pueden hacer que las tareas se ejecuten en paralelo dentro del ejecutor? Si es así, ¿cómo configurar el número de hilos para un ejecutor?
-
¿Cuál es la relación entre el trabajador, los ejecutores y los núcleos de ejecutor (--total-executeor-cores)?
-
¿Qué significa tener más trabajadores por nodo?
Actualizado
Tomemos ejemplos para entender mejor.
Ejemplo 1: un clúster independiente con 5 nodos de trabajo (cada nodo tiene 8 núcleos) cuando inicio una aplicación con la configuración predeterminada.
Ejemplo 2 La misma configuración de clúster que en el ejemplo 1, pero ejecuto una aplicación con la siguiente configuración --executor-cores 10 --total-executeor-cores 10.
Ejemplo 3 La misma configuración de clúster que en el ejemplo 1, pero ejecuto una aplicación con la siguiente configuración --executor-cores 10 --total-executeor-cores 50.
Ejemplo 4 La misma configuración de clúster que en el ejemplo 1, pero ejecuto una aplicación con la siguiente configuración --executor-cores 50 --total-executeor-cores 50.
Ejemplo 5 La misma configuración de clúster que en el ejemplo 1, pero ejecuto una aplicación con la siguiente configuración --executor-cores 50 --total-executeor-cores 10.
En cada uno de estos ejemplos, ¿Cuántos ejecutores? ¿Cuántos hilos por ejecutor? Cuantos núcleos ¿Cómo se decide el número de ejecutores por aplicación? ¿Es siempre igual al número de trabajadores?
Spark utiliza una arquitectura maestro / esclavo. Como puede ver en la figura, tiene un coordinador central (Driver) que se comunica con muchos trabajadores distribuidos (ejecutores). El controlador y cada uno de los ejecutores se ejecutan en sus propios procesos Java.
CONDUCTOR
El controlador es el proceso donde se ejecuta el método principal. Primero convierte el programa de usuario en tareas y luego programa las tareas en los ejecutores.
EJECUTORES
Los ejecutores son procesos de nodos de trabajadores a cargo de ejecutar tareas individuales en un trabajo Spark dado. Se inician al comienzo de una aplicación Spark y, por lo general, se ejecutan durante toda la vida útil de una aplicación. Una vez que han ejecutado la tarea, envían los resultados al controlador. También proporcionan almacenamiento en memoria para RDD que son almacenados en caché por programas de usuario a través de Block Manager.
APLICACIÓN FLUJO DE EJECUCIÓN
Con esto en mente, cuando envía una solicitud al clúster con spark-submit, esto es lo que sucede internamente:
-
Una aplicación independiente se inicia e instancia una instancia de
SparkContext
(y es solo entonces cuando puede llamar a la aplicación controlador). - El programa controlador solicita recursos al administrador del clúster para iniciar los ejecutores.
- El administrador del clúster lanza ejecutores.
- El proceso del controlador se ejecuta a través de la aplicación del usuario. Dependiendo de las acciones y transformaciones sobre las tareas de RDD, se envían a los ejecutores.
- Los ejecutores ejecutan las tareas y guardan los resultados.
- Si algún trabajador falla, sus tareas serán enviadas a diferentes ejecutores para ser procesadas nuevamente. En el libro "Learning Spark: Lightning-Fast Big Data Analysis" hablan sobre Spark y Fault Tolerance:
Spark se ocupa automáticamente de máquinas fallidas o lentas al volver a ejecutar tareas fallidas o lentas. Por ejemplo, si el nodo que ejecuta una partición de una operación map () se bloquea, Spark lo volverá a ejecutar en otro nodo; e incluso si el nodo no se bloquea pero es simplemente mucho más lento que otros nodos, Spark puede lanzar de manera preventiva una copia "especulativa" de la tarea en otro nodo, y tomar su resultado si eso termina.
- Con SparkContext.stop () desde el controlador o si el método principal sale / falla, todos los ejecutores serán terminados y los recursos del clúster serán liberados por el administrador del clúster.
TUS PREGUNTAS
-
Cuando se inician los ejecutores, se registran con el controlador y desde ese momento se comunican directamente. Los trabajadores están a cargo de comunicar al administrador del clúster la disponibilidad de sus recursos.
-
En un clúster YARN puede hacerlo con --num-ejecutors. En un clúster independiente, obtendrá un ejecutor por trabajador a menos que juegue con spark.executor.cores y un trabajador tenga suficientes núcleos para contener a más de un ejecutor. (Como señaló @JacekLaskowski, --num-ejecutores ya no se usa en YARN https://github.com/apache/spark/commit/16b6d18613e150c7038c613992d80a7828413e66 )
-
Puede asignar el número de núcleos por ejecutor con --executor-cores
-
--total-executeor-cores es el número máximo de núcleos de ejecutor por aplicación
-
Como dijo Sean Owen en este thread : "no hay una buena razón para ejecutar más de un trabajador por máquina". Tendría muchos JVM sentados en una máquina, por ejemplo.
ACTUALIZAR
No he podido probar estos escenarios, pero según la documentación:
EJEMPLO 1: Spark adquirirá con avidez tantos núcleos y ejecutores como los ofrezca el programador. Así que al final obtendrás 5 ejecutores con 8 núcleos cada uno.
EJEMPLO 2 a 5: Spark no podrá asignar tantos núcleos como se solicite en un solo trabajador, por lo tanto, no se ejecutarán ejecutores.