Amazon DEA-C01: Catalogage des données et gestion des métadonné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 la couche de métadonnées qui rend les données découvrables, interrogeables et gouvernables sur une plateforme de données AWS. Un catalogage et une gestion des métadonnées efficaces réduisent les frictions pour l’analytique et garantissent que les consommateurs en aval peuvent trouver les schémas, les partitions, les politiques d’accès et la lignée des données. Les services AWS dans ce domaine — Glue Data Catalog, Glue Schema Registry, Lake Formation, l’intégration Athena et DataBrew — fournissent des outils complémentaires pour la découverte, l’évolution des schémas, la gouvernance et le profilage. Comprendre comment ces services interagissent, leurs détails de configuration et les modes de défaillance typiques est essentiel pour la fiabilité opérationnelle et la sécurité.

Structure et opérations d’AWS Glue Data Catalog

Le Glue Data Catalog est le référentiel de métadonnées centralisé et régional pour les bases de données, les tables, les partitions, les connexions et les classifieurs définis par l’utilisateur. Les primitives de base sont :

• Database : un conteneur logique (utiliser l’AWS CLI :

undefined

).

• Table : décrit un jeu de données (serde, formats d’entrée/sortie, colonnes, tableType

undefined

). Vous pouvez créer/mettre à jour via la console, l’API Glue ou CloudFormation ; par ex.,

undefined

.

• Partition : une correspondance entre les valeurs de clés de partition et les préfixes S3 ; les partitions peuvent être gérées par les crawlers Glue (

undefined

) ou ajoutées explicitement (

undefined

).

Modèles opérationnels :

• Crawlers pour la découverte : planifiez des crawlers pour les arborescences S3 en évolution, choisissez l’ordre des classifieurs (CSV/JSON/Parquet) et définissez la politique du crawler pour les mises à jour incrémentielles.
• Contrôle programmatique : préférez les API Glue ou Lambda pour ajouter des partitions lorsque vous avez des arrivées de données sur S3 basées sur des événements, plutôt que de dépendre uniquement des crawlers.
• Réplication du catalogue : le Glue Data Catalog est régional. Pour les lectures multi-régions, envisagez d’exécuter des crawlers dans chaque région, de créer une automatisation pour répliquer les métadonnées, ou d’utiliser des modèles de liens entre ressources (resource-linking) ; les décisions de conception dépendent du coût, des besoins en cohérence et des modèles de requêtes inter-régions.

Critères de décision :

• Utilisez les crawlers lorsque la détection de schéma est nécessaire et que les formats de données sont hétérogènes ; utilisez la création explicite de tables pour les schémas stricts et pour les jeux de données prévisibles à fort volume.
• Utilisez batch-create-partition ou la gestion des partitions basée sur Lambda pour les arrivées fréquentes de petits fichiers afin d’éviter la latence des crawlers et de réduire les coûts de l’API Glue.

Découverte et évolution des schémas

Le Schema Registry et les schémas Glue prennent en charge Avro, JSON et Protobuf pour le streaming et les contrats producteur/consommateur à longue durée de vie. Fonctionnalités clés :

• Enregistrez les schémas via la console ou la CLI (

undefined

).

• Modes de compatibilité : BACKWARD (les consommateurs peuvent lire les nouvelles données), FORWARD (les nouveaux consommateurs peuvent lire les anciennes données), et FULL (les deux). Choisissez en fonction des modèles de déploiement des consommateurs.
• Application du schéma : pour le streaming, intégrez le registre avec Kinesis Data Streams, MSK, ou les clients Kafka et les SDK AWS pour sérialiser/désérialiser avec des versions de schéma intégrées et une validation.

Modèles pratiques de configuration et d’évolution :

• Pour Avro avec de nombreux consommateurs, utilisez la compatibilité BACKWARD pour permettre l’ajout de nouveaux champs avec des valeurs par défaut ; évitez les suppressions qui casseraient la compatibilité.
• Pour une évolution stricte des contrats entre les équipes, exigez la compatibilité FULL et contrôlez les changements de schéma via une étape de CI qui exécute une validation de schéma.
• Pour JSON où les champs sont optionnels et le schéma est fluide, utilisez l’évolution de schéma avec des valeurs par défaut permissives mais en versionnant les métadonnées dans le catalogue pour éviter une rupture silencieuse des consommateurs.

Critères de décision :

• Utilisez le Schema Registry pour les événements en streaming et lorsque plusieurs consommateurs ont besoin d’un schéma canonique. Utilisez les schémas de table Glue pour les jeux de données en batch où le format (Parquet/ORC) fournit le schéma à la lecture (schema on read).
• Choisissez le mode de compatibilité en évaluant si vous contrôlez tous les consommateurs (ce qui permet de coordonner un FORWARD) ou si vous avez besoin de changements additifs sûrs (choisissez BACKWARD).

Lignée des données et gouvernance avec Lake Formation

Lake Formation s’appuie sur le Glue Data Catalog pour fournir un contrôle d’accès affiné, un audit et des contrôles de la lignée des données. Fonctionnalités principales :

• LF-Tags : contrôles d’accès basés sur des balises (tags) appliqués aux bases de données, tables et colonnes. Créez des LF-Tags dans Lake Formation, assignez des paires clé:valeur, puis accordez des permissions aux principaux IAM via des autorisations basées sur les balises plutôt que sur les ressources.
• Contrôles au niveau des colonnes : utilisez les LF-Tags pour masquer ou restreindre des colonnes ; configurez les permissions au niveau des colonnes dans la console Lake Formation ou avec

undefined

.

• Lignée et audit : activez CloudTrail et les métriques des jobs Glue pour capturer la lignée des jobs ETL ; utilisez les signets de job Glue (job bookmarks) et les métadonnées des signets dans le catalogue pour suivre les données traitées.

Modèles de configuration :

• Définissez un ensemble restreint et cohérent de clés de LF-Tag (par ex., sensitivity:public/private/PII) et automatisez le balisage lors de la création de tables ou via les crawlers Glue en utilisant la configuration du crawler ou un code de post-traitement.
• Déléguez l’administration via les rôles d’administrateur délégué (Delegated Admin) de Lake Formation et accordez des permissions Lake Formation aux équipes d’analytique tout en restreignant l’accès S3 au niveau IAM.

Critères de décision :

• Utilisez Lake Formation lorsque vous avez besoin de contrôles centralisés, au niveau des colonnes et basés sur des balises pour de nombreux consommateurs, et lorsque la gouvernance/auditabilité est obligatoire.
• Si vos besoins en contrôle d’accès sont simples (au niveau du bucket), les politiques IAM+S3 peuvent suffire ; utilisez Lake Formation pour des contrôles fins et intégrés au catalogue.

Intégration d’Athena et du catalogue Glue

Athena s’appuie sur le Glue Data Catalog pour les métadonnées. Points d’intégration et leviers opérationnels courants :

• Gestion des partitions : Athena lit les partitions depuis le catalogue Glue. Lorsque de nouvelles partitions S3 sont ajoutées, vous devez mettre à jour le catalogue. Options :
  • Exécutez MSCK REPAIR TABLE db.table; depuis Athena ou utilisez aws athena start-query-execution avec cette commande SQL pour rafraîchir les partitions découvertes sous l’emplacement de la table.
  • Utilisez aws glue batch-create-partition pour ajouter des partitions par programmation sur les événements S3 PUT (recommandé pour les flux événementiels).
  • Utilisez la projection de partitions en définissant des propriétés de table comme projection.enabled=true, projection.year.type=integer, projection.month.range=1, et projection.year.range=2018,2026 — cela évite complètement les consultations de Glue et est essentiel pour un très grand nombre de partitions.
• Performance des requêtes et compromis en matière de coûts :
  • La projection de partitions supprime les appels d’API Glue et réduit considérablement la latence pour de nombreuses petites partitions, mais nécessite un nommage de partition déterministe.
  • MSCK REPAIR TABLE est simple pour les arrivées ponctuelles ad-hoc mais peut être lent pour les grands jeux de données.

Complément avec Glue DataBrew :

• Utilisez DataBrew pour le profilage et les transformations sans code ; pointez DataBrew vers des tables du catalogue Glue ou des chemins S3, exécutez des tâches de profilage, créez des recettes et publiez le résultat sur S3 ou en tant que nouvelles tables Glue.
• Utilisez DataBrew pour des contrôles de qualité exploratoires et pour générer des transformations en vue d’une mise en production ultérieure dans Glue ETL lorsque une logique Spark complexe est requise.

Critères de décision :

• Utilisez la projection de partitions lorsque les partitions sont nombreuses et suivent un schéma prévisible (basé sur la date / numérique).
• Utilisez les mises à jour programmatiques de partitions Glue pour une ingestion événementielle quasi en temps réel.
• Exécutez MSCK REPAIR TABLE uniquement pour des remplissages (backfills) occasionnels ou lorsque l’automatisation n’est pas disponible.

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

• Les requêtes Athena échouent car les partitions Glue ne sont pas mises à jour après les arrivées sur S3 : évitez de vous fier uniquement aux crawlers ; exécutez MSCK REPAIR TABLE pour des mises à jour occasionnelles, invoquez aws glue batch-create-partition sur les événements S3, ou implémentez la projection de partitions pour les grands ensembles de partitions prévisibles.
• Choisir le mauvais mode de compatibilité du registre de schémas casse les consommateurs : sélectionnez BACKWARD pour les changements additifs et la stabilité des consommateurs, FORWARD lorsque les producteurs doivent rester compatibles avec les anciens consommateurs, et FULL lorsque les deux directions doivent être sûres ; validez les changements en CI par rapport aux schémas des consommateurs.
• Supposer que le Glue Data Catalog est global : le catalogue est régional. Pour un accès inter-régions, concevez une réplication ou exécutez des catalogues dans les régions cibles ; ne supposez pas que les métadonnées Glue sont automatiquement disponibles entre les régions.
• Accorder un accès IAM à S3 mais pas les autorisations Lake Formation : Athena et Lake Formation appliquent des autorisations au niveau du catalogue ; accordez toujours les autorisations Lake Formation (et les LF-Tags lorsqu’ils sont utilisés) en plus de toute politique IAM.
• Granularité excessive des partitions : utiliser trop de petites partitions nuit à la planification des requêtes et à la surcharge de métadonnées ; préférez des partitions plus grossières (quotidiennes plutôt que par minute) ou utilisez la projection de partitions.
• Négliger les autorisations du rôle DataBrew : les tâches DataBrew nécessitent un rôle de service avec des autorisations Glue et S3 ; assurez-vous que le rôle dispose de Glue:GetTable, des droits de lecture/écriture S3, et de kms:Decrypt si les jeux de données sont chiffrés.

Problème pratique : Scénario de cas d’usage

Acme Retail reçoit des fichiers de ventes horaires sur S3 avec des partitions par date/heure et les analystes interrogent les données dans Athena ; après le chargement, les utilisateurs constatent des échecs de requêtes et des résultats obsolètes car les partitions ne sont pas visibles dans le Glue Data Catalog.

1. Implémentez une notification d’événement S3 PUT pour invoquer une fonction Lambda qui appelle aws glue batch-create-partition afin d’enregistrer immédiatement la nouvelle partition.
2. Pour les données plus anciennes ou les remplissages (backfills), planifiez une requête Athena qui exécute MSCK REPAIR TABLE db.sales_hourly; ou exécutez un aws glue batch-create-partition ciblé pour des plages connues.
3. Si les partitions suivent une convention de nommage stricte par date/heure, activez la projection de partitions sur la table Glue (définissez projection.enabled=true et définissez les propriétés year/month/day/hour) pour éliminer les coûts de rafraîchissement du catalogue.
4. Ajoutez des LF-Tags pour la sensibilité à la table et accordez aux analystes des autorisations Lake Formation afin que les requêtes Athena soient autorisées et gouvernées.
5. Utilisez Glue DataBrew pour profiler les nouveaux fichiers horaires dans un environnement de pré-production (staging) afin de détecter la dérive de schéma ; si des changements de schéma sont trouvés, enregistrez de nouvelles versions de schéma dans le Glue Schema Registry et validez la compatibilité avant le déploiement en production.

Justification : l’enregistrement automatique ou la projection des partitions supprime le décalage de métadonnées qui cause l’échec des requêtes Athena ; coupler cela avec la gouvernance Lake Formation assure un accès sécurisé, et le profilage piloté par DataBrew détecte tôt la dérive de schéma, tandis que le Glue Schema Registry protège les consommateurs de streaming et de batch contre les changements de schéma incompatibles.

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

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

Parcourir Amazon →