Construir un pipeline no es el final: necesita seguir observándolo para saber que está funcionando correctamente. Si un trabajo de procesamiento de datos falla y lo descubre seis horas después, los datos incorrectos pueden haberse reflejado ya en informes. El monitoreo consiste en detectar problemas rápidamente. La gestión de calidad de datos consiste en evitar que los datos incorrectos pasen por el pipeline desde el principio. Las preguntas del examen DEA-C01 sobre estos temas aparecen como escenarios de estabilidad operativa y confiabilidad de datos.
CloudWatch — El servicio central de monitoreo de AWS
CloudWatch es la plataforma de monitoreo donde puede observar casi todo lo que sucede en AWS. Piense en ella como una máquina de chequeo de salud que mide los signos vitales del servicio como números y envía alertas cuando algo parece mal.
Métricas: Medidas numéricas a lo largo del tiempo. El recuento de invocaciones de funciones Lambda, la duración de ejecución de trabajos de Glue, la latencia del stream de Kinesis — todas son métricas. Algunas métricas se recopilan automáticamente; otras son métricas personalizadas que su código publica directamente.
Alarmas: Las alarmas observan una métrica y desencadenan una acción cuando cruza un umbral. Por ejemplo, si la tasa de errores de Lambda supera el 5%, enviar un correo electrónico a través de SNS o activar una política de Auto Scaling.
Logs: CloudWatch Logs recopila la salida de texto de los servicios. Las instrucciones print de funciones Lambda, los mensajes de error de trabajos Glue y los logs del sistema EMR van a CloudWatch Logs.
Logs Insights: Consulte sus logs de CloudWatch usando un lenguaje similar a SQL. Busque mensajes de error específicos en grandes volúmenes de logs, o agregue recuentos de errores por ventana de tiempo.
Monitoreo por servicio
Cada servicio de AWS publica sus propias métricas en CloudWatch.
Monitoreo de Glue: : Cuántos datos leyó el trabajo de Glue : Número de tareas fallidas : Uso de memoria heap de JVM El historial de ejecución de trabajos también es visible directamente en la consola de Glue
Monitoreo de EMR: : Si el clúster está inactivo sin trabajo activo : Proporción de contenedores esperando por recursos insuficientes La interfaz de YARN ResourceManager muestra el progreso individual de los trabajos
Monitoreo de Redshift: : Recuento actual de conexiones , : Latencia de lectura y escritura en disco : Uso de CPU Los planes de ejecución de consultas revelan consultas lentas y sus cuellos de botella
Kinesis IteratorAge: La métrica más importante de Kinesis. IteratorAge es la edad en milisegundos del registro no procesado más antiguo en el stream. Cuando este número está cerca de cero, los consumidores están siguiendo el ritmo de los productores en tiempo real. Cuando crece continuamente, los consumidores se están quedando atrás — una señal clara de que necesita más capacidad de procesamiento.
Resolución de problemas de rendimiento
Qué verificar cuando cada servicio funciona lentamente.
Rendimiento de Glue: DPU (Data Processing Unit) es la unidad de cómputo de Glue. Muy pocos DPUs significa procesamiento lento. Demasiados desperdicia dinero. El número correcto depende del volumen de datos y la complejidad de la transformación. Observe y las métricas de memoria juntas para encontrar el cuello de botella real.
Rendimiento de EMR: Cuando un trabajo es lento, verifique primero los tipos de instancia. Los trabajos Spark intensivos en memoria se benefician de instancias optimizadas para memoria (serie R). Los trabajos intensivos en cómputo se benefician de instancias optimizadas para cómputo (serie C). Mezclar instancias Spot reduce costos pero introduce riesgo de interrupción.
Shards de Kinesis: Cuando el rendimiento de Kinesis alcanza su límite, IteratorAge crece. Cada shard maneja 1 MB/s de escritura y 2 MB/s de lectura. Cuando el rendimiento es insuficiente, agregue más shards mediante resharding.
Cinco dimensiones de la calidad de datos
La calidad de datos no es simplemente correcto o incorrecto. Se evalúa en múltiples dimensiones.
| Dimensión | Significado | Ejemplo | |-----------|-------------|----------| | Completitud | ¿Están presentes los valores requeridos? | Porcentaje de registros con email NULL | | Unicidad | ¿No hay duplicados? | El mismo ID de pedido apareciendo dos veces | | Validez | ¿Los valores coinciden con el formato y rango esperados? | Fecha de 2099, edad de -5 | | Consistencia | ¿Los valores coinciden entre sistemas? | El recuento de clientes en CRM difiere del almacén | | Puntualidad | ¿Los datos llegan cuando se espera? | Datos horarios llegando con 2 horas de retraso |
!5 dimensiones de la calidad de datos
Reglas de calidad de DataBrew
AWS Glue DataBrew permite definir y aplicar automáticamente reglas de calidad de datos a través de una interfaz visual.
Ejemplos de reglas: La columna debe estar entre 0 y 150 La columna no debe contener NULLs La columna debe ser única La columna debe ser una de: "pending", "completed", "cancelled"
DataBrew aplica estas reglas al conjunto de datos completo automáticamente e informa el porcentaje de registros que violan cada regla, junto con filas de muestra que violan las reglas. Si una tasa de violación de reglas supera un umbral, el trabajo puede marcarse como fallido o generar una advertencia.
Técnicas de muestreo
Inspeccionar cientos de millones de registros requiere demasiado tiempo y dinero. El muestreo verifica un subconjunto y lo usa para estimar la calidad del conjunto de datos completo.
Muestreo aleatorio: Seleccione registros al azar del conjunto de datos completo. Simple de implementar, resultados sin sesgo. Funciona mejor cuando los datos están distribuidos uniformemente.
Muestreo estratificado: Divida los datos en grupos (estratos) y muestree una proporción fija de cada grupo. Por ejemplo, al muestrear datos de pedidos por región, asegúrese de que cada región esté representada proporcionalmente. Más preciso que el muestreo aleatorio cuando los tamaños de los grupos difieren drásticamente.
Muestreo sistemático: Seleccione cada N-ésimo registro. Por ejemplo, tome cada 100 registros de un conjunto de datos de 1 millón. Útil cuando los datos están ordenados cronológicamente y quiere detectar patrones periódicos.
Sesgo de datos (Data Skew)
El sesgo de datos ocurre cuando los datos se distribuyen de manera desigual entre nodos o particiones en un sistema de procesamiento distribuido. La mayoría de los nodos terminan rápidamente, pero todo el trabajo espera al nodo sobrecargado.
Ejemplo: Al agregar datos de pedidos por ID de cliente en Spark, si un gran cliente empresarial tiene millones de pedidos mientras todos los demás tienen docenas, esa partición queda sobrecargada.
Soluciones al sesgo: Salting: Agregar un sufijo aleatorio a claves sesgadas para distribuirlas entre múltiples particiones Reparticionamiento: Ajustar el recuento de particiones usando o Broadcast joins: Replicar una tabla pequeña en cada nodo para eliminar el costoso join con shuffle
Puntos clave del examen
"Recopilar métricas de servicios AWS y configurar alarmas" → CloudWatch "Consultar errores específicos en logs" → CloudWatch Logs Insights "Detectar retraso del consumidor de Kinesis" → Métrica IteratorAge "El trabajo de Glue procesa lento" → Ajustar el número de DPUs "EMR se queda sin memoria" → Cambiar a instancias optimizadas para memoria "Rendimiento de Kinesis insuficiente" → Agregar más shards "Verificar datos por NULLs y valores fuera de rango" → Reglas de calidad de DataBrew "Demasiados datos para inspeccionar completamente" → Usar muestreo "Algunos nodos sobrecargados en procesamiento distribuido" → Data Skew