AWS Glue
Guía del desarrollador

Depuración de etapas exigentes y tareas rezagadas

Puede usar perfiles de trabajo de AWS Glue para identificar etapas exigentes y tareas rezagadas en sus trabajos de extracción, transformación y carga (ETL). Una tarea rezagada tarda mucho más que las demás tareas en una etapa de un trabajo de AWS Glue. Como resultado, la etapa tarda más en completarse, lo que también retrasa el tiempo de ejecución total del trabajo.

Fusión de archivos de entrada pequeños en archivos de salida más grandes

Una tarea rezagada puede producirse si hay una distribución no uniforme de trabajo entre las diferentes tareas, o un sesgo de datos da lugar a un mayor procesamiento de datos por parte de una tarea.

Puede generar perfiles en el siguiente código—un patrón común en Apache Spark—para fusionar un gran número de archivos pequeños en archivos de salida más grandes. En este ejemplo, el conjunto de datos de entrada tiene 32 GB de archivos comprimidos Gzip JSON. El conjunto de datos de salida tiene casi 190 GB de archivos JSON sin comprimir.

El código con perfil es el siguiente:

datasource0 = spark.read.format("json").load("s3://input_path") df = datasource0.coalesce(1) df.write.format("json").save(output_path)

Visualizar las métricas con perfil en la consola de AWS Glue

Puede generar perfiles en su trabajo para examinar cuatro conjuntos de métricas diferentes:

  • Movimiento de datos de ETL

  • Mezcla de datos entre los ejecutores

  • Ejecución de trabajo

  • Perfil de la memoria

Movimiento de datos de ETL: en el perfil ETL Data Movement (Movimiento de datos de ETL), todos los ejecutores leen los bytes con bastante rapidez en la primera etapa que se completa en los primeros seis minutos. Sin embargo, el tiempo de ejecución del trabajo total es de aproximadamente una hora, componiéndose principalmente de las escrituras de datos.


          En el gráfico se muestra el perfil ETL Data Movement (Movimiento de datos de ETL).

Mezcla de datos entre los ejecutores: el número de bytes leídos y escritos durante la mezcla también muestra un pico antes de finalizar la segunda etapa, como indican las métricas Job Execution (Ejecución de trabajo) y Data Shuffle (Mezcla de datos). Una vez que se mezclan los datos de todos los ejecutores, las lecturas y escrituras siguen solo a partir del tercer ejecutor.


          Las métricas de mezcla de datos entre los ejecutores.

Ejecución de trabajo: tal como se muestra en el gráfico a continuación, todos los demás ejecutores están inactivos y finalmente se renuncia a ellos por el tiempo 10:09. En este momento, el número total de ejecutores disminuye a solo uno. Esto muestra claramente que el tercer ejecutor se compone de la tarea rezagada que más tiempo de ejecución emplea y que contribuye a la mayor parte del tiempo de ejecución del trabajo.


          Las métricas de ejecución de los ejecutores activos.

Perfil de la memoria: después de las primeras dos etapas, solo el tercer ejecutor consume memoria de forma activa para procesar los datos. Los demás ejecutores están simplemente inactivos o se ha renunciado a ellos poco después de completarse las primeras dos etapas.


          Las métricas del perfil de la memoria después de las primeras dos etapas.

Corregir ejecutores rezagados mediante la agrupación

Puede evitar los ejecutores rezagados mediante la capacitación de agrupación en AWS Glue. Utilice la agrupación para distribuir los datos de manera uniforme entre todos los ejecutores y fusionar archivos en archivos más grandes mediante el uso de todos los ejecutores disponibles en el clúster. Para obtener más información, consulte Lectura de archivos de entrada en grupos grandes.

Para comprobar los movimientos de datos de ETL en el trabajo de AWS Glue, genere perfiles en el siguiente código con la agrupación habilitada:

df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json") datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "json", transformation_ctx = "datasink4")

Movimiento de datos de ETL: las escrituras de datos ahora se transmiten en paralelo con las lecturas de datos a lo largo del tiempo de ejecución del trabajo. Como resultado, el trabajo finaliza en ocho minutos—mucho más rápido que antes.


          Los movimientos de datos de ETL muestran que se ha corregido el problema.

Mezcla de datos entre los ejecutores: como los archivos de entrada se fusionan durante las lecturas mediante la capacitación de agrupación, no hay ninguna mezcla de datos costosa después de las lecturas de datos.


          Las métricas de mezcla de datos muestran que se ha corregido el problema.

Ejecución de trabajo: las métricas de ejecución de trabajo muestran que el número total de ejecutores activos que ejecutan y procesan datos permanecen bastante constantes. No hay ningún rezagado en el trabajo. Todos los ejecutores están activos y no se renuncia a ellos hasta completarse el trabajo. Como no hay mezcla de datos intermedia alguna entre los ejecutores, solo hay una única etapa en el trabajo.


          Las métricas del widget Job Execution muestran que no hay ningún rezagado en el trabajo.

Perfil de la memoria: las métricas muestran el consumo de memoria activa entre todos los ejecutores—lo que confirma una vez más que hay actividad en todos los ejecutores. Como los datos se reciben y escriben en paralelo, la huella de memoria total de todos los ejecutores es más o menos uniforme y está muy por debajo del umbral seguro de todos los ejecutores.


          Las métricas del perfil de la memoria muestran el consumo de memoria activa entre todos los ejecutores.