Amazon DEA-C01: Orquestación de datos y gestión de flujos de trabajo — 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.

La orquestación y la gestión de flujos de trabajo son fundamentales para construir plataformas de datos fiables y mantenibles: coordinan los trabajos de extracción, transformación y carga (ETL), gestionan dependencias, manejan fallos e integran procesos impulsados por eventos. Este dominio cubre las opciones gestionadas de AWS para ETL por lotes, DAGs complejos, máquinas de estado sin servidor y programación de eventos, cada una con diferentes semánticas de ejecución, durabilidad y contrapartidas de escalado. Entender cuándo usar AWS Glue Workflows, MWAA, Step Functions o EventBridge Scheduler —y cómo configurar el manejo de errores y la observabilidad— es fundamental para tener pipelines predecibles y controlar los costos operativos.

AWS Glue Workflows y disparadores (triggers)

AWS Glue Workflows agrupan trabajos (jobs), rastreadores (crawlers) y disparadores (triggers) de Glue en un grafo de dependencias y te permiten ejecutar ETL de forma coordinada. Crea flujos de trabajo a través de la consola o la CLI (aws glue create-workflow --name MyWorkflow). Los disparadores se asocian a los flujos de trabajo y existen de tres tipos: programados (scheduled), bajo demanda (on-demand) y condicionales (conditional). Ejemplo de creación por CLI para un disparador programado:

aws glue create-trigger --name hourly-trigger --workflow-name MyWorkflow --type SCHEDULED --schedule "cron(0 * * * ? *)" --actions '[{"JobName":"etl-job"}]'

Los disparadores condicionales usan un Predicate que hace referencia al nombre y estado del trabajo (SUCCEEDED, FAILED). Ejemplo de JSON para un predicado: {"Logical":"AND","Conditions":[{"JobName":"prev-job","State":"SUCCEEDED"}]}. Por defecto, los disparadores condicionales de Glue se activan con el éxito; para manejar fallos, configura condiciones con State=FAILED o crea un disparador FAILED explícito para dirigir los errores a trabajos de remediación o alertas de SNS.

Patrones operativos y criterios de decisión:

Usa AWS Glue Workflows cuando necesites orquestación nativa y linaje de trabajos/rastreadores de Glue; elige disparadores para programación tipo cron o para encadenar trabajos tras su finalización.
Para invocaciones ad-hoc, usa aws glue start-workflow-run --name MyWorkflow o start-trigger para disparadores bajo demanda.
Para ramificaciones complejas o tareas que no son de Glue, prefiere Step Functions o MWAA; los flujos de trabajo de Glue son mejores cuando el pipeline está centrado en Glue.

Manejo de errores: añade disparadores FAILED, emite métricas de CloudWatch para el éxito/fallo del trabajo y envía los fallos a una cola de mensajes fallidos (dead-letter queue) de SQS/SNS a través de Lambda para reintentos automatizados e investigación.

Amazon MWAA (Managed Airflow) para DAGs complejos

MWAA proporciona un entorno gestionado de Apache Airflow para expresar DAGs complejos, dependencias de tareas, sensores y operadores personalizados. Crea entornos con aws mwaa create-environment --name MyEnv --airflow-configuration-options Key=core.executor,Value=CeleryExecutor y proporciona una ruta de S3 para los DAGs y un rol de ejecución. Detalles importantes de dimensionamiento y redes:

MWAA requiere una VPC con subredes privadas y un NAT gateway para el acceso a internet; las configuraciones que solo usan subredes públicas no están soportadas.
El comportamiento de los workers y del scheduler se controla a través de las opciones de configuración de Airflow proporcionadas en la creación del entorno (AirflowConfigurationOptions). Ajusta celery.worker_concurrency, celery.worker_autoscale y la configuración del scheduler para que coincidan con la concurrencia de tareas y la complejidad del DAG.
Monitoriza las métricas de CloudWatch (SchedulerHeartbeat, TasksFailed, TasksRunning, QueuedTasks) y escala el autoescalado de los workers o aumenta el número máximo de workers si observas un crecimiento de la cola.

Criterios de decisión:

Usa MWAA cuando necesites las características de Airflow: DAGs complejos, operadores avanzados, dependencias entre DAGs, sensores de SLA/tareas perdidas y lógica personalizada en Python.
Si las tareas son de corta duración y de un rendimiento extremadamente alto, prefiere las operaciones ETL gestionadas y sin servidor de Step Functions Express o Glue.
Mantén las tareas pesadas y de larga duración en cómputo gestionado (Glue/EMR/EKS) y usa las tareas de MWAA solo para la orquestación; evita ejecutar transformaciones de datos masivas en los propios workers de MWAA.

Manejo de errores en Airflow: usa reintentos de tareas y retry_delay en las definiciones de los DAGs, establece on_failure_callback para notificar o enviar a una cola de mensajes fallidos (dead-letter queue) de SQS, y configura el manejo de SLA a nivel de tarea para disparar DAGs de remediación.

AWS Step Functions para orquestación sin servidor

Step Functions proporciona orquestación con estado (stateful) con un lenguaje basado en JSON llamado Amazon States Language y se integra ampliamente con los servicios de AWS. Elige entre flujos de trabajo Standard y Express:

Flujos de trabajo Standard (Standard Workflows): diseñados para máquinas de estado duraderas y de larga duración (de meses a años), con semántica de ejecución de tipo exactly-once (única), historial de ejecución integrado y trazabilidad/registro por ejecución. Inícialos con aws stepfunctions start-execution --state-machine-arn arn:... --input '{"key":"value"}'.
Flujos de trabajo Express (Express Workflows): optimizados para procesamiento de alto rendimiento, baja latencia y corta duración, y son rentables a escala; utilizan una semántica de ejecución de tipo at-least-once, por lo que las tareas deben ser idempotentes o usar patrones de deduplicación.

Casos de uso y criterios de decisión:

Usa Standard cuando necesites flujos de trabajo duraderos y auditables que puedan ejecutarse durante largos períodos y requieran una semántica de ejecución única (once-only).
Usa Express para microorquestaciones impulsadas por eventos con miles de ejecuciones por segundo, donde la corta duración y la eficiencia de costos son importantes, y puedes diseñar tareas idempotentes o deduplicar en los sistemas de destino.

Manejo de errores y patrones de integración:

Usa bloques Retry en ASL para definir reintentos con ErrorEquals, IntervalSeconds, BackoffRate y MaxAttempts.
Usa bloques Catch para redirigir los fallos a ramas alternativas o a un estado Fail/Success y para poblar ResultPath con los detalles del error para diagnóstico.
Para el envío asíncrono a colas de mensajes fallidos, envía los mensajes fallidos a SQS/SNS o diseña un patrón de Step Functions que envíe las cargas útiles de error a una DLQ de SQS para su procesamiento fuera de línea. Habilita los registros de CloudWatch Logs y el rastreo de X-Ray a través de LoggingConfiguration y TracingConfiguration para la observabilidad.

EventBridge Scheduler y canalizaciones basadas en eventos

EventBridge proporciona un enrutamiento de eventos enriquecido y una función de Scheduler para tareas cron y de única ejecución. Cree reglas basadas en programación con

undefined

y adjunte destinos mediante

undefined

. Para el enrutamiento basado en eventos (patrones), use put-rule con

undefined

para enrutar eventos de S3 a Lambda, Step Functions o SQS.

Puntos operativos clave:

EventBridge admite expresiones de programación (cron y rate). Tenga en cuenta el intervalo mínimo de 5 minutos para las reglas de EventBridge al usar expresiones rate; para una granularidad más fina, considere Step Functions o una capa de sondeo.
Use EventBridge Scheduler para invocaciones futuras ad-hoc y de única ejecución, y para programaciones recurrentes; Scheduler admite zonas horarias y configuraciones de reintento flexibles por destino, y puede configurar una cola de mensajes fallidos (DLQ) de SQS para invocaciones no entregables.
Para canalizaciones de alta fiabilidad, adjunte destinos como Step Functions, Lambda o SQS y configure políticas de reintento y DLQs por destino. Por ejemplo, put-targets acepta un DeadLetterConfig con el Arn de una cola SQS.

Manejo de errores: configure intentos de reintento y backoff específicos del destino, use una DLQ para entregas fallidas y combine EventBridge con Step Functions para un manejo de errores complejo y transacciones de compensación.

Errores Comunes y Criterios de Decisión

Error: Usar Express Workflows para tareas no idempotentes. Enfoque correcto: diseñar la idempotencia (claves de deduplicación, Lambda idempotente) o usar flujos de trabajo Standard para una semántica de ejecución única (exactly-once).
Error: Asumir que los disparadores condicionales de Glue se activan en caso de fallo. Enfoque correcto: crear explícitamente disparadores de FAILED o incluir State=FAILED en el Predicate del disparador para enrutar errores.
Error: Desplegar MWAA en subredes públicas o sin NAT. Enfoque correcto: ubicar MWAA en subredes privadas y proporcionar una puerta de enlace NAT o VPC endpoints para el acceso a los servicios requeridos.
Error: Esperar programaciones de EventBridge de menos de un minuto. Enfoque correcto: recordar que las reglas de EventBridge tienen un intervalo mínimo de 5 minutos; usar Step Functions o temporizadores de Lambda para necesidades de menos de 5 minutos.
Error: No tener una estrategia centralizada de reintento/captura entre servicios. Enfoque correcto: estandarizar el reintento/backoff (ASL Retry, configuración de reintento de EventBridge, reintentos de Airflow) y usar DLQs para preservar eventos fallidos para remediación manual o automatizada.
Error: Sobrecargar los workers de MWAA con procesamiento de datos pesado. Enfoque correcto: realizar solo la orquestación en MWAA, ejecutar transformaciones pesadas en Glue/EMR/EKS y pasar punteros (rutas de S3) entre tareas.

Problema práctico: ETL por hora con picos de carga para Acme Retail

Acme Retail necesita un ETL por hora que ejecute trabajos de Glue para la ingesta de datos crudos, un DAG de enriquecimiento complejo con operadores de Python y una agregación de SKU de corta duración que debe responder a eventos de inventario de alta frecuencia. Requieren reintentos robustos y captura de fallos.

Use EventBridge para disparar una regla programada por hora que invoca un flujo de trabajo Standard de Step Functions para coordinar la canalización general.
En Step Functions, orqueste trabajos de Glue de larga duración (StartJobRun) con manejadores Retry y Catch; en caso de fallo, enrute a una DLQ de SQS y a una Lambda de remediación a través de un bloque Catch.
Despliegue los DAGs de enriquecimiento complejos en MWAA e invóquelos desde Step Functions usando la API REST de Airflow o colocando mensajes de ejecución de DAG en SQS; dimensione los workers de MWAA mediante la configuración celery.worker_autoscale basado en la concurrencia esperada y monitorice las métricas de CloudWatch para ajustar.
Para eventos de inventario de alta frecuencia, use reglas de patrón de eventos de EventBridge para enviar a un Express Step Function o Lambda con claves de idempotencia y una DLQ respaldada por SQS para absorber picos de carga.
Implemente monitorización centralizada (CloudWatch Logs/Metrics, X-Ray para Step Functions) y configure alertas sobre el crecimiento de la DLQ y el agotamiento de reintentos de tareas.

Justificación: Este diseño utiliza la herramienta adecuada para cada requisito — Step Functions para orquestación duradera entre servicios y manejo de errores, MWAA para lógica de DAG compleja, Glue para ETL gestionado y EventBridge para programación y eventos reactivos. Impone la idempotencia y el uso de DLQs para canalizaciones resilientes y observables, alineado con las mejores prácticas de AWS.

← Transformación y procesamiento de datos · Todos los dominios · Consulta y análisis de datos →

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