apache-spark yarn amazon-emr amazon-kinesis

apache spark - El informe de aplicación para application_(state: ACCEPTED) nunca termina para Spark Submit(con Spark 1.2.0 en YARN)



apache-spark amazon-emr (12)

Cuando se ejecuta con clúster de hilo, todo el registro de aplicaciones y la salida estándar se ubicarán en el maestro de aplicación de hilo asignado y no parecerán enviar chispas. También se está transmitiendo la aplicación por lo general no sale. Consulte la interfaz web del administrador de recursos de Hadoop y observe la interfaz web de Spark y los registros que estarán disponibles en Hadoop ui.

Estoy ejecutando kinesis plus spark application https://spark.apache.org/docs/1.2.0/streaming-kinesis-integration.html

Estoy corriendo como abajo

comando en la instancia de ec2:

./spark/bin/spark-submit --class org.apache.spark.examples.streaming.myclassname --master yarn-cluster --num-executors 2 --driver-memory 1g --executor-memory 1g --executor-cores 1 /home/hadoop/test.jar

He instalado la chispa en EMR.

EMR details Master instance group - 1 Running MASTER m1.medium 1 Core instance group - 2 Running CORE m1.medium

Estoy debajo de INFO y nunca termina.

15/06/14 11:33:23 INFO yarn.Client: Requesting a new application from cluster with 2 NodeManagers 15/06/14 11:33:23 INFO yarn.Client: Verifying our application has not requested more than the maximum memory capability of the cluster (2048 MB per container) 15/06/14 11:33:23 INFO yarn.Client: Will allocate AM container, with 1408 MB memory including 384 MB overhead 15/06/14 11:33:23 INFO yarn.Client: Setting up container launch context for our AM 15/06/14 11:33:23 INFO yarn.Client: Preparing resources for our AM container 15/06/14 11:33:24 INFO yarn.Client: Uploading resource file:/home/hadoop/.versions/spark-1.3.1.e/lib/spark-assembly-1.3.1-hadoop2.4.0.jar -> hdfs://172.31.13.68:9000/user/hadoop/.sparkStaging/application_1434263747091_0023/spark-assembly-1.3.1-hadoop2.4.0.jar 15/06/14 11:33:29 INFO yarn.Client: Uploading resource file:/home/hadoop/test.jar -> hdfs://172.31.13.68:9000/user/hadoop/.sparkStaging/application_1434263747091_0023/test.jar 15/06/14 11:33:31 INFO yarn.Client: Setting up the launch environment for our AM container 15/06/14 11:33:31 INFO spark.SecurityManager: Changing view acls to: hadoop 15/06/14 11:33:31 INFO spark.SecurityManager: Changing modify acls to: hadoop 15/06/14 11:33:31 INFO spark.SecurityManager: SecurityManager: authentication disabled; ui acls disabled; users with view permissions: Set(hadoop); users with modify permissions: Set(hadoop) 15/06/14 11:33:31 INFO yarn.Client: Submitting application 23 to ResourceManager 15/06/14 11:33:31 INFO impl.YarnClientImpl: Submitted application application_1434263747091_0023 15/06/14 11:33:32 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED) 15/06/14 11:33:32 INFO yarn.Client: client token: N/A diagnostics: N/A ApplicationMaster host: N/A ApplicationMaster RPC port: -1 queue: default start time: 1434281611893 final status: UNDEFINED tracking URL: http://172.31.13.68:9046/proxy/application_1434263747091_0023/ user: hadoop 15/06/14 11:33:33 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED) 15/06/14 11:33:34 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED) 15/06/14 11:33:35 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED) 15/06/14 11:33:36 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED) 15/06/14 11:33:37 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED) 15/06/14 11:33:38 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED) 15/06/14 11:33:39 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED) 15/06/14 11:33:40 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED) 15/06/14 11:33:41 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)

¿Podría alguien decirme por qué no funciona?

En mi caso, veo que algunos viejos procesos de chispa (que son detenidos por Ctrl + Z) todavía se están ejecutando y sus AppMasters (controladores) probablemente todavía ocupan memoria. Por lo tanto, el nuevo AppMaster del nuevo comando de chispa puede estar esperando indefinidamente para registrarse en YarnScheduler, ya que spark.driver.memory no se puede asignar en los nodos centrales respectivos. Esto también puede ocurrir cuando la asignación de recursos máxima es verdadera y si el controlador está configurado para usar recursos máximos disponibles para un nodo central.

Entonces, identifiqué todos esos procesos obsoletos de cliente de chispa y los maté (lo que pudo haber matado a sus Controladores y liberar memoria).

ps -aux | grep spark hadoop 3435 1.4 3.0 3984908 473520 pts/1 Tl Feb17 0:12 .. org.apache.spark.deploy.SparkSubmit --conf spark.driver.memory=1G --class org.apache.spark.examples.SparkPi /usr/lib/spark/lib/spark-examples.jar 10 hadoop 32630 0.9 3.0 3984908 468928 pts/1 Tl Feb17 0:14 .. org.apache.spark.deploy.SparkSubmit --conf spark.driver.memory=1G --class org.apache.spark.examples.SparkPi /usr/lib/spark/lib/spark-examples.jar 1000 kill -9 3435 32630

Después de eso, no veo esos mensajes.

En un caso, tuve este problema porque estaba pidiendo demasiados recursos. Esto fue en un pequeño clúster independiente. El comando original era

spark-submit --driver-memory 4G --executor-memory 7G -class "my.class" --master yarn --deploy-mode cluster --conf spark.yarn.executor.memoryOverhead my.jar

Logré pasar ''Aceptado'' y ''Correr'' cambiando a

spark-submit --driver-memory 1G --executor-memory 3G -class "my.class" --master yarn --deploy-mode cluster --conf spark.yarn.executor.memoryOverhead my.jar

En otros casos, tuve este problema debido a la forma en que se escribió el código. Instantamos el contexto de chispa dentro de la clase donde se usó, y no se cerró. Solucionamos el problema instanciando primero el contexto, pasándolo a la clase donde los datos están paralelizados, etc., y luego cerramos el contexto (sc.close ()) en la clase de la persona que llama.

Esto sugiere que YARN no puede asignar recursos para la nueva aplicación que está enviando. Intente reducir los recursos para el contenedor que está solicitando (consulte here ), o intente esto en un clúster menos ocupado.

Otra cosa que debes probar es verificar si YARN funciona correctamente como un servicio:

sudo service hadoop-yarn-nodemanager status sudo service hadoop-yarn-resourcemanager status

Estoy en una configuración ligeramente diferente con CDH 5.4. Creo que la causa de este problema en mi configuración es algo que se atasca debido a un error (el archivo ya existe, etc.), porque esto ocurre después de que otra parte de mi código se equivoca y trata de arreglarlo y reanudarlo.

Puedo superar esto reiniciando todos los servicios en el clúster en cloudera manager, por lo que estoy de acuerdo con las respuestas anteriores de que probablemente se deba a recursos asignados a algo que salió erroneamente y necesita recuperar esos recursos para poder ejecutarlos de nuevo, o asignarlos de manera diferente para comenzar.

Por ejemplo, mi clúster tiene 4 ejecutores disponibles. En SparkConf para un proceso, configuré spark.executor.instances en 4. Mientras el proceso todavía se está ejecutando, posiblemente colgado por alguna razón, comienzo otro trabajo (de la misma manera, o con spark-submit), con chispa. executor.instances establecido en 1 ("--num-executors 1" si se usa spark-submit). Solo tengo 4 y 4 se asignan al proceso anterior, por lo que este que está pidiendo 1 ejecutor tiene que esperar en línea.

Hay tres formas en que podemos tratar de solucionar este problema.

  1. Verifica el proceso de chispa en tu máquina y mátalo.

Hacer

ps aux | grep spark

Toma todas las identificaciones del proceso con procesos de chispa y mátalas, como

sudo kill -9 4567 7865

  1. Verifique el número de aplicaciones de chispa que se ejecutan en su clúster.

Para verificar esto, hazlo

yarn application -list

obtendrás un resultado similar a esto:

Total number of applications (application-types: [] and states: [SUBMITTED, ACCEPTED, RUNNING]):1 Application-Id Application-Name Application-Type User Queue State Final-State Progress Tracking-URL application_1496703976885_00567 ta da SPARK cloudera default RUNNING UNDEFINED 20% http://10.0.52.156:9090

Verifique los ID de la aplicación, si son más de 1 o más de 2, elimínelos. Su clúster no puede ejecutar más de 2 aplicaciones de chispa al mismo tiempo. No estoy 100% seguro de esto, pero en el clúster si ejecuta más de dos aplicaciones de chispa, comenzará a quejarse. Entonces, mátalos. Haz esto para matarlos:

yarn application -kill application_1496703976885_00567

  1. Verifica tus parámetros de configuración de chispa. Por ejemplo, si ha establecido más memoria de ejecutor o memoria de controlador o número de ejecutores en su aplicación de chispa que también puede causar un problema. Por lo tanto, reduzca cualquiera de ellos y ejecute su aplicación de chispa, que podría resolverlo.

Me enfrenté al mismo problema en la VM de arranque rápido de clouera cuando traté de ejecutar pyspark shell. Cuando veo los registros de trabajos en el administrador de recursos, veo

17/02/18 22:20:53 ERROR yarn.ApplicationMaster: Failed to connect to driver at RM IP.

Eso significa que el trabajo no puede conectarse a RM (administrador de recursos) porque de manera predeterminada, pyspark intenta iniciarse en modo hilo en la máquina virtual cloudera.

pyspark --master local

trabajó para mi . Incluso los RM iniciales resolvieron el problema.

Gracias

Obtuve este error en esta situación:

  1. MASTER = hilo (o hilo-cliente)
  2. spark-submit se ejecuta en una computadora fuera del clúster y no hay ninguna ruta desde el clúster hacia él porque está oculto por un enrutador

Registros para container_1453825604297_0001_02_000001 (desde la interfaz de usuario web ResourceManager):

16/01/26 08:30:38 INFO yarn.ApplicationMaster: Waiting for Spark driver to be reachable. 16/01/26 08:31:41 ERROR yarn.ApplicationMaster: Failed to connect to driver at 192.168.1.180:33074, retrying ... 16/01/26 08:32:44 ERROR yarn.ApplicationMaster: Failed to connect to driver at 192.168.1.180:33074, retrying ... 16/01/26 08:32:45 ERROR yarn.ApplicationMaster: Uncaught exception: org.apache.spark.SparkException: Failed to connect to driver! at org.apache.spark.deploy.yarn.ApplicationMaster.waitForSparkDriver(ApplicationMaster.scala:484)

Lo soluciono usando el modo de clúster de hilo: MASTER = hilo-clúster.

En otra computadora que está configurada de manera similar, pero la IP de IP es accesible desde el clúster, tanto el hilo-cliente como el grupo de hilos funcionan.

Otros pueden encontrar este error por diferentes razones, y mi punto es que revisar los registros de errores (que no se ven desde el terminal, pero la interfaz de usuario web de ResourceManager en este caso) casi siempre ayuda.

Pulso el mismo clúster de MS Azure en su clúster de chispa HDinsight.
finalmente descubrió que el problema era que el clúster no podía responderle al conductor. Supongo que utilizó el modo cliente al enviar el trabajo, ya que puede proporcionar este registro de depuración.

por lo que los ejecutores de chispas deben hablar con el programa del controlador, y la conexión TCP debe ser bidireccional. así que si su programa de controlador se está ejecutando en una máquina virtual (instancia ec2) que no es accesible a través de nombre de host o IP (debe especificar en chispa conf, por defecto a nombre de host), su estado será aceptado para siempre.

Tenía un pequeño grupo donde los recursos eran limitados (~ 3GB por nodo). Resolvió este problema al cambiar la asignación de memoria mínima a un número suficientemente bajo.

De:

yarn.scheduler.minimum-allocation-mb: 1g yarn.scheduler.increment-allocation-mb: 512m

A:

yarn.scheduler.minimum-allocation-mb: 256m yarn.scheduler.increment-allocation-mb: 256m

Tuve el mismo problema en un clúster de hadoop local con chispa 1.4 e hilo, tratando de ejecutar la chispa-cáscara. Tenía más que suficientes recursos.

Lo que ayudó fue ejecutar lo mismo desde un trabajo lsf interactivo en el clúster. Así que tal vez había algunas limitaciones de red para ejecutar hilo desde el nodo principal ...

Tuve este problema exacto cuando varios usuarios intentaban ejecutar en nuestro clúster a la vez. La solución fue cambiar la configuración del planificador.

En el archivo /etc/hadoop/conf/capacity-scheduler.xml , cambiamos la propiedad yarn.scheduler.capacity.maximum-am-resource-percent de 0.1 a 0.5 .

Al cambiar esta configuración, aumenta la fracción de los recursos que están disponibles para asignarse a los maestros de aplicación, lo que aumenta el número de maestros posibles para ejecutarse a la vez y, por lo tanto, aumenta la cantidad de posibles aplicaciones simultáneas.