# Monitorización y depuración de trabajo
Puede recopilar métricas acerca de los trabajos de AWS Glue y visualizarlas en las consolas de AWS Glue y Amazon CloudWatch para identificar y solucionar problemas. La generación de perfiles en sus trabajos de AWS Glue requiere los siguientes pasos:
1. Habilitar las métricas:
1. Habilite la opción **Job metrics (Métricas del trabajo)** en la definición de trabajo. Puede habilitar la creación de perfiles en la consola de AWS Glue o como parámetro del trabajo. Para obtener más información, consulte [Definición de propiedades de trabajo para trabajos de Spark](add-job.md#create-job) o [Uso de los parámetros de trabajo en los trabajos de AWS Glue](aws-glue-programming-etl-glue-arguments.md).
1. Habilite la opción **Métricas de observabilidad AWS Glue** en la definición de trabajo. Puede habilitar la observabilidad en la consola de AWS Glue o como parámetro del trabajo. Para obtener más información consulte () [Monitorización con métricas de observabilidad de AWS Glue](monitor-observability.md).
1. Confirme que el script de trabajo inicializa `GlueContext`. Por ejemplo, el siguiente fragmento de script inicializa `GlueContext` y muestra en qué parte del script se sitúa el código con perfil. Este formato general se usa en las situaciones de depuración siguientes.
```
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import time
## @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
...
...
code-to-profile
...
...
job.commit()
```
1. Ejecute el trabajo.
1. Visualización de las métricas:
1. Visualice las métricas de trabajo en la consola AWS Glue e identifique las métricas que están fuera de lo normal para el controlador o un ejecutor.
1. Compruebe las métricas de observabilidad en la página de monitorización de las ejecuciones de tareas, en la página de detalles de las ejecuciones de tareas o en Amazon CloudWatch. Para obtener más información, consulte [Monitorización con métricas de observabilidad de AWS Glue](monitor-observability.md).
1. Acote la causa raíz mediante la métrica identificada.
1. Opcionalmente, confirme la causa raíz mediante el flujo de registros del controlador o el ejecutor de trabajo identificado.
**Casos de uso de las métricas de observabilidad de AWS Glue**
+ [Depuración de excepciones de memoria insuficiente e irregularidades relativas al trabajo](monitor-profile-debug-oom-abnormalities.md)
+ [Depuración de etapas exigentes y tareas rezagadas](monitor-profile-debug-straggler.md)
+ [Monitoreo del progreso de varios trabajos](monitor-debug-multiple.md)
+ [Monitorización de la planificación de la capacidad de DPU](monitor-debug-capacity.md)
+ [Uso de la observabilidad de AWS Glue para monitorear el uso de los recursos a fin de reducir los costos](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics)
# Depuración de excepciones de memoria insuficiente e irregularidades relativas al trabajo
Puede depurar excepciones de memoria insuficiente (OOM) e irregularidades relativas al trabajo en AWS Glue. En las siguientes secciones se describen situaciones de depuración de excepciones de memoria insuficiente del controlador Apache Spark o un ejecutor de Spark.
+ [Depuración de una excepción de memoria insuficiente del controlador](#monitor-profile-debug-oom-driver)
+ [Depuración de una excepción de memoria insuficiente del ejecutor](#monitor-profile-debug-oom-executor)
## Depuración de una excepción de memoria insuficiente del controlador
En esta situación, un trabajo de Spark está leyendo un gran número de pequeños archivos desde Amazon Simple Storage Service (Amazon S3). Convierte los archivos al formato Apache Parquet y, a continuación, los escribe en Amazon S3. El controlador Spark se está quedando sin memoria. Los datos de Amazon S3 de entrada tienen más de un millón de archivos en diferentes particiones de Amazon S3.
El código con perfil es el siguiente:
```
data = spark.read.format("json").option("inferSchema", False).load("s3://input_path")
data.write.format("parquet").save(output_path)
```
### Visualizar las métricas con perfil en la consola de AWS Glue
En el siguiente gráfico se muestra el uso de la memoria como porcentaje del controlador y los ejecutores. Este uso se traza como un punto de datos que se promedia a lo largo de los valores notificados en el último minuto. En el perfil de la memoria del trabajo, puede ver que la [memoria del controlador](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage) cruza el umbral seguro del 50 % de uso con rapidez. Por otra parte, el [uso medio de la memoria](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) en todos los ejecutores sigue siendo inferior al 4 %. Esto es una clara muestra de irregularidad en la ejecución del controlador en el trabajo de Spark.
![\[El uso de la memoria en porcentaje del controlador y los ejecutores.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-oom-memoryprofile.png)
La ejecución del trabajo produce un error enseguida y aparece el siguiente error en la pestaña **History (Historial)** de la consola de AWS Glue: Command Failed with Exit Code 1. Esta cadena de error significa que el trabajo falló debido a un error sistémico, que en este caso se trata de la falta de memoria del controlador.
![\[Mensaje de error mostrado en la consola de AWS Glue.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-oom-errorstring.png)
En la consola, elija el enlace **Error logs (Registros de error)** en la pestaña **History (Historial)** para confirmar el hallazgo relativo a la falta de memoria del controlador desde CloudWatch Logs. Busque "**Error**" en los registros de errores del trabajo para confirmar que se trató, sin duda, de una excepción de memoria insuficiente que imposibilitó la realización del trabajo:
```
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="kill -9 %p"
# Executing /bin/sh -c "kill -9 12039"...
```
En la pestaña **History (Historial)** del trabajo, elija **Logs (Registros)**. Puede encontrar el siguiente rastro de la ejecución del controlador en CloudWatch Logs al empezar el trabajo. El controlador Spark intenta listar todos los archivos en todos los directorios, crea `InMemoryFileIndex` y lanza una tarea por archivo. Esto, a su vez, hace que el controlador Spark tenga que mantener una gran cantidad de estado en memoria para realizar un seguimiento de todas las tareas. Almacena en caché la lista completa de un gran número de archivos para el índice en memoria, lo que da lugar a la falta de memoria de un controlador.
### Corregir el procesamiento de varios archivos mediante su agrupación
Puede corregir el procesamiento de los numerosos archivos mediante la capacitación de *agrupación* en AWS Glue. La agrupación se habilita automáticamente al usar marcos dinámicos y cuando el conjunto de datos de entrada tiene un gran número de archivos (más de 50 000). La agrupación le permite fusionar varios archivos en un grupo y deja que una tarea procese todo el grupo en vez de un solo archivo. Como resultado, la cantidad de estado en memoria que almacena el controlador Spark es considerablemente más baja para realizar un seguimiento de menos tareas. Para obtener más información acerca de cómo habilitar manualmente la agrupación de su conjunto de datos, consulte [Lectura de archivos de entrada en grupos más grandes](grouping-input-files.md).
Para comprobar el perfil de la memoria del 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 = "parquet", transformation_ctx = "datasink")
```
Puede monitorear el perfil de la memoria y el movimiento de datos de ETL en el perfil de trabajo de AWS Glue.
El controlador se ejecuta por debajo del umbral del 50 % de uso de la memoria durante todo el trabajo de AWS Glue. Los ejecutores transmiten los datos desde Amazon S3, los procesan y los escriben en Amazon S3. Como resultado, consumen un porcentaje de memoria inferior al 5 % en cualquier momento.
![\[El perfil de la memoria muestra que se ha corregido el problema.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-oom-memoryprofile-fixed.png)
El perfil de movimiento de datos a continuación muestra el número total de bytes de Amazon S3 que todos los ejecutores [leen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) y [escriben](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) en el último minuto a medida que progresa el trabajo. Ambos siguen un patrón similar, puesto que todos los ejecutores transmiten los datos. El trabajo termina de procesar el millón de archivos en menos de tres horas.
![\[El perfil de movimiento de datos muestra que se ha corregido el problema.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-oom-etlmovement.png)
## Depuración de una excepción de memoria insuficiente del ejecutor
En esta situación, puede aprender a depurar excepciones de memoria insuficiente que podrían producirse en los ejecutores Apache Spark. El siguiente código usa el lector de Spark MySQL para leer una gran tabla de unos 34 millones de filas en un DataFrame de Spark. A continuación, la escribe en Amazon S3 en formato Parquet. Puede proporcionar las propiedades de la conexión y usar las configuraciones de Spark predeterminadas para leer la tabla.
```
val connectionProperties = new Properties()
connectionProperties.put("user", user)
connectionProperties.put("password", password)
connectionProperties.put("Driver", "com.mysql.jdbc.Driver")
val sparkSession = glueContext.sparkSession
val dfSpark = sparkSession.read.jdbc(url, tableName, connectionProperties)
dfSpark.write.format("parquet").save(output_path)
```
### Visualizar las métricas con perfil en la consola de AWS Glue
Si la pendiente del gráfico de uso de memoria es positiva y supera el 50 por ciento, si se produce un error en el trabajo antes de que se emita la siguiente métrica, la causa bien se puede deber al agotamiento de memoria. En el siguiente gráfico se muestra que, transcurrido un minuto desde el inicio de la ejecución, el [uso medio de la memoria](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) en todos los ejecutores aumenta rápidamente por encima del 50 %. El uso llega a alcanzar el 92 % y Apache Hadoop YARN cancela el contenedor que ejecuta el ejecutor.
![\[El uso medio de la memoria en todos los ejecutores.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile.png)
Tal como aparece en el siguiente gráfico, siempre hay un [único ejecutor](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors) en ejecución hasta que el trabajo produce un error. Esto se debe al lanzamiento de un nuevo ejecutor para reemplazar el ejecutor cancelado. Las lecturas del origen de datos JDBC no se paralelizan de forma predeterminada, ya que requeriría que se particionara la tabla en una columna y que se abrieran varias conexiones. Como resultado, solo un ejecutor lee la tabla completa de forma secuencial.
![\[La ejecución de trabajo muestra un único ejecutor en ejecución hasta que el trabajo produce un error.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-oom-2-execution.png)
Tal como se muestra en el siguiente gráfico, Spark intenta lanzar una nueva tarea cuatro veces antes de producir el trabajo el error. Puede ver el [perfil de la memoria](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.used) de tres ejecutores. Cada ejecutor usa rápidamente toda su memoria. El cuarto ejecutor se queda sin memoria y el trabajo produce un error. Como resultado, su métrica no se notifica inmediatamente.
![\[Los perfiles de la memoria de los ejecutores.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-oom-2-exec-memprofile.png)
Puede confirmar desde la cadena de error de la consola de AWS Glue que el trabajo produjo un error debido a excepciones de memoria insuficiente, como se muestra en la siguiente imagen.
![\[Mensaje de error mostrado en la consola de AWS Glue.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-oom-2-errorstring.png)
**Registros de salida del trabajo:** para confirmar aún más su hallazgo de una excepción de memoria insuficiente, examine CloudWatch Logs. Al buscar **Error**, verá cómo se cancelan los cuatro ejecutores casi al mismo tiempo como se muestra en el panel de métricas. YARN termina todos, ya que superan sus límites de memoria.
Ejecutor 1
```
18/06/13 16:54:29 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 ERROR YarnClusterScheduler: Lost executor 1 on ip-10-1-2-175.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, ip-10-1-2-175.ec2.internal, executor 1): ExecutorLostFailure (executor 1 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Ejecutor 2
```
18/06/13 16:55:35 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 ERROR YarnClusterScheduler: Lost executor 2 on ip-10-1-2-16.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN TaskSetManager: Lost task 0.1 in stage 0.0 (TID 1, ip-10-1-2-16.ec2.internal, executor 2): ExecutorLostFailure (executor 2 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Ejecutor 3
```
18/06/13 16:56:37 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 ERROR YarnClusterScheduler: Lost executor 3 on ip-10-1-2-189.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN TaskSetManager: Lost task 0.2 in stage 0.0 (TID 2, ip-10-1-2-189.ec2.internal, executor 3): ExecutorLostFailure (executor 3 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Ejecutor 4
```
18/06/13 16:57:18 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 ERROR YarnClusterScheduler: Lost executor 4 on ip-10-1-2-96.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN TaskSetManager: Lost task 0.3 in stage 0.0 (TID 3, ip-10-1-2-96.ec2.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
### Corregir la configuración del tamaño de búsqueda mediante marcos dinámicos de AWS Glue
El ejecutor se quedó sin memoria durante la lectura de la tabla de JDBC, ya que la configuración predeterminada del tamaño de búsqueda de JDBC de Spark es cero. Esto significa que el controlador JDBC del ejecutor de Spark intenta recuperar los 34 millones de filas de la base de datos de forma conjunta y almacenarlas en caché, aunque Spark se transmita a través de las filas de una en una. Con Spark, puede evitar esta situación estableciendo el parámetro de tamaño de búsqueda en un valor predeterminado distinto de cero.
También puede solucionar este problema con marcos dinámicos de AWS Glue en su lugar. De forma predeterminada, los marcos dinámicos utilizan un tamaño de captura de 1000 filas, que suele ser un valor suficiente. Como resultado, el ejecutor no usa más del 7 % de su memoria total. El trabajo de AWS Glue finaliza en menos de dos minutos con un único ejecutor solamente. Aunque el enfoque recomendado es utilizar los marcos dinámicos de AWS Glue, también se puede definir el tamaño de captura con la propiedad `fetchsize` de Apache Spark. Consulte la [guía de Spark SQL, DataFrames y Datasets](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html#jdbc-to-other-databases).
```
val (url, database, tableName) = {
("jdbc_url", "db_name", "table_name")
}
val source = glueContext.getSource(format, sourceJson)
val df = source.getDynamicFrame
glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink")
```
**Métricas con perfil normales**: la [memoria del ejecutor](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) con marcos dinámicos de AWS Glue nunca supera el umbral seguro, como se muestra en la siguiente imagen. Se transmite en las filas de la base de datos y almacena en caché solo 1000 filas en el controlador JDBC en cualquier momento. No se producen excepciones de memoria insuficiente.
![\[La consola de AWS Glue muestra que la memoria del ejecutor está por debajo del umbral seguro.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile-fixed.png)
# 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](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) 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](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) de datos.
![\[En el gráfico se muestra el perfil ETL Data Movement (Movimiento de datos de ETL).\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-straggler-1.png)
**Mezcla de datos entre los ejecutores:** el número de bytes [leídos](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead) y [escritos](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten) 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.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-straggler-2.png)
**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.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-straggler-3.png)
**Perfil de la memoria:** después de las primeras dos etapas, solo el [tercer ejecutor](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) 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.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-straggler-4.png)
### Corregir ejecutores rezagados mediante 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 más grandes](grouping-input-files.md).
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.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-straggler-5.png)
**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.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-straggler-6.png)
**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.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-straggler-7.png)
**Perfil de memoria:** las métricas muestran el [consumo de memoria activa](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) 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.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-straggler-8.png)
# Monitoreo del progreso de varios trabajos
Puede generar perfiles en varios trabajos de AWS Glue de forma conjunta y monitorear el flujo de datos entre ellos. Se trata de un patrón de flujo de trabajo habitual y requiere el monitoreo del progreso de trabajos individuales, las tareas pendientes de procesamiento de datos, el reprocesamiento de datos y los marcadores de trabajos.
**Topics**
+ [Código con perfil](#monitor-debug-multiple-profile)
+ [Visualizar las métricas con perfil en la consola de AWS Glue](#monitor-debug-multiple-visualize)
+ [Corregir el procesamiento de los archivos](#monitor-debug-multiple-fix)
## Código con perfil
En este flujo de trabajo, tiene dos trabajos: un trabajo de entrada y un trabajo de salida. El trabajo de entrada está programado para ejecutarse cada 30 minutos mediante un disparador periódico. El trabajo de salida está programado para ejecutarse tras cada ejecución correcta del trabajo de entrada. Estos trabajos programados se controlan mediante disparadores del trabajo.
![\[Captura de pantalla de la consola que muestra los disparadores del trabajo que controlan la programación de los trabajos de entrada y salida.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-multiple-1.png)
**Trabajo de entrada**: este trabajo lee datos desde una ubicación de Amazon Simple Storage Service (Amazon S3), los transforma mediante `ApplyMapping` y los escribe en una ubicación de Amazon S3 provisional. El siguiente código es código con perfil para el trabajo de entrada:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": ["s3://input_path"], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": staging_path, "compression": "gzip"}, format = "json")
```
**Trabajo de salida**: este trabajo lee la salida del trabajo de entrada desde la ubicación provisional en Amazon S3, la vuelve a transformar y la escribe en un destino:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "json")
```
## Visualizar las métricas con perfil en la consola de AWS Glue
El siguiente panel superpone la métrica escrita de bytes de Amazon S3 desde el trabajo de entrada en la métrica leída de bytes de Amazon S3 en la misma escala de tiempo del trabajo de salida. La escala de tiempo muestra diferentes ejecuciones de trabajo de los trabajos de entrada y salida. El trabajo de entrada (mostrado en rojo) comienza cada 30 minutos. El trabajo de salida (mostrado en marrón) comienza al finalizar el trabajo de entrada, con una simultaneidad máxima de 1.
![\[Gráfico donde se muestran los datos leídos y escritos.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-multiple-4.png)
En este ejemplo, los [marcadores de trabajos](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html) no están habilitados. No se usa ningún contexto de transformación para habilitar marcadores de trabajos en el código de script.
**Historial de trabajos**: los trabajos de entrada y salida tienen varias ejecuciones, como se muestra en la pestaña **History (Historial)**, las cuales comienzan a partir de las 12:00 h.
El trabajo de entrada de la consola de AWS Glue tiene este aspecto:
![\[Captura de pantalla de la consola donde se muestra la pestaña History (Historial) del trabajo de entrada.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-multiple-2.png)
En la siguiente imagen se muestra el trabajo de salida:
![\[Captura de pantalla de la consola donde se muestra la pestaña History (Historial) del trabajo de salida.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-multiple-3.png)
**Primeras ejecuciones de trabajo**: como se muestra en el siguiente gráfico de bytes de datos leídos y escritos, las primeras ejecuciones de trabajo de los trabajos de entrada y salida entre las 12:00 y las 12:30 h muestran más o menos la misma área bajo las curvas. Esas áreas representan los bytes de Amazon S3 escritos por el trabajo de entrada y los bytes de Amazon S3 leídos por el trabajo de salida. Estos datos también están confirmados por la relación de bytes de Amazon S3 escritos (suma de más de 30 minutos, la frecuencia del desencadenador de trabajo para el trabajo de entrada). El punto de datos de la relación para la ejecución de trabajo de entrada que comenzó a las 12:00 h también es 1.
En el siguiente gráfico se muestra la relación de flujo de datos entre todas las ejecuciones de trabajo:
![\[Gráfico donde se muestra la relación de flujo de datos: bytes escritos y bytes leídos.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-multiple-5.png)
**Segundas ejecuciones de trabajo**: en la segunda ejecución de trabajo, existe una clara diferencia entre el número de bytes leídos por el trabajo de salida y el número de bytes escritos por el trabajo de entrada (compare el área bajo la curva entre las dos ejecuciones de trabajo para el trabajo de salida, o bien las áreas en la segunda ejecución de los trabajos de entrada y salida). La relación de los bytes leídos y escritos muestra que el trabajo de salida lee alrededor de 2,5 veces los datos escritos por el trabajo de entrada en el segundo periodo de 30 minutos de 12:30 a 13:00 h. Esto se debe a que el trabajo de salida reprocesó la salida de la primera ejecución de trabajo del trabajo de entrada porque los marcadores de trabajos no estaban habilitados. Una relación superior a 1 muestra que hay tareas pendientes adicionales de datos que el trabajo de salida procesó.
**Terceras ejecuciones de trabajo**: el trabajo de entrada es bastante coherente en términos del número de bytes escritos (consulte el área bajo las curvas rojas). Sin embargo, la tercera ejecución de trabajo del trabajo de entrada se ejecutó más tiempo del que se había previsto (consulte la larga cola de la curva roja). Como resultado, la tercera ejecución de trabajo del trabajo de salida comenzó tarde. La tercera ejecución de trabajo procesó solo una fracción de los datos acumulados en la ubicación provisional durante los 30 minutos restantes entre las 13:00 y las 13:30 h. La relación del flujo de bytes muestra que solo procesó 0,83 de los datos escritos por la tercera ejecución de trabajo del trabajo de entrada (consulte la relación a las 13:00 h).
**Solapamiento de los trabajos de entrada y salida**: la cuarta ejecución de trabajo del trabajo de entrada comenzó a las 13:30 h según el programa, antes de finalizar la tercera ejecución de trabajo del trabajo de salida. Existe un solapamiento parcial entre estas dos ejecuciones de trabajo. Sin embargo, la tercera ejecución de trabajo del trabajo de salida captura solo los archivos que listó en la ubicación provisional de Amazon S3 cuando empezó alrededor de las 13:17 h. Esta consta de la salida de todos los datos de las primeras ejecuciones de trabajo del trabajo de entrada. La relación real a las 13:30 h es de aproximadamente 2,75. La tercera ejecución de trabajo del trabajo de salida procesó alrededor de 2,75 veces los datos escritos por la cuarta ejecución de trabajo del trabajo de entrada de 13:00 a 14:00 h.
Tal como muestran estas imágenes, el trabajo de salida reprocesa datos de la ubicación provisional de todas las ejecuciones de trabajo anteriores del trabajo de entrada. Como resultado, la cuarta ejecución de trabajo para el trabajo de salida es la más larga y se solapa con la quinta ejecución de trabajo al completo del trabajo de entrada.
## Corregir el procesamiento de los archivos
Debe garantizar que el trabajo de salida procese solo los archivos que no han procesado las ejecuciones de trabajo anteriores del trabajo de salida. Para ello, habilite marcadores de trabajos y establezca el contexto de transformación en el trabajo de salida, como se indica a continuación:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json", transformation_ctx = "bookmark_ctx")
```
Con los marcadores de trabajos habilitados, el trabajo de salida no reprocesa los datos en la ubicación provisional de todas las ejecuciones de trabajo anteriores del trabajo de entrada. En la siguiente imagen donde se muestran los datos leídos y escritos, el área bajo la curva marrón es bastante coherente y similar a la de las curvas rojas.
![\[Gráfico donde se muestran los datos leídos y escritos como líneas rojas y marrones.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-multiple-6.png)
Las relaciones de flujo de bytes también permanecen más o menos próximas a 1 al no haber datos adicionales procesados.
![\[Gráfico donde se muestra la relación de flujo de datos: bytes escritos y bytes leídos\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-multiple-7.png)
Una ejecución de trabajo para el trabajo de salida comienza y captura los archivos en la ubicación provisional antes de que la siguiente ejecución de trabajo de entrada comience a poner más datos en la ubicación provisional. Siempre que siga haciendo esto, procesará solo los archivos capturados de la ejecución de trabajo de entrada anterior, mientras que la relación permanece próxima a 1.
![\[Gráfico donde se muestra la relación de flujo de datos: bytes escritos y bytes leídos\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-multiple-7.png)
Supongamos que el trabajo de entrada tarda más de lo esperado y, como resultado, el trabajo de salida captura archivos en la ubicación provisional de dos ejecuciones de trabajo de entrada. A continuación, la relación es mayor que 1 para esa ejecución de trabajo de salida. Sin embargo, las siguientes ejecuciones de trabajo del trabajo de salida no procesan ningún archivo que ya hayan procesado las ejecuciones de trabajo anteriores del trabajo de salida.
# Monitorización de la planificación de la capacidad de DPU
Puede usar las métricas de trabajos en AWS Glue para estimar el número de unidades de procesamiento de datos (DPU) que se puede utilizar para escalar en horizontal un trabajo de AWS Glue.
**nota**
Esta página solo corresponde para versiones 0.9 y 1.0 de AWS Glue. Las versiones posteriores de AWS Glue contienen funciones de ahorro de costos que introducen consideraciones adicionales a la hora de planificar la capacidad.
**Topics**
+ [Código con perfil](#monitor-debug-capacity-profile)
+ [Visualizar las métricas con perfil en la consola de AWS Glue](#monitor-debug-capacity-visualize)
+ [Determinar la capacidad de DPU óptima](#monitor-debug-capacity-fix)
## Código con perfil
El siguiente script lee una partición de Amazon Simple Storage Service (Amazon S3) que contiene 428 archivos gzip JSON. El script aplica un mapeo para cambiar los nombres de los campos y convertirlos y escribirlos en Amazon S3 en formato Apache Parquet. Aprovisione 10 DPU según el valor predeterminado y ejecute este trabajo.
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [input_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [(map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet")
```
## Visualizar las métricas con perfil en la consola de AWS Glue
**Ejecución de trabajo 1:** en esta ejecución de trabajo, mostramos cómo encontrar si hay DPU de aprovisionamiento deficiente en el clúster. La funcionalidad de ejecución de trabajos de AWS Glue muestra el [número de ejecutores que se ejecutan activamente](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors) total, el [número de fases completadas](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages) y el [número máximo de ejecutores necesarios](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors).
El número máximo de ejecutores necesarios se calcula añadiendo el número total de tareas en ejecución y tareas pendientes, y dividiéndolo entre las tareas por ejecutor. Este resultado es una medida del número total de ejecutores necesarios para satisfacer la carga actual.
Por contraste, el número de ejecutores que se ejecutan activamente mide cuántos ejecutores ejecutan tareas Apache Spark activas. A medida que progresa el trabajo, el número máximo de ejecutores necesarios puede cambiar y suele reducirse hacia el final del trabajo al disminuir la cola de tareas pendientes.
La línea roja horizontal del siguiente gráfico muestra el número máximo de ejecutores asignados, que depende del número de DPU que asigna para el trabajo. En este caso, asigna 10 DPU para la ejecución de trabajo. Una DPU está reservada para administración. Nueve DPU ejecutan dos ejecutores cada una y un ejecutor se reserva para el controlador Spark. El controlador Spark se ejecuta dentro de la aplicación principal. Así pues, el número máximo de ejecutores asignados es 2 x 9 -1 = 17 ejecutores.
![\[Métricas de trabajos que muestran los ejecutores activos y el número máximo de ejecutores necesarios.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-capacity-1.png)
Tal como se muestra en el gráfico, el número máximo de ejecutores necesarios parte de 107 al principio del trabajo, mientras que el número de ejecutores activos sigue siendo 17. Este es igual al número máximo de ejecutores asignados con 10 DPU. La relación entre el número máximo de ejecutores necesarios y el número máximo de ejecutores asignados (que añade 1 a ambos para el controlador Spark) le ofrece el factor de aprovisionamiento deficiente: 108/18 = 6x. Puede aprovisionar 6 (por debajo de la proporción de aprovisionamiento)\$1 9 (capacidad de DPU actual - 1)\$11 DPU = 55 DPU para escalar en horizontal el trabajo a fin de ejecutarlo con el máximo paralelismo y finalizar con mayor rapidez.
La consola de AWS Glue muestra las métricas detalladas de trabajos como una línea estática que representa el número original de ejecutores máximos asignados. La consola calcula los ejecutores máximos asignados a partir de la definición de trabajo de las métricas. En cambio, para las métricas detalladas de ejecución de trabajos, la consola calcula los ejecutores máximos asignados a partir de la configuración de ejecución de trabajos, específicamente las DPU asignadas a la ejecución de trabajos. Para ver las métricas de una ejecución de trabajo individual, seleccione la ejecución de trabajo y elija **View run metrics (Ver métricas de ejecución)**.
![\[Métricas de trabajos que muestran el movimiento de datos de ETL.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-capacity-2.png)
Al examinar los bytes de Amazon S3 [leídos](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) y [escritos](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes), observe que el trabajo dedica los seis minutos a la streaming de datos desde Amazon S3 y a escribir dichos datos en paralelo. Todos los núcleos de las DPU asignadas leen y escriben en Amazon S3. El número máximo de ejecutores necesarios, 107, también coincide con el número de archivos en la ruta de entrada de Amazon S3, 428. Cada ejecutor puede lanzar cuatro tareas Spark para procesar cuatro archivos de entrada (gzip JSON).
## Determinar la capacidad de DPU óptima
En función de los resultados de la ejecución de trabajo anterior, puede aumentar el número total de DPU asignadas a 55, así como consultar el rendimiento del trabajo. El trabajo finaliza en menos de tres minutos, la mitad del tiempo que requería anteriormente. El escalado en horizontal del trabajo no es lineal en este caso porque se trata de un trabajo de corta ejecución. Los trabajos con tareas de larga duración o un gran número de tareas (un gran número correspondiente al máximo de ejecutores necesarios) se benefician de una aceleración de rendimiento de escalado en horizontal de DPU casi lineal.
![\[Gráfico donde se muestra el aumento del número total de DPU asignadas\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-capacity-3.png)
Tal como se muestra en la imagen anterior, el número total de ejecutores activos alcanza el máximo asignado, 107 ejecutores. Del mismo modo, el número máximo de ejecutores necesarios nunca supera el número máximo de ejecutores asignados. El número máximo de ejecutores necesarios se calcula a partir de los recuentos de tareas pendientes y tareas que se ejecutan activamente, por lo que podría ser inferior al número de ejecutores activos. Esto se debe a que puede haber ejecutores que estén inactivos parcial o completamente durante un corto periodo de tiempo y no se hayan retirado aún.
![\[Gráfico donde se muestra el número total de ejecutores activos que alcanzan el máximo asignado.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-capacity-4.png)
Esta ejecución de trabajo usa seis veces más ejecutores para leer y escribir desde Amazon S3 en paralelo. Como resultado, esta ejecución de trabajo usa más ancho de banda de Amazon S3 tanto para las lecturas como para las escrituras, y finaliza con mayor rapidez.
### Identificar DPU sobreaprovisionadas
A continuación, puede determinar si escalar en horizontal el trabajo con 100 DPU (99 x 2 = 198 ejecutores) ayuda a escalar más en horizontal. Tal como se muestra en el siguiente gráfico, el trabajo sigue tardando tres minutos en finalizar. Del mismo modo, el trabajo no escala en horizontal más allá de 107 ejecutores (configuración de 55 DPU) y los 91 ejecutores restantes están sobreaprovisionados y no se han utilizado en absoluto. Esto muestra que es posible que aumentar el número de DPU no siempre mejore el rendimiento, como se desprende del número máximo de ejecutores necesarios.
![\[Gráfico donde se muestra que el rendimiento del trabajo no siempre aumenta al aumentar el número de DPU.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/monitor-debug-capacity-5.png)
### Comparar las diferencias de tiempo
Las tres ejecuciones de trabajo mostradas en la siguiente tabla resumen los tiempos de ejecución de trabajo para 10 DPU, 55 DPU y 100 DPU. Puede encontrar la capacidad de DPU para mejorar el tiempo de ejecución de trabajo mediante las estimaciones que estableció monitorizando la primera ejecución de trabajo.
| ID de tarea | Número de DPU | Hora de ejecución |
| --- | --- | --- |
| jr\$1c894524c8ef5048a4d9... | 10 | 6 min. |
| jr\$11a466cf2575e7ffe6856... | 55 | 3 min. |
| jr\$134fa1ed4c6aa9ff0a814... | 100 | 3 min. |