Amazon DEA-C01: Surveillance et dépannage des pipelines de 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.

La surveillance et le dépannage des pipelines de données sont essentiels pour garantir une livraison ponctuelle et précise des données en streaming et par lots sur AWS. Ce domaine couvre les techniques de télémétrie, d’alerte et de diagnostic pour des services comme Kinesis, Firehose, Glue, DMS, Lambda, ainsi que les pistes d’audit AWS qui soutiennent les enquêtes sur les incidents. Une surveillance efficace réduit le temps moyen de détection/rétablissement (MTTD/MTTR) en exposant le retard des consommateurs, la pression sur les ressources des tâches, la latence de livraison et les accès non autorisés. Les sections suivantes présentent des signaux concrets, des modèles d’utilisation de la CLI/console et des critères de décision pour exploiter et remédier aux flux de données en production.

Métriques et alarmes CloudWatch pour les services de données

CloudWatch est le plan de télémétrie principal : créez des filtres de métriques, des tableaux de bord et des alarmes pour les métriques clés des services, et intégrez les alarmes avec SNS, EventBridge ou Systems Manager pour une remédiation automatisée. Utilisez

undefined

pour créer des alarmes par programmation ; les indicateurs typiques incluent --metric-name, --namespace, --statistic (ou --extended-stat), --threshold, --evaluation-periods et --comparison-operator. Pour les tableaux de bord, envoyez des métriques personnalisées (par exemple, à partir des métadonnées d’une tâche Glue) en utilisant

undefined

avec un espace de noms comme « MaSociete/PipelineDeDonnees ».

Concentrez-vous sur ces métriques et modèles exploitables :

• Glue : surveillez BytesRead, BytesWritten, RecordsProcessed et DPUHrs pour détecter les changements de volume de données, l’asymétrie (skew) et les coûts. Alarmes : chute soudaine de RecordsProcessed ou pics de DPUHrs par enregistrement.
• Kinesis : surveillez GetRecords.IteratorAgeMilliseconds pour le retard du consommateur (consumer lag) et IncomingBytes/IncomingRecords pour la pression sur la source.
• Firehose : surveillez DeliveryToS3.DataFreshness et DeliveryToS3.Records pour repérer la latence de livraison et la perte de données.
• DMS : surveillez FullLoadRows, CDCLatencyMilliseconds et AppliedChanges pour la santé de la réplication.

Critères de décision pour les alertes :

• Utilisez des alarmes composites (CloudWatch composite alarms) pour réduire le bruit : combinez IteratorAgeMilliseconds > X pour 3 points de données ET le taux d’erreur du consommateur > Y.
• Pour la sélection des seuils, dérivez des lignes de base à partir de 7 à 14 jours de données historiques et définissez des seuils dynamiques utilisant des modèles de détection d’anomalies (PutAnomalyDetector) lorsque les charges de travail sont saisonnières.

Surveillance et gestion des erreurs des tâches Glue

Glue émet des métriques vers CloudWatch et écrit des journaux dans

undefined

(journaux d’exécution de la tâche) et

undefined

(erreurs). Utilisez CloudWatch Logs Insights pour interroger les exécutions de tâches : lancez des requêtes via la console ou

undefined

avec une chaîne de requête telle que

undefined

. Suivez BytesRead, BytesWritten, RecordsProcessed et DPUHrs à partir des métriques d’exécution de la tâche Glue — DPUHrs est directement corrélé au coût et au parallélisme de la tâche.

Modes de défaillance courants de Glue et remédiation :

• Manque de mémoire (OutOfMemory - OOM) ou perte d’exécuteur : augmentez le type de worker/le nombre de DPU, passez au type de worker G.2X pour une consommation mémoire plus importante, ou optimisez le partitionnement Spark (repartition/coalesce) et utilisez des prédicats poussés (pushdown predicates) pour réduire le volume d’entrée.
• Asymétrie des données (data skew) provoquant des tâches à la traîne (stragglers) : utilisez des clés de partition pour rééquilibrer, augmentez le parallélisme, ou utilisez les choix de split/resolve du DynamicFrame de Glue le cas échéant.
• Blocage de la tâche ou démarrage long : activez les signets de tâche (job bookmarks) et surveillez les JobMetrics de Glue pour « TimeWaitingForResources » afin d’identifier les conflits de capacité.

Compromis décisionnels :

• Augmentez les DPU lorsque le CPU/la mémoire sont le goulot d’étranglement et que la prévisibilité du temps d’exécution est importante ; préférez les optimisations de code (partitionnement, mise en cache uniquement lorsque nécessaire) si les coûts doivent être maîtrisés.
• Utilisez Glue en streaming pour des transformations en quasi-temps réel ; utilisez Glue ETL en mode batch pour des transformations Spark complexes et des charges de travail plus importantes compatibles avec les instances Spot.

Surveillance de Kinesis et Firehose

Retard des consommateurs Kinesis : fiez-vous à GetRecords.IteratorAgeMilliseconds pour détecter le retard des consommateurs. Si GetRecords.IteratorAgeMilliseconds est constamment élevé :

• Mettez à l’échelle en augmentant le nombre de partitions (reshard/scale), ou
• Améliorez les performances des consommateurs par le traitement par lots, en utilisant la diffusion améliorée (enhanced fan-out) (pour un débit par consommateur jusqu’à 2 Mo/sec) ou la Kinesis Client Library (KCL) v2 avec un checkpointing amélioré.

Utilisez

undefined

pour inspecter le nombre de partitions et

undefined

pour IteratorAgeMilliseconds. Lors de la comparaison des options de remédiation, considérez :

• Ajout de partitions : augmente le débit d’ingestion et de lecture ; nécessite un repartitionnement et un rééquilibrage.
• Diffusion améliorée (enhanced fan-out) : évite le partage du débit de lecture mais augmente le coût par consommateur.
• Optimisation du consommateur : réduit le besoin de partitions supplémentaires et le coût, mais nécessite un effort d’ingénierie.

Métriques de livraison Firehose : DeliveryToS3.DataFreshness quantifie la latence de livraison ; les paramètres de mise en mémoire tampon (buffering) typiques sont de 60 à 900 secondes et retiendront les enregistrements jusqu’à ce que bufferSize ou bufferInterval soit atteint. Si DeliveryToS3.DataFreshness est élevé :

• Vérifiez les indications de mise en mémoire tampon (buffer hints) de Firehose (BufferIntervalInSeconds, BufferSizeInMBs) dans la console ou via

undefined

.

• Inspectez les erreurs CloudWatch (DeliveryToS3.RecordsFailed) et les autorisations du compartiment S3 (erreurs KMS s’il est chiffré).

Gardez à l’esprit la sémantique de mise en mémoire tampon de Firehose : le service retarde intentionnellement les données jusqu’à l’intervalle de tampon ; réduisez l’intervalle de tampon pour diminuer la latence, au prix d’écritures plus fréquentes sur S3.

← Sécurité · Tous les domaines · Optimisation des coûts pour les charges de travail de données →

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

Parcourir Amazon →