Acerca de la supervisión de los trabajos de AWS Glue Streaming
Supervisar el trabajo de transmisión es una parte fundamental de la creación de su canalización de ETL. Además de usar la interfaz de usuario de Spark, también puede usar Amazon CloudWatch para supervisar las métricas. A continuación se muestra una lista de las métricas de transmisión que emite el marco de AWS Glue. Para obtener una lista completa de todas las métricas de AWS Glue, consulte Supervisión de AWS Glue mediante métricas de Amazon CloudWatch.
AWS Glue usa un marco de transmisión estructurado para procesar los eventos de entrada. Puede usar la API de Spark directamente en el código o aprovechar ForEachBatch que proporciona GlueContext, que publica estas métricas. Para entender estas métricas, primero debemos entender windowSize.
windowSize: windowSize es el intervalo de microlotes que usted proporciona. Si especifica un tamaño de ventana de 60 segundos, el trabajo de transmisión de AWS Glue esperará 60 segundos (o más si el lote anterior no se ha completado para entonces) antes de leer los datos de un lote procedentes del origen de transmisión y aplicar las transformaciones incluidas en ForEachBatch. Esto también se denomina intervalo de activación.
Revisemos las métricas con más detalle para comprender las características de estado y rendimiento.
nota
Estas métricas se emiten cada 30 segundos. Si windowSize tiene menos de 30 segundos, las métricas informadas son una agregación. Por ejemplo, supongamos que windowSize tiene 10 segundos y que está procesando 20 registros de forma constante por microlote. En este escenario, el valor métrico emitido de numRecords sería 60.
No se emite una métrica si no hay datos disponibles para ella. Además, en el caso de la métrica de retraso de consumo, debe habilitar la característica para obtener las métricas correspondientes.
Cómo obtener el mejor rendimiento
Spark intentará crear una tarea por fragmento para poder leerla en el flujo de Amazon Kinesis. Los datos de cada fragmento se convierten en una partición. Luego, distribuirá estas tareas entre los ejecutores o trabajos, en función del número de núcleos de cada trabajo (el número de núcleos por trabajo depende del tipo de trabajo que seleccione, como G.025X, G.1X, etc.). Sin embargo, la forma en que se distribuyen las tareas no es determinista. Todas las tareas se ejecutan en paralelo en sus respectivos núcleos. Si hay más fragmentos que el número de núcleos ejecutores disponibles, las tareas se ponen en cola.
Puede usar una combinación de las métricas anteriores y el número de fragmentos para aprovisionar los ejecutores a fin de garantizar una carga estable con espacio para las ráfagas. Se recomienda realizar algunas iteraciones del trabajo para determinar el número aproximado de trabajos. Para una carga de trabajo inestable o con picos, puede hacer lo mismo al configurar el escalado automático y el número máximo de trabajos.
Configure windowSize de acuerdo con los requisitos de SLA de su empresa. Por ejemplo, si su empresa exige que los datos procesados no puedan estar inactivos durante más de 120 segundos, configure windowSize en al menos 60 segundos, de forma que el retraso promedio de consumo sea inferior a 120 segundos (consulte la sección anterior acerca del retraso de consumo). A partir de ahí, en función de numRecords y del número de fragmentos, planifique la capacidad de las DPU asegurándose de que batchProcessingTimeInMs sea inferior al 70 % de windowSize la mayor parte del tiempo.
nota
Los fragmentos activos pueden distorsionar los datos, lo que significa que algunos fragmentos o particiones son mucho más grandes que otros. Esto puede provocar que algunas tareas que se ejecutan en paralelo tarden más tiempo, lo que genera que las tareas queden rezagadas. Como resultado, el siguiente lote no puede comenzar hasta que se hayan completado todas las tareas del anterior, lo que afectará batchProcessingTimeInMillis y el retraso máximo.
