Amazon DEA-C01: Orchestration des données et gestion des flux de travail — Guide d'étude

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

Fait partie du Amazon Data Engineer Associate DEA-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

L’orchestration et la gestion de flux de travail sont au cœur de la construction de plateformes de données fiables et maintenables : elles coordonnent les tâches d’extraction, de transformation et de chargement (ETL), gèrent les dépendances, traitent les échecs et intègrent les processus événementiels. Ce domaine couvre les options AWS gérées pour l’ETL par lots, les DAGs complexes, les machines à états serverless et la planification d’événements — chacune avec des sémantiques d’exécution, une durabilité et des compromis de mise à l’échelle différents. Comprendre quand utiliser AWS Glue Workflows, MWAA, Step Functions ou EventBridge Scheduler — et comment configurer la gestion des erreurs et l’observabilité — est essentiel pour obtenir des pipelines prévisibles et maîtriser les coûts opérationnels.

AWS Glue Workflows et déclencheurs (triggers)

AWS Glue Workflows regroupe des tâches Glue, des crawlers et des déclencheurs dans un graphe de dépendances et vous permet d’exécuter des ETL coordonnés. Créez des flux de travail via la console ou la CLI (aws glue create-workflow –name MonWorkflow). Les déclencheurs s’attachent aux flux de travail et sont de trois types : planifiés, à la demande et conditionnels. Exemple de création par CLI pour un déclencheur planifié :

aws glue create-trigger –name hourly-trigger –workflow-name MyWorkflow –type SCHEDULED –schedule “cron(0 * * * ? *)” –actions ‘[{“JobName”:“etl-job”}]’

Les déclencheurs conditionnels utilisent un Prédicat (Predicate) qui référence le nom et l’état d’une tâche (SUCCEEDED, FAILED). Exemple de JSON pour un prédicat : {“Logical”:“AND”,“Conditions”:[{“JobName”:“prev-job”,“State”:“SUCCEEDED”}]}. Par défaut, les déclencheurs conditionnels de Glue se déclenchent en cas de succès ; pour gérer les échecs, configurez des conditions avec State=FAILED ou créez un déclencheur FAILED explicite pour router les erreurs vers des tâches de remédiation ou des alertes SNS.

Modèles opérationnels et critères de décision :

Utilisez Glue Workflows lorsque vous avez besoin d’une orchestration native des tâches/crawlers Glue et d’un lignage des données ; choisissez les déclencheurs pour la planification cron ou pour enchaîner les tâches à leur achèvement.
Pour une invocation ad-hoc, utilisez aws glue start-workflow-run –name MyWorkflow ou start-trigger pour les déclencheurs à la demande.
Pour des branchements complexes ou des tâches non-Glue, préférez Step Functions ou MWAA ; les flux de travail Glue sont plus adaptés lorsque le pipeline est centré sur Glue.

Gestion des erreurs : ajoutez des déclencheurs FAILED, émettez des métriques CloudWatch sur le succès/échec des tâches, et envoyez les échecs vers une file d’attente de lettres mortes (dead-letter queue) SQS/SNS via Lambda pour des tentatives de réessai automatisées et des investigations.

Amazon MWAA (Managed Airflow) pour les DAGs complexes

MWAA fournit un environnement Apache Airflow géré pour exprimer des DAGs complexes, des dépendances entre tâches, des capteurs (sensors) et des opérateurs personnalisés. Créez des environnements avec aws mwaa create-environment –name MyEnv –airflow-configuration-options Key=core.executor,Value=CeleryExecutor et fournissez un chemin S3 pour les DAGs ainsi qu’un rôle d’exécution. Détails importants sur le dimensionnement et le réseau :

MWAA nécessite un VPC avec des sous-réseaux privés et une passerelle NAT pour l’accès à Internet ; les configurations avec uniquement des sous-réseaux publics ne sont pas prises en charge.
Le comportement des workers et du planificateur (scheduler) est contrôlé par les options de configuration d’Airflow fournies lors de la création de l’environnement (AirflowConfigurationOptions). Ajustez celery.worker_concurrency, celery.worker_autoscale et les paramètres du planificateur pour correspondre à la concurrence des tâches et à la complexité des DAGs.
Surveillez les métriques CloudWatch (SchedulerHeartbeat, TasksFailed, TasksRunning, QueuedTasks) et ajustez l’autoscaling des workers ou augmentez le nombre maximal de workers si vous observez une croissance de la file d’attente.

Critères de décision :

Utilisez MWAA lorsque vous avez besoin des fonctionnalités d’Airflow : DAGs complexes, opérateurs riches, dépendances inter-DAGs, capteurs de SLA/tâches manquées et logique Python personnalisée.
Si les tâches sont de courte durée et à très haut débit, préférez les options serverless comme Step Functions Express ou Glue pour les opérations ETL gérées.
Conservez les tâches lourdes et de longue durée sur des services de calcul gérés (Glue/EMR/EKS) et utilisez les tâches MWAA uniquement pour l’orchestration — évitez d’exécuter des transformations de données massives sur les workers MWAA eux-mêmes.

Gestion des erreurs dans Airflow : utilisez les tentatives de réessai (retries) et retry_delay dans les définitions de DAG, définissez on_failure_callback pour notifier ou envoyer vers une file d’attente de lettres mortes SQS, et configurez la gestion des SLA au niveau de la tâche pour déclencher des DAGs de remédiation.

AWS Step Functions pour l’orchestration serverless

Step Functions fournit une orchestration avec état (stateful) avec un langage basé sur JSON, l’Amazon States Language, et s’intègre largement avec les services AWS. Choisissez entre les flux de travail Standard et Express :

Flux de travail Standard : conçus pour des machines à états durables et de longue durée (de plusieurs mois à plusieurs années), avec une sémantique d’exécution de type “exactement une fois” (exactly-once), un historique d’exécution intégré, et un traçage/logging par exécution. Démarrez avec aws stepfunctions start-execution –state-machine-arn arn:… –input ‘{“key”:“value”}’.
Flux de travail Express : optimisés pour un traitement à haut débit, à faible latence et de courte durée, et sont rentables à grande échelle ; ils utilisent une sémantique d’exécution de type “au moins une fois” (at-least-once), donc les tâches doivent être idempotentes ou utiliser des schémas de déduplication.

Cas d’utilisation et critères de décision :

Utilisez le mode Standard lorsque vous avez besoin de flux de travail durables et auditables qui peuvent s’exécuter pendant de longues périodes et nécessitent une sémantique “une seule fois”.
Utilisez le mode Express pour des micro-orchestrations événementielles avec des milliers d’exécutions par seconde, où la courte durée et la rentabilité sont importantes, et où vous pouvez concevoir des tâches idempotentes ou dédupliquer en aval.

Gestion des erreurs et modèles d’intégration :

Utilisez les blocs Retry dans l’ASL pour définir des tentatives de réessai avec ErrorEquals, IntervalSeconds, BackoffRate et MaxAttempts.
Utilisez les blocs Catch pour rediriger les échecs vers des branches alternatives ou vers un état Fail/Success et pour remplir ResultPath avec les détails de l’erreur pour le diagnostic.
Pour la mise en file d’attente de lettres mortes asynchrone, envoyez les messages en échec vers SQS/SNS ou concevez un modèle Step Functions qui envoie les charges utiles d’erreur vers une DLQ SQS pour un traitement hors ligne. Activez CloudWatch Logs et le traçage X-Ray via LoggingConfiguration et TracingConfiguration pour l’observabilité.

EventBridge Scheduler et pipelines pilotés par les événements

EventBridge fournit un routage d’événements riche et une fonctionnalité Scheduler pour les tâches cron et ponctuelles. Créez des règles basées sur une planification avec

undefined

et attachez des cibles via

undefined

. Pour le routage piloté par les événements (basé sur des motifs), utilisez

undefined

avec

undefined

pour router les événements S3 vers Lambda, Step Functions ou SQS.

Points opérationnels clés :

EventBridge prend en charge les expressions de planification (cron et rate). Soyez conscient de l’intervalle minimum de 5 minutes pour les règles EventBridge lors de l’utilisation d’expressions rate ; pour une granularité plus fine, envisagez Step Functions ou une couche de polling.
Utilisez EventBridge Scheduler pour les invocations futures ponctuelles et ad-hoc, ainsi que pour les planifications récurrentes ; Scheduler prend en charge les fuseaux horaires et des paramètres de nouvelles tentatives flexibles par cible, et peut configurer une file d’attente de lettres mortes (DLQ) SQS pour les invocations non distribuables.
Pour les pipelines à haute fiabilité, attachez des cibles comme Step Functions, Lambda ou SQS et configurez des politiques de nouvelles tentatives et des DLQ par cible. Par exemple,

undefined

accepte un

undefined

avec l'

undefined

d’une file d’attente SQS.

Gestion des erreurs : configurez des tentatives de relance et un backoff spécifiques à la cible, utilisez une DLQ pour les livraisons échouées, et combinez EventBridge avec Step Functions pour une gestion d’erreurs complexe et des transactions de compensation.

Pièges courants et critères de décision

Erreur : Utiliser des Express Workflows pour des tâches non idempotentes. Approche correcte : concevoir l’idempotence (clés de déduplication, Lambda idempotente) ou utiliser des Standard Workflows pour une sémantique de traitement unique (exactly-once).
Erreur : Supposer que les déclencheurs conditionnels de Glue s’activent en cas d’échec. Approche correcte : créer explicitement des déclencheurs FAILED ou inclure State=FAILED dans le Predicate du déclencheur pour router les erreurs.
Erreur : Déployer MWAA dans des subnets publics ou sans NAT. Approche correcte : placer MWAA dans des subnets privés et fournir une passerelle NAT ou des points de terminaison VPC pour l’accès aux services requis.
Erreur : S’attendre à des planifications EventBridge inférieures à la minute. Approche correcte : se souvenir que les règles EventBridge ont un intervalle minimum de 5 minutes ; utiliser Step Functions ou des minuteurs Lambda pour les besoins inférieurs à 5 minutes.
Erreur : Absence de stratégie centralisée de relance/capture (retry/catch) entre les services. Approche correcte : standardiser les nouvelles tentatives/le backoff (ASL Retry, configuration de relance EventBridge, retries Airflow) et utiliser des DLQ pour préserver les événements en échec pour une remédiation manuelle/automatisée.
Erreur : Surcharger les workers MWAA avec du traitement de données lourd. Approche correcte : uniquement l’orchestration sur MWAA, exécuter les transformations lourdes sur Glue/EMR/EKS et passer des pointeurs (chemins S3) entre les tâches.

Problème pratique : ETL horaire d’Acme Retail avec des pics d’activité

Acme Retail a besoin d’un ETL horaire qui exécute des tâches Glue pour l’ingestion brute, un DAG d’enrichissement complexe avec des opérateurs Python, et une agrégation de SKU à courte durée de vie qui doit répondre à des événements d’inventaire à haute fréquence. Ils exigent des nouvelles tentatives robustes et une capture des échecs.

Utilisez EventBridge pour déclencher une règle planifiée horaire qui invoque un flux de travail Step Functions Standard pour coordonner le pipeline global.
Dans Step Functions, orchestrez les tâches Glue de longue durée (

undefined

) avec des gestionnaires Retry et Catch ; en cas d’échec, routez vers une DLQ SQS et une Lambda de remédiation via un bloc Catch. 3. Déployez les DAG d’enrichissement complexes dans MWAA et invoquez-les depuis Step Functions en utilisant l’API REST d’Airflow ou en plaçant des messages d’exécution de DAG sur SQS ; dimensionnez les workers MWAA via les paramètres

undefined

en fonction de la concurrence attendue et surveillez les métriques CloudWatch pour ajuster. 4. Pour les événements d’inventaire à haute fréquence, utilisez des règles EventBridge basées sur des motifs d’événements (event-pattern) pour pousser vers un Express Step Function ou une Lambda avec des clés d’idempotence et une DLQ basée sur SQS pour absorber les pics. 5. Implémentez une surveillance centralisée (CloudWatch Logs/Metrics, X-Ray pour Step Functions), et définissez des alertes sur la croissance de la DLQ et l’épuisement des nouvelles tentatives de tâches.

Justification : Cette conception utilise le bon outil pour chaque besoin — Step Functions pour l’orchestration inter-services durable et la gestion des erreurs, MWAA pour la logique de DAG complexe, Glue pour l’ETL géré, et EventBridge pour la planification et les événements réactifs. Elle impose l’idempotence et les DLQ pour des pipelines résilients et observables, conformes aux meilleures pratiques AWS.

← Transformation et traitement des données · Tous les domaines · Requêtage et analyse des données →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →