Amazon DEA-C01: Transformation et traitement des données — 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.

Ce domaine couvre les services et les modèles AWS utilisés pour nettoyer, transformer et préparer les données pour l’analytique et le ML à grande échelle. Il se concentre sur la sélection des outils et de la puissance de calcul appropriés (Glue, Lambda, EMR, DataBrew) en fonction du volume de données, des exigences de latence et des contraintes de coût. La compréhension des limites des services, des paramètres de configuration des tâches, et de la manière dont les formats de données et les catalogues interagissent est essentielle pour construire des pipelines fiables et incrémentiels.

Tâches ETL AWS Glue (Spark et Python shell)

Les tâches Glue Spark sont le choix principal pour l’ETL distribué à grande échelle : elles s’exécutent sur Apache Spark géré par AWS Glue, utilisent le GlueContext et opèrent sur les types DynamicFrame et Spark DataFrame. Configurez via la console ou la CLI avec le type de tâche « glueetl », le workerType (G.1X, G.2X, G.4X) et le NumberOfWorkers ; démarrez avec la CLI :

undefined

. Utilisez les API DynamicFrame (create_dynamic_frame.from_options, apply_mapping) lorsque vous avez besoin de transformations flexibles au niveau du schéma, de transformations intégrées (Relationalize, Unnest) et d’une gestion automatique des données semi-structurées ; convertissez en Spark DataFrame avec dyf.toDF() lorsque vous avez besoin de Spark SQL, de jointures plus performantes ou de UDF personnalisées.

Les tâches Glue Python shell utilisent le type de tâche « pythonshell » pour les scripts légers et les tâches de plan de contrôle. Elles sont à DPU unique (1 DPU) avec un parallélisme limité et sont idéales pour les manipulations de petits fichiers, les mises à jour de métadonnées ou l’orchestration. Configurez via

undefined

et démarrez avec

undefined

. Notez que les tâches Python shell ont une limite de 1 DPU — utilisez Spark pour les grands jeux de données.

Les signets de tâche (job bookmarks) Glue permettent un traitement incrémentiel en suivant les objets et partitions S3 déjà traités. Activez les signets dans la configuration de la tâche ou lors du démarrage des exécutions :

undefined

. Les signets fonctionnent pour les sources basées sur S3 utilisant des connecteurs intégrés ; les sources JDBC ne prennent pas en charge les signets par défaut et nécessitent un « watermarking » personnalisé ou un stockage d’état.

Glue prend désormais en charge ExecutionClass FLEX pour les tâches non urgentes et optimisées en termes de coûts. Démarrez avec

undefined

pour permettre à Glue de planifier la tâche à un coût inférieur avec des SLA de temps de démarrage assouplis. Utilisez FLEX pour les remplissages par lots (backfills) et les charges de travail non sensibles à la latence ; utilisez STANDARD pour une latence prévisible.

Critères de décision — comparaisons rapides :

• DynamicFrame vs Spark DataFrame
  • Utilisez DynamicFrame lors de l’ingestion de JSON/Parquet semi-structuré avec dérive de schéma (schema drift), en tirant parti de apply_mapping, relationalize et des transformations Glue.
  • Utilisez Spark DataFrame lorsque vous avez besoin des performances de Spark SQL, de jointures complexes, de fonctions de fenêtrage (window functions) et de bibliothèques Spark tierces.
  • Convertissez entre les deux via

undefined

et

undefined

.

• Glue Spark vs Python shell
  • Choisissez Spark pour l’ETL distribué multi-nœuds sur de grands jeux de données et lors de l’utilisation de l’intégration du Glue Catalog à grande échelle.
  • Choisissez Python shell pour les tâches petites et rapides ou les étapes d’orchestration qui ne dépassent pas 1 DPU.

AWS Lambda pour les transformations légères

Lambda est idéal pour les transformations légères, à faible latence et pilotées par les événements, déclenchées directement par S3, Kinesis ou EventBridge. Les cas d’usage typiques incluent la validation de fichiers, l’extraction de métadonnées, la conversion de JSON en CSV pour de petits fichiers, ou le traitement en flux d’enregistrements. Configurez la mémoire et le délai d’expiration (timeout) avec

undefined

. La simultanéité provisionnée (Provisioned Concurrency) peut être définie avec

undefined

pour atténuer les démarrages à froid (cold starts) pour les pipelines de streaming sensibles à la latence.

Soyez attentif aux limites de Lambda pour le traitement des données : 15 minutes d’exécution maximale, 10 Go de mémoire (10 240 Mo) et seulement 512 Mo de stockage éphémère /tmp. Pour le traitement de fichiers plus volumineux, enchaînez les traitements (divisez les fichiers), transférez-les vers S3 et invoquez une tâche Glue ou EMR, ou utilisez un traitement en plusieurs parties avec AWS Step Functions. Utilisez des variables d’environnement pour les petites configurations et des politiques de rôle IAM qui accordent strictement le moindre privilège.

Critères de décision — quand choisir Lambda :

• Utilisez Lambda lorsque le traitement par invocation respecte les contraintes de 15 minutes, 10 Go de mémoire et 512 Mo /tmp, et lorsqu’une latence de l’ordre de la seconde ou de la sous-seconde est requise.
• Évitez d’utiliser Lambda pour les transformations volumineuses, de longue durée ou gourmandes en mémoire ; utilisez plutôt Glue Spark ou EMR.

Amazon EMR pour le traitement à grande échelle

EMR est la solution de prédilection pour le traitement de big data personnalisable et à grande échelle (Spark, Hadoop, Presto, Flink) où un contrôle au niveau du cluster, des actions de bootstrap personnalisées ou des bibliothèques spécialisées sont nécessaires. Créez des clusters via la CLI avec aws emr create-cluster et choisissez soit --instance-groups, soit --instance-fleets. Les flottes d’instances (instance fleets) offrent des combinaisons flexibles de types d’instances et de modes Spot/à la demande ; les groupes d’instances (instance groups) sont des groupes plus simples, de taille fixe.

Modèles de clusters EMR à considérer :

• Clusters transitoires : démarrez avec --auto-terminate et soumettez des étapes pour que le cluster se termine une fois les étapes achevées. Bon pour la maîtrise des coûts, mais l’état HDFS et l’état local éphémères seront perdus à la terminaison.
• Clusters à longue durée de vie : ne se terminent pas automatiquement ; utilisez-les pour des charges de travail interactives, un HDFS persistant, ou lorsque de nombreuses petites tâches bénéficient du préchauffage de la JVM. Persistez les données critiques sur S3 ou un stockage Hadoop basé sur EBS si la terminaison du cluster est prévue.

Exemples de configuration :

• CLI avec groupe d’instances : aws emr create-cluster --name Prod --release-label emr-6.6.0 --use-default-roles --instance-groups InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=4
• La CLI avec flotte d’instances utilise --instance-fleets avec des allocations OnDemand/Spot et plusieurs types d’instances pour la résilience et l’optimisation des coûts.

Utilisez EMR lorsque vous avez besoin d’un contrôle total sur les composants de l’écosystème Hadoop, de scripts de bootstrap personnalisés ou d’un HDFS persistant pour les données intermédiaires ; sinon, Glue Spark est plus simple pour l’ETL Spark managé qui s’intègre avec le Glue Data Catalog.

Glue DataBrew et les transformations visuelles

Glue DataBrew est un outil visuel, no-code/low-code, pour le profilage, le nettoyage et la transformation de données, destiné aux analystes de données et aux ingénieurs travaillant de manière interactive. Créez un jeu de données à partir de S3 ou du Glue Catalog, construisez une recette de transformations dans la console, prévisualisez sur un échantillon, et exécutez des tâches pour appliquer les recettes à grande échelle. Planifiez les tâches DataBrew ou exécutez-les via la CLI avec aws databrew start-job-run --name my-databrew-job.

DataBrew est optimisé pour les tâches de préparation de données comme la standardisation, la déduplication, la conversion de type et les transformations au niveau des colonnes avec des fonctions intégrées. Il s’intègre avec le Glue Catalog et écrit les résultats sur S3. Choisissez DataBrew lorsque les utilisateurs métier ont besoin de nettoyage en libre-service et de profilage rapide ; pour une logique de transformation lourde, des jointures complexes ou de très grands jeux de données, préférez Glue Spark ou EMR.

Comparaison des transformations visuelles et basées sur le code :

• Glue DataBrew
  • Avantages : profilage rapide, basé sur des recettes, les non-codeurs peuvent construire des pipelines, planification intégrée.
  • Inconvénients : ne convient pas aux jointures distribuées très volumineuses ou très complexes et aux bibliothèques personnalisées.
• Glue Spark / EMR
  • Avantages : contrôle programmatique complet, gère des jeux de données massifs, prend en charge les bibliothèques tierces.
  • Inconvénients : nécessite des compétences de développeur et plus de configuration.

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

• Supposer que les signets de tâche (job bookmarks) de Glue fonctionnent pour les sources JDBC — les signets ne suivent que l’état des objets/partitions S3 ; pour les chargements incrémentiels JDBC, utilisez des colonnes de type watermark, la capture des changements de données (change-data-capture), ou stockez la progression dans DynamoDB/S3.
• Traiter les clusters EMR transitoires comme des systèmes avec état (stateful) — les clusters transitoires se terminent après les étapes et perdent HDFS ; persistez les données intermédiaires sur S3 ou utilisez des volumes EBS pour un stockage durable.
• Ignorer les démarrages à froid (cold starts) de Lambda dans les pipelines de streaming — les démarrages à froid augmentent la latence ; atténuez avec la concurrence provisionnée pour les chemins critiques ou utilisez des ressources de calcul à longue durée de vie pour des exigences strictes de faible latence.
• Exécuter de grandes transformations dans Glue Python shell — les tâches Python shell sont limitées à 1 DPU ; pour les grands jeux de données, utilisez des tâches Glue Spark avec les workerType/NumberOfWorkers appropriés.
• Mal configurer les types d’instances EMR : choisissez des flottes d’instances pour le coût et la flexibilité avec les instances Spot ; utilisez des groupes d’instances lorsque vous avez besoin d’une composition d’instances prévisible.
• Surutiliser Glue Flex pour les charges de travail urgentes — FLEX réduit les coûts mais peut retarder les temps de démarrage ; utilisez STANDARD pour des temps de démarrage et d’exécution prévisibles.

Problème pratique : Scénario d’utilisation

AcmeRetail traite des fichiers Parquet de parcours de navigation (clickstream) nocturnes pour les consolider dans une table unifiée de l’activité client et souhaite un traitement incrémentiel pour éviter de retraiter des mois de données tout en maintenant des coûts bas pour les remplissages (backfills) non urgents.

1. Utilisez une structure de partitionnement S3 (year=/month=/day=) et enregistrez le jeu de données dans le Glue Data Catalog.
2. Créez une tâche Glue Spark (glueetl) qui lit avec DynamicFrame.from_catalog pour la flexibilité de schéma, applique des mappages, convertit en DataFrame pour les jointures complexes, et réécrit en Parquet partitionné sur S3.
3. Activez les signets de tâche Glue (job-bookmark-enable) pour les exécutions nocturnes afin de traiter uniquement les nouvelles partitions ; pour les sources d’enrichissement JDBC, implémentez des colonnes de type watermark persistées dans DynamoDB pour suivre l’horodatage maximal traité.
4. Pour les exécutions nocturnes de routine, utilisez ExecutionClass=STANDARD ; pour le retraitement historique non urgent, soumettez les exécutions avec --execution-class FLEX pour réduire les coûts.
5. Surveillez avec les métriques CloudWatch et configurez des alarmes pour les échecs de tâches ; pour une très grande échelle ou des bibliothèques personnalisées, envisagez des clusters EMR transitoires qui écrivent les résultats intermédiaires sur S3 et se terminent automatiquement.

Justification : Cette approche tire parti du Spark managé de Glue pour des transformations scalables et des DynamicFrames pour les entrées semi-structurées, utilise les signets de tâche pour le traitement incrémentiel sur S3, et utilise FLEX pour réduire les coûts des backfills — préservant ainsi le coût, la fiabilité et la simplicité opérationnelle.

← Catalogage des données et gestion des métadonnées · Tous les domaines · Orchestration des données et gestion des flux de travail →

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

Parcourir Amazon →