¿Por qué falla mi trabajo de ETL de AWS Glue y aparece el error «Contenedor eliminado por YARN porque superaba los límites de memoria»?

5 minutos de lectura
0

Mi trabajo de extracción, transformación y carga (ETL) de AWS Glue falla y aparece el error «Contenedor eliminado por YARN porque superaba los límites de memoria».

Descripción breve

Las causas más comunes de este error son las siguientes:

  • Operaciones que consumen mucha memoria, como unir tablas grandes o procesar conjuntos de datos con un sesgo en la distribución de valores de columnas específicas y que superen el umbral de memoria del clúster de Spark subyacente
  • Particiones grandes de datos que consumen más memoria que la asignada al ejecutor respectivo
  • Archivos grandes que no se pueden dividir, lo que da como resultado particiones grandes en la memoria

Resolución

Para resolver este error, elija una o más de las siguientes soluciones:

  • Actualice el tipo de proceso de trabajo de G.1x a G.2x que tenga configuraciones de memoria superiores. Para obtener más información sobre las especificaciones de los tipos de proceso de trabajo, consulte la sección Tipo de proceso de trabajo en Definición de propiedades de trabajo para trabajos de Spark.
  • Para obtener más información sobre la migración de AWS Glue 2.0 a 3.0, consulte Migrar de AWS Glue 2.0 a AWS Glue 3.0.
  • También puede consultar la siguiente tabla para obtener información sobre las especificaciones del tipo de proceso de trabajo:
AWS Glue versiones 1.0 y 2.0
Estándarspark.executor.memory: 5 g spark.driver.memory: 5 g spark.executor.cores: 4
G.1xspark.executor.memory: 10 g spark.driver.memory: 10 g spark.executor.cores: 8
G.2xspark.executor.memory: 20 g spark.driver.memory: 20 g spark.executor.cores: 16
AWS Glue versión 3.0
Estándarspark.executor.memory: 5 g spark.driver.memory: 5 g spark.executor.cores: 4
G.1xspark.executor.memory: 10 g spark.driver.memory: 10 g spark.executor.cores: 4
G.2xspark.executor.memory: 20 g spark.driver.memory: 20 g spark.executor.cores: 8
  • Si el error persiste después de actualizar el tipo de proceso de trabajo, aumente el número de ejecutores del trabajo. Cada ejecutor tiene un número determinado de núcleos. Este número determina el número de particiones que puede procesar el ejecutor. Las configuraciones de Spark para las unidades de procesamiento de datos (DPU) se definen en función del tipo de proceso de trabajo.
  • Asegúrese de que los datos estén correctamente paralelizados para que los ejecutores se puedan utilizar de manera uniforme antes de cualquier operación de mezcla aleatoria, como las uniones. Puede volver a hacer particiones en los datos de todos los ejecutores. Para ello, incluya los siguientes comandos: DynamicFrame para AWS Glue y Spark DataFrame en su trabajo de ETL, respectivamente.
dynamicFrame.repartition(totalNumberOfExecutorCores)

dataframe.repartition(totalNumberOfExecutorCores)
  • El uso de marcadores de trabajo permite que el trabajo de AWS Glue solo procese los archivos recién escritos. Esto reduce la cantidad de archivos que procesa la tarea de AWS Glue y los problemas de memoria. Los marcadores almacenan los metadatos de los archivos procesados en la ejecución anterior. En la ejecución posterior, el trabajo compara la marca de tiempo y, a continuación, decide si desea volver a procesar estos archivos. Para obtener más información, consulte Seguimiento de los datos procesados mediante marcadores de trabajo.
  • Al conectarse con una tabla de JDBC, Spark abre de forma predeterminada solo una conexión cada vez. El controlador intenta descargar toda la tabla a la vez en un único ejecutor de Spark. Esto puede llevar más tiempo e incluso provocar errores de falta de memoria para el ejecutor. Puede optar por establecer propiedades específicas de la tabla JDBC para indicar a AWS Glue que lea los datos en paralelo a través de DynamicFrame. Para obtener más información, consulte Lectura de tablas de JDBC en paralelo. También puede lograr lecturas paralelas desde JDBC a través de Spark DataFrame. Para obtener más información, consulte Lecturas en paralelo de Spark DataFrame desde JDBC y consulte las propiedades, como partitionColumn, lowerBound, upperBound y numPartitions.
  • No utilice funciones definidas por el usuario en su trabajo de ETL, especialmente al combinar código de Python/Scala con funciones y métodos de Spark. Por ejemplo, no utilice df.count() de Spark para verificar DataFrames vacíos dentro de declaraciones if/else o de bucles. En cambio, utilice una función con mejor rendimiento, como df.schema() o df.rdd.isEmpty().
  • Pruebe el trabajo de AWS Glue en un punto de conexión de desarrollo y optimice el código de ETL en consecuencia.
  • Si ninguna de las opciones de solución de problemas anteriores funciona, divida los datos de entrada en fragmentos o particiones. A continuación, ejecute varios trabajos de ETL de AWS Glue en lugar de ejecutar un trabajo grande. Para obtener más información, consulte Partición de cargas de trabajo con ejecución limitada.

Información relacionada

Depuración de excepciones de memoria insuficiente e irregularidades relativas al trabajo

Prácticas recomendadas para escalar trabajos de Apache Spark y fragmentar datos con AWS Glue

Optimización de la administración de memoria en AWS Glue

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace 2 años