Amazon DEA-C01: Ingestion et collecte 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 modèles, les services AWS et les détails opérationnels utilisés pour intégrer des données brutes dans une plateforme de données de manière fiable et à grande échelle. Les ingénieurs de données doivent choisir entre des points d’entrée par lots (batch) et en streaming, assurer le catalogage et la découvrabilité des données, et concevoir en fonction du débit, de la rejouabilité et des modes de défaillance. Les composants AWS clés sont S3 et Glue pour le traitement par lots, Kinesis et Firehose pour le streaming, DMS pour la migration de bases de données et le CDC, ainsi que les composants pilotés par API/événements (API Gateway, Lambda, SNS, SQS, événements S3) pour l’ingestion ad-hoc et basée sur des notifications (push).

Ingestion par lots avec AWS Glue et S3

Glue est la principale solution gérée d’ETL et de métadonnées pour l’ingestion par lots dans S3 et votre catalogue de données. Modèle typique : déposer les fichiers bruts dans S3 (avec des préfixes distincts pour les zones brutes/raw), exécuter un crawler Glue pour inférer le schéma et remplir le Glue Data Catalog, puis exécuter des tâches ETL Glue (Spark) pour transformer, partitionner, convertir en formats colonnaires (Parquet/ORC) et réécrire les données optimisées dans S3. Configurez les crawlers avec les classifieurs appropriés (intégrés pour CSV/JSON/Parquet ou personnalisés avec grok/regex) et attribuez au crawler un rôle IAM disposant des autorisations s3:GetObject/s3:ListBucket et glue:catalog — l’absence de ces autorisations est une erreur opérationnelle courante.

Lors de la configuration des tâches et des crawlers Glue, utilisez ces modèles et options de la console/CLI :

• Créer un crawler :

undefined

et le démarrer avec

undefined

.

• Tâche Glue :

undefined

; activez les signets de tâche (job bookmarks) pour éviter le retraitement. Critères de décision pour Glue par rapport aux alternatives :

• Utilisez Glue lorsque vous souhaitez un ETL Spark géré, la découverte de schémas et l’intégration du catalogue avec Athena/Redshift Spectrum.
• Utilisez EMR lorsque vous avez besoin d’un réglage de cluster spécialisé, de bibliothèques personnalisées ou de clusters à longue durée de vie.
• Utilisez une simple fonction Lambda ou Glue à la demande pour des transformations légères sur de petits fichiers.

Ingestion en streaming avec Kinesis Data Streams et Firehose

Kinesis Data Streams (KDS) est destiné à l’ingestion en temps réel avec rejouabilité, contrôle des consommateurs et mise à l’échelle fine. Un shard Kinesis fournit une capacité d’écriture de 1 Mo/s ou 1 000 enregistrements/s et une capacité de lecture de 2 Mo/s ; utilisez

undefined

et insérez des données avec

undefined

. Les clés de partition déterminent l’affectation des shards ; une faible cardinalité des clés de partition provoque des shards saturés (hot shards) — évitez cela en augmentant l’entropie de la clé ou en la suffixant avec un hachage. Mettez à l’échelle les shards en utilisant

undefined

ou activez le mode On-Demand pour une mise à l’échelle automatique.

Firehose est un service de flux de livraison optimisé pour la livraison en quasi-temps réel (vers S3, Redshift, OpenSearch, Splunk) avec mise en mémoire tampon (buffering), compression et transformation Lambda optionnelle intégrées. Configurez la mise en mémoire tampon avec BufferingHints : buffer_size (Mo) et buffer_interval (secondes) pour ajuster la latence de livraison par rapport au coût ; activez la compression (GZIP, Snappy) et définissez une fonction Lambda de traitement pour les transformations au niveau de l’enregistrement. Différences clés :

• Kinesis Data Streams :
  • Temps réel, prend en charge plusieurs consommateurs, rejouabilité des données conservées, gestion explicite des shards
  • Débit par shard (1 Mo/1k écritures), nécessite de concevoir les clés de partition
• Kinesis Data Firehose :
  • Livraison gérée vers les destinations, tentatives/interruptions automatiques, pas de rejouabilité des enregistrements livrés
  • Prend en charge la mise en mémoire tampon (taille/temps), la compression, la transformation via Lambda, la préparation (staging) sur S3 pour les chargements Redshift

Choisissez KDS lorsque vous avez besoin de rejouabilité, d’un contrôle strict des consommateurs ou de plusieurs consommateurs en aval ; choisissez Firehose lorsque vous avez besoin d’une livraison et d’une transformation simples vers S3/Redshift/OpenSearch avec une surcharge opérationnelle minimale.

Migration de bases de données et CDC avec DMS

AWS DMS est utilisé pour les migrations homogènes/hétérogènes et la réplication continue (CDC - Change Data Capture). Déployez une instance de réplication (

undefined

) dimensionnée pour le débit, les décisions de dimensionnement étant basées sur le taux de changement, le volume du chargement complet et le parallélisme des tâches. Types de tâches DMS :

• full-load (chargement complet) : copie uniquement les données existantes
• cdc (capture des données modifiées) : diffuse en continu les changements en cours
• full-load + cdc : chargement initial puis poursuite de la diffusion des changements Configurez les points de terminaison avec les paramètres de moteur appropriés (JDBC/chaîne de connexion), activez la journalisation supplémentaire ou les plugins sur la source, et fournissez un mappage de tables JSON pour filtrer/inclure des tables. Pour les sources basées sur MySQL, le CDC de DMS nécessite que la journalisation binaire (binlog) soit activée et un binlog_format approprié (ROW est recommandé) sur la source ; pour PostgreSQL, vous devez activer la réplication logique et un plugin comme wal2json ou utiliser des slots de réplication. Surveillez les tâches via les métriques CloudWatch et les journaux de tâches ; ajustez batchApplyEnabled et maxFullLoadSubTasks pour le débit.

Critères de décision entre le chargement complet et le CDC : utilisez full-load+CDC lorsque vous avez besoin d’une migration avec un temps d’arrêt minimal ; utilisez CDC seul pour une réplication continue après qu’un chargement initial a été effectué par un autre mécanisme. Validez toujours le mappage de schéma et effectuez des migrations de test sur des volumes de données représentatifs.

Modèles d’ingestion basés sur les API et les événements

Les API et les événements sont utilisés pour l’ingestion et l’orchestration de type push. Modèles courants :

• API Gateway -> Lambda -> Firehose/Kinesis : adapté lorsque les clients envoient des événements JSON. Utilisez la limitation de débit (throttling) d’API Gateway et les contrôles de simultanéité de Lambda pour fournir une contre-pression et appliquer les en-têtes d’idempotence.
• Notifications d’événements S3 : configurez les notifications de bucket pour envoyer des événements de création d’objet à Lambda, SQS ou SNS via la console ou aws s3api put-bucket-notification-configuration ; utilisez des filtres de préfixe/suffixe pour limiter les déclencheurs. Pour le fan-out, routez S3 -> topic SNS -> plusieurs files d’attente SQS/abonnés Lambda pour livrer le même événement à plusieurs consommateurs sans couplage.
• SQS et SNS pour une ingestion durable et découplée : SQS pour le traitement par des workers en mode pull avec un délai de visibilité, SNS pour le fan-out en mode push.

Considérations opérationnelles et modèles CLI :

• Utilisez des DLQ pour les échecs Lambda/SQS ; configurez une politique de nouvelles tentatives sur les abonnements SNS.
• Pour le streaming à haut débit depuis des API, préférez le traitement par lots dans Kinesis ou Firehose plutôt que des écritures synchrones en aval pour éviter de bloquer les clients API.

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

• Confondre Kinesis Data Streams (capable de relecture, géré par partition) avec Firehose (livraison gérée, sans relecture) : choisissez KDS lorsque vous avez besoin de relecture ou de plusieurs consommateurs ; choisissez Firehose pour des pipelines de livraison simples.
• Oublier les permissions IAM du crawler Glue : attachez toujours un rôle IAM qui accorde s3:GetObject/s3:ListBucket et glue:CreateTable/UpdateTable/DeleteTable pour que les crawlers puissent peupler le Data Catalog.
• Manque de journalisation binaire/réplication logique pour DMS CDC : activez binlog sur MySQL (format ROW) ou la réplication logique et wal2json sur PostgreSQL avant de démarrer les tâches CDC.
• Faible cardinalité de la clé de partition provoquant des partitions (shards) surchargées : augmentez la cardinalité de la clé de partition via le hachage, incluez des attributs à haute cardinalité ou augmentez le nombre de partitions ; surveillez les métriques de limitation de débit Put/Get.
• Mise en mémoire tampon excessive de Firehose ou mise en mémoire tampon mal configurée entraînant une latence élevée : ajustez buffer_size et buffer_interval en fonction de la latence acceptable et du volume de requêtes.
• Se fier aux notifications d’événements S3 sans DLQ ni nouvelle tentative : utilisez le fan-out SNS/SQS ou Lambda avec une DLQ pour éviter les événements manqués et assurer un fan-out durable.

Problème pratique : Scénario d’utilisation

RetailCo collecte des flux de clics mobiles (temps réel à haut volume) et des fichiers de catalogue de produits nocturnes ; ils ont besoin de tableaux de bord en temps réel et d’un lac d’analytique consolidé.

1. Ingérer les flux de clics dans Kinesis Data Streams avec des clés de partition dérivées de la session utilisateur + un suffixe de partition (shard) haché ; créer des consommateurs utilisant Kinesis Data Analytics ou Lambda/Kinesis Client Library pour le traitement en temps réel.
2. Utiliser Kinesis Data Firehose avec une Lambda de transformation pour persister les sorties de streaming enrichies vers S3 (Parquet), compresser avec Snappy, et éventuellement charger dans Redshift Spectrum pour l’analytique.
3. Placer les fichiers de catalogue nocturnes dans s3://raw/ et exécuter un crawler Glue planifié pour mettre à jour le Glue Data Catalog, puis exécuter des tâches Glue ETL pour convertir en Parquet partitionné dans la zone organisée (curated).
4. Utiliser les notifications d’événements S3 -> SNS -> Lambda pour déclencher des mises à jour de métadonnées légères ou invalider les caches ; router la livraison vers SQS pour un traitement durable en aval.
5. Surveiller les métriques de partition (shard) Kinesis (IncomingBytes, IncomingRecords, PutRecords.Success) et utiliser UpdateShardCount ou les flux On-Demand pour gérer la croissance ; activer les alarmes CloudWatch.

Justification des bonnes pratiques AWS : séparer les chemins temps réel et batch, utiliser Kinesis Data Streams lorsque la relecture et l’isolation des consommateurs sont requises, utiliser Firehose pour la livraison gérée vers S3/destinations, et maintenir un Glue Data Catalog pour l’intégration pour la découverte et les requêtes avec Athena/Redshift.

Tous les domaines · Stockage des données et architecture de lac de données →

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

Parcourir Amazon →