Amazon DEA-C01: Qualité, validation et observabilité 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 pratiques de bout en bout et les services AWS utilisés pour garantir l’exactitude des données, détecter les anomalies et maintenir la fiabilité des pipelines. Une validation et une observabilité solides réduisent les défauts en aval, permettent de respecter les SLA et autorisent un retraitement sécurisé. Les ingénieurs de données doivent combiner Glue Data Quality, des frameworks de validation, la détection d’anomalies CloudWatch, les DLQ et une conception idempotente pour construire des pipelines robustes.

Règles et évaluation d’AWS Glue Data Quality

Glue Data Quality utilise des ensembles de règles (rulesets) en Data Quality Definition Language (DQDL) pour définir des assertions sur les jeux de données (nombre de lignes, seuils de valeurs nulles, unicité, vérifications SQL personnalisées). Créez des ensembles de règles dans la console ou avec la CLI (exemple de commande : aws glue create-data-quality-ruleset --name MyRuleset --rules file://dqdl.json). Les ensembles de règles peuvent être attachés à des tâches ETL Glue ou exécutés indépendamment via les API StartDataQualityRuleRecommendationRun / StartDataQualityRulesetEvaluationRun pour évaluer des jeux de données stockés dans S3, des tables du catalogue ou des Glue DynamicFrames.

Détails de configuration clés et critères de décision :

Structure DQDL : les règles incluent ruleName, expression (DQDL ou SQL), severity et action on failure. Définissez explicitement l’action en cas d’échec sur FAIL pour la tâche lorsque des vérifications critiques échouent ; sinon, Glue peut consigner les résultats sans faire échouer l’exécution.
Contexte d’évaluation : fournissez des références de table ou de chemin S3 et des options d’échantillonnage (analyse complète ou échantillon) via les paramètres de la tâche ou les entrées de l’exécution d’évaluation pour équilibrer le coût et la couverture.
Sortie : l’évaluation des règles écrit les résultats dans les métriques Glue et sur Amazon S3 au format JSON ; utilisez ces artefacts pour l’audit et la remédiation automatisée.

Quand utiliser Glue Data Quality par rapport aux frameworks externes :

Utilisez Glue DQDL pour les règles standard de schéma, de complétude et d’unicité simple qui s’intègrent nativement dans les tâches et le lignage (lineage) Glue.
Utilisez Great Expectations (voir le sous-domaine suivant) lorsque vous avez besoin de bibliothèques d’attentes (expectations) plus riches, de vérifications plus expressives ou de suites d’attentes partagées entre plusieurs systèmes.

Patrons de validation des données dans les pipelines

La validation intervient à plusieurs points de contact : entrée (ingress), transformation et destination (sink). Patrons courants :

Vérifications légères avant ingestion dans les producteurs Lambda/Kinesis pour le schéma et les plages de valeurs de base afin de rejeter ou de router les lignes incorrectes avant le pipeline.
Validation côté serveur dans les tâches ETL Glue (Spark) à l’aide d’ensembles de règles DQDL et de validations explicites dans le code. Dans Glue Studio, ajoutez une transformation Data Quality qui référence un ensemble de règles ; en CLI, passez `

undefined

` ou incluez des paramètres de tâche pour déclencher les exécutions d’évaluation.

Validation post-transformation avec Great Expectations intégré dans les tâches Glue Python Shell ou Glue Spark. Déployez les attentes (expectations) sur S3 (répertoire expectations/) et chargez le DataContext dans la tâche : DataContext(root_dir="/tmp/ge") après avoir synchronisé les attentes S3 avec l’environnement de la tâche.

Comparaison des options de validation :

Glue DQDL
- Avantages : intégration native, faible surcharge opérationnelle, écrit les résultats dans le catalogue/métriques Glue
- Inconvénients : moins expressif pour les attentes logiques complexes
Great Expectations
- Avantages : attentes (expectations) riches, data docs, checkpoints intégrés, backends extensibles
- Inconvénients : nécessite l’empaquetage et la gestion des artefacts d’attentes dans S3 et l’orchestration dans les tâches Glue
Vérifications manuelles dans le code (Spark/DataFrame)
- Avantages : flexibilité totale, haute performance pour la logique personnalisée
- Inconvénients : maintenance plus élevée, pas de rapports standardisés sans travail supplémentaire

Pour le streaming, validez les enregistrements en transit et, en cas d’échec, poussez-les vers une DLQ SQS (configurez la RedrivePolicy avec maxReceiveCount via la CLI AWS ou la console) plutôt que de les supprimer. Pour le traitement par lots (batch), générez un artefact de rapport de validation et faites échouer ou mettez en quarantaine les sorties en fonction de la politique définie.

Détection d’anomalies et surveillance de la dérive des données

Utilisez la détection d’anomalies CloudWatch pour les métriques opérationnelles (enregistrements traités, taux d’erreur, durée de la tâche). Créez un détecteur avec la CLI : aws cloudwatch put-anomaly-detector --namespace "Glue" --metric-name "JobRunTime" --statistic "Average" --single-metric-anomaly-detector '{"MetricName":"JobRunTime","Namespace":"Glue","Stat":"Average","Dimensions":[...]}', puis créez des alarmes CloudWatch qui référencent la bande de détection d’anomalies. Pour la dérive au niveau des données (changements de distribution, variations du taux de valeurs nulles), planifiez des tâches de profilage (profile jobs) Glue DataBrew (aws databrew create-profile-job) pour calculer des statistiques, des histogrammes et des quantiles ; stockez les profils dans S3 comme lignes de base (baselines).

Critères de décision pour les alarmes d’anomalie par rapport aux alarmes à seuil :

Choisissez la détection d’anomalies CloudWatch lorsque les modèles de métriques sont saisonniers ou variables ; elle apprend du comportement passé et réduit l’ajustement manuel des seuils.
Utilisez des alarmes à seuil statique pour des conditions binaires (par ex., tâche bloquée > X heures) où la prévisibilité est élevée.

Pour la détection automatisée de la dérive :

Planifiez des tâches de profilage DataBrew régulières (quotidiennes/hebdomadaires selon la vélocité des données) pour capturer les lignes de base des métriques (% de valeurs nulles, cardinalité, percentiles).
Comparez les nouvelles sorties de profil aux profils de référence avec soit des ensembles de règles Glue (vérifications SQL personnalisées), soit des attentes personnalisées Great Expectations qui référencent les statistiques de la ligne de base.
Alertez via SNS / EventBridge lorsque la dérive dépasse les seuils de la politique ou lorsque les détecteurs d’anomalies signalent un comportement inhabituel des métriques.

Gestion des SLA et fiabilité des pipelines

La gestion des SLA associe l’observabilité à la remédiation et à l’ingénierie de la fiabilité. Instrumentez chaque pipeline avec ces métriques de base : débit (enregistrements/sec), latence (ingestion→destination), taux d’erreur, durée du job/d’exécution et décomptes en aval. Utilisez CloudWatch Metrics pour les jobs Glue (métriques d’exécution de job), le décalage des consommateurs Kinesis/Kafka et les métriques d’application personnalisées via PutMetricData.

Patrons de fiabilité et détails de configuration :

Files d’attente de lettres mortes (DLQ SQS) : pour les consommateurs de streaming (Lambda, consommateurs Kinesis), configurez une DLQ et définissez une RedrivePolicy(maxReceiveCount). Utilisez la rétention de la DLQ et un job de traitement distinct pour inspecter et retraiter les messages de la DLQ.
Conception idempotente : assurez-vous que les destinations (sinks) prennent en charge les écritures idempotentes — exemples :
- DynamoDB : utilisez PutItem avec des expressions conditionnelles ou une clé composite comme jeton d’idempotence.
- S3 : écrivez avec des patrons de renommage atomique ou utilisez des clés basées sur le contenu (hachage de l’enregistrement) afin que les relectures écrasent au lieu de dupliquer.
- Redshift/Glue ETL : utilisez une zone de transit (staging) + MERGE par clé pour dédupliquer après le retraitement.
Checkpointing : activez les checkpoints du connecteur Kinesis/DynamoDB et gérez la fréquence des checkpoints du consommateur pour équilibrer la fenêtre de retraitement et le risque de duplication.

Critères de décision pour la nouvelle tentative (retry) vs l’échec rapide (fail-fast) :

Pour les échecs transitoires (limitation de débit en aval), implémentez des nouvelles tentatives avec un backoff exponentiel et une DLQ uniquement après le nombre maximal de tentatives.
Pour les échecs de qualité des données (non-concordance de schéma), échouez rapidement et écrivez les enregistrements incriminés dans un préfixe S3 de quarantaine avec des métadonnées pour une revue manuelle.

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

Les règles Glue Data Quality consignent les échecs mais ne font pas échouer le job par défaut — configurez l’action de la règle sur FAIL pour les vérifications critiques et attachez l’évaluation de l’ensemble de règles à l’exécution du job.
Les pipelines de streaming sans DLQ rejettent ou perdent les enregistrements en échec — configurez toujours des DLQ SQS (ou une zone de transit S3 persistante) et une politique de redrive pour inspecter et retraiter.
Le retraitement sans idempotence produit des enregistrements en double — concevez des clés déterministes, utilisez une sémantique upsert/merge au niveau de la destination (sink), ou appliquez des clés d’objet basées sur le contenu pour S3.
La détection de dérive des données (data drift) sans lignes de base produit des alertes bruyantes — planifiez des jobs de profilage Glue DataBrew pour créer et stocker des statistiques de référence, puis comparez les nouveaux profils à celles-ci.
Une dépendance excessive aux seuils statiques de CloudWatch provoque des faux positifs — utilisez la détection d’anomalies CloudWatch pour les métriques saisonnières/variables et réservez les seuils statiques pour les limites non négociables.
Définir un maxReceiveCount trop élevé diffère le routage vers la DLQ et augmente la latence de traitement — choisissez un maxReceiveCount raisonnable pour que les DLQ reçoivent les messages en échec persistant en temps opportun.

Problème pratique : Scénario d’utilisation

Streamline Retail est confronté à de fréquentes erreurs de reporting en aval après l’ETL nocturne : pics de schéma occasionnels, violations de règles silencieuses et commandes en double lors du retraitement des exécutions échouées.

Implémentez des règles Glue Data Quality (DQDL) pour le schéma, les seuils de valeurs nulles et l’unicité sur order_id ; définissez l’action en cas d’échec sur FAIL pour le job et publiez les artefacts d’évaluation sur S3.
Ajoutez Great Expectations dans une étape Glue Python Shell pour des vérifications métier complexes (cohérence des commandes entre les tables) ; stockez les attentes (expectations) dans S3 et exécutez des checkpoints dans le pipeline.
Planifiez des jobs de profilage DataBrew pour capturer des lignes de base quotidiennes (cardinalité, taux de valeurs nulles, percentiles) et utilisez des comparaisons automatisées pour détecter la dérive.
Pour les événements de commande en streaming, configurez une DLQ SQS avec une RedrivePolicy appropriée et créez un job de relecture pour traiter les messages de la DLQ de manière idempotente (en utilisant order_id comme clé de déduplication).
Instrumentez les détecteurs d’anomalies CloudWatch pour la durée d’exécution du job et le nombre d’erreurs ; attachez des alarmes basées sur les anomalies à SNS pour l’escalade à l’équipe d’astreinte.

Justification de la bonne pratique AWS : combinez les contrôles de qualité natifs de Glue pour une intégration rapide, Great Expectations pour l’expressivité, DataBrew pour les statistiques de référence et les détecteurs d’anomalies CloudWatch pour une surveillance adaptative. Les DLQ et les destinations (sinks) idempotentes bouclent la boucle pour des nouvelles tentatives et un retraitement sécurisés tout en préservant les SLA.

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

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