Amazon DEA-C01: Requêtage et analyse 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 la conception, l’optimisation et l’exploitation des services AWS qui prennent en charge les requêtes analytiques et la BI sur de grands ensembles de données. Il se concentre sur les modèles de requêtes rentables et à haute performance sur Athena, Redshift, OpenSearch et QuickSight, et sur la manière dont ils interagissent avec S3, Glue et les bases de données transactionnelles. La maîtrise exige d’équilibrer le format de stockage, le partitionnement, le type de calcul et l’emplacement des données afin de minimiser les octets analysés et l’asymétrie réseau (network skew) tout en fournissant des informations à faible latence.

Optimisation des requêtes Amazon Athena

La tarification d’Athena est basée sur les octets analysés, donc la disposition physique des données et les métadonnées sont les principaux leviers. Utilisez des formats colonnaires (Parquet ou ORC) avec compression (Snappy pour Parquet, options Zlib/ORC) pour réduire la taille et l’utilisation du CPU. Partitionnez les données par colonnes à haute cardinalité filtrées dans les requêtes (date, région) et enregistrez les partitions dans le Glue Data Catalog. Modèles typiques :

Écrire les données sur S3 dans des chemins comme s3://bucket/events/date=2026-08-02/ et utiliser des crawlers Glue ou MSCK REPAIR TABLE pour peupler les partitions.

undefined

pour imposer la compression colonnaire.

Utilisez la projection et l’élagage de partitions (partition pruning) via des clauses WHERE qui référencent les clés de partition pour éviter d’analyser les partitions inutiles.

Lorsque les requêtes nécessitent des jointures avec des bases de données transactionnelles, utilisez Athena Federated Query (connecteurs Lambda) pour effectuer des jointures inter-sources avec RDS, DynamoDB ou Redshift. Les connecteurs sont déployés en tant que fonctions Lambda et enregistrés comme sources de données dans Athena ; exemple de flux dans la console : Athena > Sources de données > Connecteurs > Nouveau. Critères de décision :

Utilisez Federated Query lorsque les volumes de données dans RDS/DynamoDB sont modestes ou pour joindre une petite table de dimension à un grand ensemble de données S3.
Pour les jointures lourdes et répétées, extrayez et matérialisez les données opérationnelles dans S3 (Parquet) pour déplacer le coût de la jointure vers un seul ETL et utilisez Athena pour les lectures répétées.

Optimisation des requêtes et distribution Amazon Redshift

La performance de Redshift dépend du style de distribution (distribution style) et des clés de tri (sort keys) pour minimiser les déplacements de données et permettre le mappage de zones (zone mapping). Choisissez les styles DIST en utilisant ces points de décision :

DISTKEY (KEY) : utile pour joindre de grandes tables sur une clé de jointure à haute cardinalité ; évite la redistribution si les deux tables partagent le même DISTKEY.
ALL : répliquer une petite table de dimension sur tous les nœuds pour éviter les brassages réseau (network shuffles) lors des jointures.
EVEN : style par défaut pour les charges de travail imprévisibles ou lorsqu’aucune bonne clé n’existe ; évite les points chauds (hotspots).
AUTO : laisser Redshift choisir en fonction de la taille de la table et de la charge de travail si vous manquez d’indications claires.

Définissez des SORTKEYs sur les colonnes utilisées dans les filtres de plage ou les clauses ORDER BY pour activer les zone maps et réduire les lectures sur disque. Commandes opérationnelles courantes :

undefined

;

Utilisez VACUUM et ANALYZE périodiquement :

undefined

; surveillez SVV_TABLE_INFO et STL_QUERY pour les métriques d’asymétrie (skew) et de distribution. Redshift Spectrum vous permet d’interroger des tables externes S3 via le Glue Data Catalog. Créez le schéma externe avec :

undefined

; Critères de décision pour Spectrum par rapport à Redshift natif :

Utilisez Spectrum pour les données froides, volumineuses et rarement interrogées stockées dans S3 ou pour les architectures de données à plusieurs niveaux.
Conservez les ensembles de données chauds et fréquemment joints à l’intérieur de Redshift pour la performance ; lors de la jointure avec Spectrum, choisissez des DISTKEYs pour colocaliser les clés de jointure ou utilisez la redistribution pour minimiser les E/S réseau.

Amazon OpenSearch Service pour l’analyse de logs

OpenSearch est optimisé pour l’ingestion et l’analyse rapide et ad-hoc de logs ; sa configuration d’index et de cluster détermine le débit et le coût. Conception et cycle de vie des index :

Utilisez des modèles d’index comme logs-YYYY.MM.DD et un template d’index pour définir index.number_of_shards (petits index : 1 fragment (shard) ; grands index : plusieurs fragments d’environ 10 à 50 Go) et index.number_of_replicas pour la disponibilité.
Configurez des politiques de cycle de vie d’index (ILM) pour faire passer les index par les niveaux hot, warm, cold et UltraWarm pour le contrôle des coûts ; UltraWarm réduit les coûts de stockage des nœuds hot pour les données historiques. Le partitionnement en fragments (sharding) et les réplicas affectent les performances de requête et d’indexation :
Plus de fragments (shards) augmentent le parallélisme mais ajoutent une surcharge ; ajustez le nombre de fragments par nœud en fonction de la mémoire (heap) et du CPU.
Les réplicas améliorent le débit de lecture et la tolérance aux pannes ; définissez le nombre de réplicas en fonction de la simultanéité des requêtes et du SLA. Commandes opérationnelles et modèles de console :
Utilisez les Dev Tools d’OpenSearch (ou curl) pour appliquer (PUT) les templates d’index et les politiques ILM, et surveillez avec les API de santé du cluster. Allouez des attributs de nœud et utilisez la reconnaissance de l’allocation des fragments (shard allocation awareness) pour éviter les points chauds (hot-spotting). Critères de décision :
Choisissez UltraWarm lorsque les exigences de latence des requêtes sur les logs historiques peuvent tolérer une latence de lecture plus élevée en échange d’un coût de stockage inférieur.
Conservez les index récents sur les nœuds hot pour prendre en charge les agrégations et les tableaux de bord rapides.

QuickSight pour la BI et la visualisation

QuickSight fournit des tableaux de bord rapides avec deux modes d’ingestion principaux : SPICE (en mémoire) et la requête directe (direct query). SPICE offre des performances inférieures à la seconde pour les tableaux de bord et est adapté aux lectures répétées ; les requêtes SQL directes (vers Athena, Redshift, RDS) sont préférables pour les très grands ensembles de données ou les données qui changent fréquemment. Configuration clé et meilleures pratiques :

Créez des ensembles de données dans la console : Nouvel ensemble de données > Choisir la source (Athena/Redshift/RDS/OpenSearch) > Importer dans SPICE ou Utiliser une requête directe.
Utilisez des actualisations SPICE planifiées pour les besoins quotidiens/quasi temps réel ; configurez l’actualisation incrémentielle par partitionnement temporel pour limiter le mouvement des données. Sécurité et gouvernance :
Mettez en œuvre la sécurité au niveau des lignes (row-level security) via des mappages utilisateur/groupe QuickSight et des règles sur l’ensemble de données.
Pour l’accès aux données inter-comptes, déployez un rôle IAM et des autorisations basées sur les ressources que QuickSight peut assumer. Critères de décision :
Utilisez SPICE pour les tableaux de bord avec de nombreux utilisateurs simultanés et des fenêtres d’actualisation prévisibles.
Utilisez la requête directe lorsque la fraîcheur des données est critique ou que les capacités de SPICE sont limitées ; combinez-la avec des champs calculés et des paramètres pour une expérience utilisateur interactive.

← Orchestration des données et gestion des flux de travail · Tous les domaines · Sécurité →

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