Amazon DEA-C01: Calidad, validación y observabilidad de los datos — Guía de estudio

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Forma parte de la Amazon Data Engineer Associate DEA-C01 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Este dominio abarca las prácticas de extremo a extremo y los servicios de AWS utilizados para garantizar la exactitud de los datos, detectar anomalías y mantener la fiabilidad de las canalizaciones. Una validación y observabilidad sólidas reducen los defectos en etapas posteriores, cumpliendo con los SLAs y permitiendo un reprocesamiento seguro. Los ingenieros de datos deben combinar Glue Data Quality, marcos de validación, la detección de anomalías de CloudWatch, DLQs y un diseño idempotente para construir canalizaciones robustas.

Reglas y evaluación de AWS Glue Data Quality

Glue Data Quality utiliza conjuntos de reglas en Data Quality Definition Language (DQDL) para definir aserciones sobre los conjuntos de datos (recuentos de filas, umbrales de nulos, unicidad, comprobaciones SQL personalizadas). Crea conjuntos de reglas en la consola o con la CLI (patrón de ejemplo:

undefined

). Los conjuntos de reglas se pueden adjuntar a trabajos ETL de Glue o ejecutarse de forma independiente a través de las APIs StartDataQualityRuleRecommendationRun / StartDataQualityRulesetEvaluationRun para evaluar conjuntos de datos almacenados en S3, tablas del catálogo o Glue DynamicFrames.

Detalles clave de configuración y criterios de decisión:

Estructura de DQDL: las reglas incluyen ruleName, expression (DQDL o SQL), severity y action on failure. Establece explícitamente la acción en caso de fallo a FAIL para que el trabajo falle cuando las comprobaciones críticas no se superen; de lo contrario, Glue puede registrar los resultados sin hacer que la ejecución falle.
Contexto de evaluación: proporciona referencias a tablas o rutas de S3 y opciones de muestreo (escaneo completo vs. muestra) a través de parámetros del trabajo o entradas de la ejecución de evaluación para equilibrar el costo frente a la cobertura.
Salida: la evaluación de reglas escribe los resultados en las métricas de Glue y en Amazon S3 como JSON; utiliza esos artefactos para auditoría y remediación automatizada.

Cuándo usar Glue Data Quality vs. marcos externos:

Usa Glue DQDL para reglas estándar de esquema, completitud y unicidad simple que se integran de forma nativa en los trabajos y el linaje de Glue.
Usa Great Expectations (ver el siguiente subdominio) cuando necesites bibliotecas de expectativas más ricas, comprobaciones más expresivas o suites de expectativas compartidas entre múltiples sistemas.

Patrones de validación de datos en canalizaciones

La validación debe realizarse en múltiples puntos de contacto: entrada, transformación y destino. Patrones comunes:

Comprobaciones ligeras previas a la ingesta en productores de Lambda/Kinesis para el esquema y rangos de valores básicos para rechazar o enrutar filas incorrectas antes de la canalización.
Validación del lado del servidor en trabajos ETL de Glue (Spark) utilizando conjuntos de reglas DQDL y validaciones explícitas en el código. En Glue Studio, añade una transformación de Data Quality que haga referencia a un conjunto de reglas; en la CLI, pasa

undefined

o incluye parámetros de trabajo para activar las ejecuciones de evaluación.

Validación posterior a la transformación con Great Expectations integrado en trabajos de Glue Python Shell o Glue Spark. Despliega las expectativas en S3 (directorio expectations/) y carga el DataContext en el trabajo:

undefined

después de sincronizar las expectativas de S3 con el entorno del trabajo.

Comparación de opciones de validación:

Opción	Pros	Contras
Glue DQDL	integración nativa, baja sobrecarga operativa, escribe resultados en el catálogo/métricas de Glue	menos expresivo para expectativas lógicas complejas
Great Expectations	expectativas ricas, data docs, checkpoints integrados, backends extensibles	requiere empaquetar y gestionar artefactos de expectativas en S3 y orquestación en los trabajos de Glue
Comprobaciones manuales en código (Spark/DataFrame)	flexibilidad total, alto rendimiento para lógica personalizada	mayor mantenimiento, sin informes estandarizados sin trabajo adicional

Para el streaming, valida los registros en tránsito y, en caso de fallo, envíalos a una DLQ de SQS (configura la RedrivePolicy con maxReceiveCount a través de la CLI de AWS o la consola) en lugar de descartarlos. Para el procesamiento por lotes, genera un artefacto de informe de validación y falla o pon en cuarentena las salidas según la política.

Detección de anomalías y monitoreo de deriva de datos

Usa la detección de anomalías de CloudWatch para métricas operativas (registros procesados, tasa de errores, duración del trabajo). Crea un detector con la CLI:

undefined

y luego crea alarmas de CloudWatch que hagan referencia a la banda de detección de anomalías. Para la deriva a nivel de datos (cambios en la distribución, cambios en la tasa de nulos), programa trabajos de perfil de Glue DataBrew (

undefined

) para calcular estadísticas, histogramas y cuantiles; almacena los perfiles en S3 como líneas base.

Criterios de decisión para alarmas de anomalía vs. de umbral:

Elige la detección de anomalías de CloudWatch cuando los patrones de las métricas son estacionales o variables; aprende del comportamiento pasado y reduce el ajuste manual de umbrales.
Usa alarmas de umbral estático para condiciones binarias (p. ej., trabajo atascado > X horas) donde la previsibilidad es alta.

Para la detección automatizada de deriva:

Programa trabajos de perfil de DataBrew de forma regular (diaria/semanalmente según la velocidad de los datos) para capturar líneas base de métricas (% de nulos, cardinalidad, percentiles).
Compara las nuevas salidas de perfil con los perfiles de línea base, ya sea con conjuntos de reglas de Glue (comprobaciones SQL personalizadas) o con expectativas personalizadas de Great Expectations que hagan referencia a estadísticas de la línea base.
Alerta usando SNS / EventBridge cuando la deriva cruce los umbrales de la política o cuando los detectores de anomalías marquen un comportamiento inusual de las métricas.

Gestión de SLA y fiabilidad de los pipelines

La gestión de SLA vincula la observabilidad con la remediación y la ingeniería de fiabilidad. Instrumenta cada pipeline con estas métricas de base: rendimiento (registros/seg), latencia (ingesta→destino), tasa de errores, tiempo de ejecución del job y recuentos en sistemas posteriores. Utiliza CloudWatch Metrics para los jobs de Glue (métricas de ejecución del job), el retraso del consumidor (consumer lag) de Kinesis/Kafka y métricas de aplicación personalizadas a través de

undefined

Patrones de fiabilidad y detalles de configuración:

Colas de mensajes fallidos (DLQ de SQS): para consumidores de streaming (Lambda, consumidores de Kinesis), configura una DLQ y establece una RedrivePolicy(maxReceiveCount). Utiliza la retención de la DLQ y un job de procesamiento separado para inspeccionar y reprocesar los mensajes de la DLQ.
Diseño idempotente: asegura que los destinos soporten escrituras idempotentes — ejemplos:
- DynamoDB: usa PutItem con expresiones condicionales o una clave compuesta para el token de idempotencia.
- S3: escribe con patrones de renombrado atómico o usa claves basadas en el contenido (hash del registro) para que los reprocesamientos sobrescriban en lugar de duplicar.
- Redshift/Glue ETL: usa staging + MERGE por clave para deduplicar después del reprocesamiento.
Checkpointing: habilita los checkpoints del conector de Kinesis/DynamoDB y gestiona la frecuencia de los checkpoints del consumidor para equilibrar la ventana de reprocesamiento y el riesgo de duplicación.

Criterios de decisión para reintentar vs. fallo rápido:

Para fallos transitorios (throttling en sistemas de destino), implementa reintentos con retroceso exponencial (exponential backoff) y una DLQ solo después de alcanzar el máximo de reintentos.
Para fallos de calidad de datos (discrepancia de esquema), provoca un fallo rápido y escribe los registros problemáticos en un prefijo de S3 de cuarentena con metadatos para su revisión manual.

Errores Comunes y Criterios de Decisión

Las reglas de Glue Data Quality registran los fallos pero no provocan el fallo del job por defecto — configura la acción de la regla en FAIL para las comprobaciones críticas y adjunta la evaluación del conjunto de reglas a la ejecución del job.
Los pipelines de streaming sin DLQs descartan o pierden los registros fallidos — configura siempre DLQs de SQS (o un staging persistente en S3) y una política de reenvío (redrive policy) para inspeccionar y reprocesar.
El reprocesamiento sin idempotencia produce registros duplicados — diseña claves deterministas, utiliza semántica de upsert/merge en el destino o aplica claves de objeto basadas en el contenido para S3.
La detección de deriva de datos (data drift) sin líneas base produce alertas ruidosas — programa jobs de perfilado de Glue DataBrew para crear y almacenar estadísticas de referencia, y luego compara los nuevos perfiles con ellas.
La dependencia excesiva de umbrales estáticos de CloudWatch causa falsos positivos — utiliza la detección de anomalías de CloudWatch para métricas estacionales o variables y reserva los umbrales estáticos para límites no negociables.
Establecer un maxReceiveCount demasiado alto pospone el enrutamiento a la DLQ y aumenta la latencia de procesamiento — elige un maxReceiveCount sensato para que las DLQs reciban los mensajes que fallan persistentemente de manera oportuna.

Problema Práctico: Escenario de Caso de Uso

Streamline Retail se enfrenta a frecuentes errores en los informes de sistemas posteriores tras el ETL nocturno: cambios inesperados en el esquema, violaciones silenciosas de reglas y pedidos duplicados al reprocesar ejecuciones fallidas.

Implementa reglas de Glue Data Quality (DQDL) para el esquema, umbrales de nulos y unicidad en order_id; establece la acción en caso de fallo en FAIL para el job y publica los artefactos de evaluación en S3.
Añade Great Expectations en un paso de Glue Python Shell para comprobaciones de negocio complejas (consistencia de pedidos entre tablas); almacena las expectativas en S3 y ejecuta checkpoints en el pipeline.
Programa jobs de perfilado de DataBrew para capturar líneas base diarias (cardinalidad, tasa de nulos, percentiles) y utiliza comparaciones automatizadas para detectar derivas (drift).
Para los eventos de pedidos en streaming, configura una DLQ de SQS con una RedrivePolicy apropiada y crea un job de reprocesamiento para procesar los mensajes de la DLQ de forma idempotente (usando order_id como clave de deduplicación).
Instrumenta detectores de anomalías de CloudWatch para el tiempo de ejecución del job y el recuento de errores; adjunta alarmas basadas en anomalías a SNS para el escalado al personal de guardia.

Justificación de la buena práctica de AWS: combina los controles de calidad nativos de Glue para una integración rápida, Great Expectations por su expresividad, DataBrew para las estadísticas de línea base y los detectores de anomalías de CloudWatch para una monitorización adaptativa. Las DLQs y los destinos idempotentes cierran el ciclo para permitir reintentos y reprocesamientos seguros, preservando al mismo tiempo los SLAs.

← Optimización de costos para cargas de trabajo de datos · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →