Spark aprendizaje de 0 a 1 (2) -Modo y principio de funcionamiento de Apache Spark

1. Modo autónomo dos formas de enviar tareas

1.1 Modo de tarea de envío de cliente independiente

1. Orden de envio

   $./spark-submit --master spark://masterNode:7077 --class 主类 jar路径 100
   

   o

   $./spark-submit --master spark://masterNode:7077 --deploy-mode client --class 主类 jar路径 100
   

2. Diagrama del principio de implementación

3. Proceso de implementación

   1. Una vez enviada la tarea en el modo de cliente, el proceso del controlador se iniciará en el cliente.
   2. El controlador solicitará recursos a Master para iniciar la aplicación.
   3. La aplicación de recursos es exitosa y el lado del conductor envía la tarea al lado del trabajador para su ejecución.
   4. El trabajador devuelve el resultado de la ejecución de la tarea al final del controlador.

4. para resumir

   El modo cliente es adecuado para probar y depurar programas. El proceso del controlador se inicia en el cliente, y el cliente aquí se refiere al nodo actual que envía la aplicación. Puede ver la ejecución de la tarea en el lado del controlador. El modo de cliente no se puede utilizar en el entorno de producción. Porque: Supongamos que se van a enviar 100 aplicaciones al clúster para su funcionamiento. El controlador se iniciará en el lado del cliente cada vez, lo que provocará el problema de un aumento repentino del tráfico de la tarjeta de red en el lado del cliente 100 veces.

1.2 Método de envío de clúster independiente

1. Orden de envio

   $./spark-submit --master spark://masterNode:7077 --deploy-mode cluster --class 主类 jar包 100
   

2. Diagrama del principio de implementación

3. Proceso de implementación

   1. Una vez enviada la aplicación en modo de clúster, solicitará al maestro que inicie el controlador.
   2. El maestro recibe la solicitud e inicia el proceso del controlador en un nodo del clúster de forma aleatoria.
   3. Una vez que se inicia el controlador, solicite recursos para la aplicación actual.
   4. El controlador envía tareas a los nodos trabajadores para su ejecución.
   5. El trabajador devuelve el estado de ejecución y el resultado de la ejecución al controlador.

4. para resumir

   El proceso del controlador se inicia en un trabajador del clúster y la ejecución de la tarea no se puede ver en el cliente. Suponiendo que se envíen 100 aplicaciones al clúster para su ejecución, y cada vez que el controlador se inicie aleatoriamente en un trabajador del clúster, el problema del aumento repentino del tráfico de la tarjeta de red de 100 palabras se extenderá al clúster.

1.3 Resumen

Independientemente de dos formas de enviar tareas, la comunicación entre el controlador y el clúster incluye:

• El conductor es responsable de la aplicación de los recursos de la aplicación.
• Distribución de tareas
• Recuperación de resultados
• Supervisar la ejecución de la tarea

2. Dos formas de enviar tareas en modo Yarn

2.1 tarea de envío de hilo-cliente

1. Orden de envio

   ./spark-submit --master yarn --class 类名 jar包路径 100
   

   o

   ./spark-submit --master yarn-client --class 类名 jar包路径 100
   

   o

   ./spark-submit --master yarn --deploy-mode client --class 类名 jar包路径 100
   

2. Diagrama del principio de implementación

3. Proceso de implementación

   1. El cliente envía una aplicación e inicia un proceso de controlador en el cliente.
   2. Una vez iniciada la aplicación, enviará una solicitud a RS (ResourceManager) para iniciar los recursos de AM (ApplicationMaster).
   3. RS recibe la solicitud y selecciona aleatoriamente un NM (NodeManager) para iniciar AM. El NM aquí es equivalente al nodo Worker en Standalone.
   4. Después de que se inicie AM, solicitará un lote de recursos de contenedor del RS para iniciar el Ejecutor.
   5. RS encontrará un lote de NM y lo devolverá a AM para iniciar Executor.
   6. AM enviará un comando a NM para iniciar Executor.
   7. Después de que se inicia el Ejecutor, se registrará en el Conductor en la dirección inversa y el Conductor enviará tareas al Ejecutor. El ejecutor devuelve el estado de ejecución y los resultados al controlador.

4. para resumir

   El modo Yarn-client es uniformemente adecuado para realizar pruebas porque el controlador se ejecuta localmente. El controlador se comunicará mucho con el ejecutor en el grupo de hilos, lo que provocará un gran aumento en el tráfico de tarjetas de red del cliente.

   El papel de ApplicationMaster:

   1. Solicite recursos para la aplicación actual.

   2. Envíe un mensaje a NodeManager para iniciar Executor.

      Nota: ApplicationMaster tiene la función de iniciar Executor y solicitar recursos, pero no la función de programación de trabajos.

2.2 tarea de envío de grupos de hilos

1. Orden de envio

   ./spark-submit --master yarn --deploy-mode cluster --class 主类 jar包路径 100
   

   o

   ./spark-submit --master yarn-cluster --class 主类 jar包路径 100
   

2. Diagrama del principio de implementación

   

3. Proceso de implementación

   1. El cliente envía el programa de aplicación, envía una solicitud a RS (ResourceManager) e inicia AM (ApplicationMaster).
   2. Después de recibir la solicitud, RS inicia AM (equivalente al lado del conductor) aleatoriamente en un NM (NodeManager).
   3. Después de que AM comienza, envía una solicitud a RS para solicitar un lote de contenedores para iniciar Executor.
   4. RS devuelve un lote de nodos NM a AM.
   5. AM se conecta a NM, envía una solicitud a NM e inicia Executor.
   6. El Ejecutor se registra a la inversa del Controlador del nodo donde se encuentra el AM. El conductor envía tareas al ejecutor.

4. para resumir

   Yarn-Cluster se utiliza principalmente en el entorno de producción, porque el controlador se ejecuta en un NodeManager en el clúster de Yarn. Cada vez que el controlador que envía la tarea se ubica en una máquina aleatoria, no habrá aumento en el tráfico de la tarjeta de red de una determinada máquina. La desventaja es que el registro no se puede ver después de enviar la tarea y el registro solo se puede ver a través de hilo.

   El papel de ApplicationMaster:

   1. Solicite recursos para la aplicación actual.
   2. Envíe un mensaje a NodeManager para iniciar Excutor.
   3. Programación de tareas.

   Comando para detener la tarea del clúster: yarn application -kill applicationId

3. Explicación del término Spark

• Maestro (independiente): el nodo maestro (proceso) de la gestión de recursos
• Administrador de clúster: servicios externos que obtienen recursos en el clúster (como independiente, Mesos, Yarn)
• Nodo trabajador (independiente): el nodo esclavo (proceso) de gestión de recursos o el proceso de gestión de recursos locales.
• Aplicación: programa de usuario basado en Spark, incluido el programa controlador y el programa Executor que se ejecutan en el clúster.
• Programa de controlador: el proceso utilizado para conectarse al proceso de trabajo (Trabajador).
• Ejecutor: Proceso iniciado para una Aplicación en un nodo administrado por un proceso Trabajador, el proceso es responsable de ejecutar tareas y almacenar datos en memoria o disco. Cada aplicación tiene sus propios ejecutores independientes.
• Tarea: la unidad de trabajo enviada a un ejecutor.
• Trabajo: contiene muchas tareas en computación paralela, que pueden considerarse correspondientes a Acción.
• Etapa: un trabajo se dividirá en muchos grupos de tareas, y cada tarea se llamará Etapa (al igual que MapReduce se divide en Tarea de mapa y Tarea de reducción)

4. Dependencia estrecha y dependencia amplia

Existe una serie de dependencias entre los RDD, que se dividen en dependencias estrechas y dependencias amplias.

• Dependencia estrecha

  La relación entre el RDD principal y la partición RDD secundaria es de uno a uno. O una partición de un RDD principal corresponde a un RDD principal y un RDD secundario en el caso de una partición de un RDD secundario. La relación de partición es de varios a uno. No habrá reproducción aleatoria.

• Amplia dependencia

  La relación entre el RDD principal y la partición RDD secundaria es de uno a muchos. Habrá barajas.

• Diagrama de dependencia de ancho

5. Etapa

La tarea Spark formará un gráfico acíclico dirigido por DAG basado en las dependencias entre RDD. El DAG se enviará al DAGScheduler y el DAGScheduler dividirá el DAG en varias etapas que dependen unas de otras. La división se basa en las dependencias amplias y estrechas entre los RDD. Cuando se encuentra una dependencia amplia, la etapa se divide y cada etapa contiene una o más tareas. Luego envíe estas tareas a TaskScheduler en forma de taskSet para que se ejecuten.

Un escenario se compone de un conjunto de tareas paralelas.

5.1 Reglas de corte de escenario

Regla de corte: de atrás hacia adelante, corte el escenario cuando se encuentre con una amplia dependencia.

5.2 Modo de cálculo de etapa

Modo de cálculo de canalización, canalización es solo una idea y un modo de cálculo.

Los datos siempre están en proceso, ¿cuándo caerán?

1. Persiste el RDD.
2. Cuando el escritor aleatorio.

El paralelismo de tareas de la etapa está determinado por el número de particiones del último RDD de la etapa.

Cómo cambiar el número de particiones RDD

Por reduceByKey("key",4)ejemplo:,groupByKey(4)

5.3 Verificar el modo de cálculo de la canalización

val conf = new SparkConf()
conf.setMaster("local").setAppName("pipeline")
val sc = new SparkContext(conf)
val rdd1 = sc.parallelize(Array(1,2,3,4))
val rdd2 = rdd1.map {
    
    x => {
    
    
    println("map======>"+x)
    x
}}

val rdd3 = rdd2.filter {
    
     x=> {
    
    
    println("filter=====>"+x)
    true
}}
rdd3.collect()
sc.stop()

6. Programación de recursos y programación de tareas de Spark

6.1 Programación gráfica de recursos de Spark y proceso de programación de tareas

6.2 Proceso de programación de tareas y programación de recursos de Spark

1. Después de iniciar el clúster, el nodo trabajador informará el estado de los recursos al nodo maestro y el maestro tendrá el estado de los recursos del clúster.
2. Después de que Spark envía una aplicación, forma un gráfico acíclico dirigido por DAG basado en las dependencias entre RDD.
3. Una vez enviada la tarea, Spark creará dos objetos en el lado del controlador: DAGScheduler y TaskScheduler.
4. DAGScheduler es el programador de más alto nivel para la programación de tareas y es un objeto.
5. La función principal de DAGScheduler es dividir DAG en etapas de acuerdo con las dependencias amplias y estrechas entre los RDD, y luego enviar estas etapas a TaskScheduler en forma de TaskSet (TaskScheduler es el programador de bajo nivel de la programación de tareas, aquí TaskSet es en realidad una colección, que Lo que está encapsulado es una tarea, que es la tarea de paralelismo en el escenario).
6. TaskScheduler atravesará la colección TaskSet y, después de obtener cada tarea, enviará la tarea al nodo informático Executor para su ejecución (de hecho, se envía al grupo de subprocesos ThreadPool en el Executor para su ejecución).
7. El estado de ejecución de la tarea en el grupo de subprocesos del Ejecutor se retroalimentará a TaskScheduler. Cuando la ejecución de la tarea falla, TaskScheduler es responsable de reintentar y la Tarea se reenvía al Ejecutor para su ejecución. El valor predeterminado es 3 reintentos.
8. Si falla después de 3 reintentos, la etapa donde se encuentra la tarea falla. Si la etapa falla, el DAGScheduler copiará, volverá a intentarlo y volverá a enviar el TaskSet al TaskScheduler. La etapa predeterminada para reintentar 5 veces. Si aún falla después de 4 veces, entonces el trabajo ha fallado. Si el trabajo falla, la aplicación falla.

TaskScheduler no solo puede reintentar tareas fallidas, sino también reintentar tareas rezagadas (retrasadas, lentas) (es decir, tareas cuya velocidad de ejecución es mucho más lenta que otras tareas). Si hay una tarea de ejecución lenta, TaskScheduler iniciará una nueva tarea para realizar la misma lógica de procesamiento que la tarea lenta. Cuál de las dos tareas se ejecuta primero depende del resultado de ejecución de qué tarea. Este es el mecanismo de ejecución especulativa de Spark. La ejecución especulativa está desactivada de forma predeterminada en Spark. Se puede spark.speculationconfigurar a través de propiedades.

Nota:

• Para los tipos de negocios ETL que necesitan almacenarse en la base de datos, el mecanismo de ejecución especulativa debe cerrarse para que no se almacenen datos duplicados en la base de datos.
• Si encuentra datos sesgados, activar el mecanismo de especulación puede hacer que la tarea se reinicie todo el tiempo para procesar la misma lógica, y la tarea siempre puede estar en un estado de procesamiento incompleto.

6.3 Aplicación de recursos de grano grueso y aplicación de recursos de grano fino

• Aplicación de recursos de grano grueso (Spark)

  Antes de que se ejecute la aplicación, se aplican todas las aplicaciones de recursos. Cuando la aplicación de recursos tiene éxito, se realizará la programación de tareas. Después de ejecutar todas las tareas, se liberarán algunos recursos.

  Ventajas: antes de que se ejecute la aplicación, se aplican todos los recursos. Cada tarea puede utilizar recursos directamente. No es necesario que las tareas soliciten recursos por sí mismas antes de la ejecución. La tarea comienza rápido, la ejecución de la tarea es rápida, la ejecución de la aplicación es rápida.

  Desventajas: los recursos no se liberarán hasta que se complete la última tarea y los recursos del clúster no se pueden utilizar por completo.

• Aplicación de recursos detallada (MapReduce)

  La aplicación no necesita solicitar recursos antes de la ejecución, sino que se ejecuta directamente. Deje que cada tarea del trabajo solicite recursos por sí misma antes de la ejecución y libere los recursos cuando se ejecute la tarea.

  Ventajas: los recursos del clúster se pueden utilizar por completo.

  Desventajas: cuando las tareas solicitan recursos por sí mismas, el inicio de la tarea se vuelve más lento. La aplicación se ejecuta más lentamente en consecuencia.