Amazon MLS-C01: Ingénierie des données et ingénierie des caractéristiques — Guide d'étude

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

Fait partie du AWS Machine Learning Specialty MLS-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.

Ingestion de données, stockage et formats de fichiers

La conception d’un lac de données (data lake) prêt pour le ML commence par le choix du bon modèle d’ingestion et du format de persistance. Pour la télémétrie en temps réel, utilisez Kinesis Data Streams (traitement à faible latence) ou Kinesis Data Firehose (livraison gérée). Firehose peut livrer directement dans Amazon S3 et effectuer une conversion de format d’enregistrement côté serveur vers Parquet/ORC lorsqu’il est combiné avec AWS Glue Schema Registry et une transformation Lambda ; choisissez Data Streams + Kinesis Data Analytics ou Lambda si vous avez besoin d’un enrichissement personnalisé ou de réponses en moins d’une seconde. Pour la migration en masse, utilisez AWS DataSync, Database Migration Service (DMS) pour les sources RDS/OLTP, ou Snowball pour les transferts hors ligne à l’échelle du téraoctet. Sur S3, stockez au format colonnaire Parquet pour les charges de travail analytiques (predicate pushdown, compression comme Snappy, clés de partitionnement ajustées aux modèles de requêtes) et TFRecord pour alimenter les pipelines TensorFlow pour des lectures séquentielles à haut débit. Méfiez-vous de l’explosion de petits fichiers : mettez en mémoire tampon les écritures (buffering Firehose, traitement par lots Glue) pour produire des objets S3 dimensionnés pour les frameworks big data (dizaines à centaines de Mo). L’évolution des schémas est courante : utilisez Glue Catalog et Schema Registry pour versionner les schémas ; utilisez le partitionnement et des conventions de nommage pour éviter les scans de table complets et coûteux. Un piège courant consiste à utiliser le mode Fichier (File mode) dans le traitement en aval, qui copie des jeux de données entiers sur les nœuds de calcul ; préférez le streaming (mode Pipe de SageMaker), Redshift Spectrum ou Athena à la copie intégrale lorsque les jeux de données contiennent des millions d’enregistrements.

ETL serverless et en cluster : Glue, EMR, Redshift et SageMaker

Les choix d’ETL dépendent de l’échelle, de la personnalisation, du profil de coût et des besoins en bibliothèques. AWS Glue fournit un ETL Spark sans serveur (serverless) avec catalogage, crawlers et orchestration de jobs intégrée — excellent pour les transformations fréquentes, pilotées par les événements, où vous souhaitez une mise à l’échelle gérée. EMR est préférable lorsque vous avez besoin d’écosystèmes Spark/Hadoop personnalisés, de clusters de longue durée ou de bibliothèques spécialisées (GraphX, builds personnalisés de MLlib) et que vous pouvez utiliser S3 comme lac de données sous-jacent. Pour l’analytique sans ingestion, utilisez Redshift Spectrum ou Athena pour requêter directement Parquet/ORC dans S3 ; Redshift est meilleur pour les jointures complexes et les charges de travail de BI. Pour la préparation des données de modèle, les jobs SageMaker Processing fournissent des conteneurs gérés pour exécuter un prétraitement Spark ou Python évolutif, garantissant que le code de prétraitement s’exécute à proximité de l’entraînement et peut être versionné avec le job d’entraînement. Lors du lancement d’un entraînement SageMaker avec des algorithmes intégrés, fournissez au minimum l’image d’entraînement, le rôle IAM, le type/nombre d’instances (instance_type/count) et l’URI S3 des données d’entraînement ; envisagez le mode Pipe pour streamer les enregistrements et éviter la copie sur EBS pour les jeux de données de plusieurs millions d’enregistrements. Pièges courants : choisir Glue pour des transformations à très faible latence (utilisez plutôt Lambda/Kinesis) ou copier inutilement des données S3 vers HDFS/EBS alors que Redshift Spectrum/Athena suffirait.

Ingénierie des caractéristiques, pipelines de transformation et sélection

L’ingénierie des caractéristiques (feature engineering) doit être reproductible et isolée des fuites de données (leakage). Implémentez le prétraitement sous forme de pipelines de qualité production (Pipeline scikit-learn, pipelines Spark ML, ou SageMaker Processing + Feature Store) afin que des transformations identiques s’appliquent à l’entraînement et à l’inférence. Gérez les valeurs manquantes (missingness) avec une sélection de stratégie : imputation simple (moyenne/médiane/mode) pour les petits manques ; méthodes basées sur un modèle (KNN, MICE itératif) lorsque d’autres caractéristiques prédisent les valeurs manquantes. Mettez à l’échelle les caractéristiques numériques avec StandardScaler ou MinMax pour les modèles basés sur le gradient ; appliquez une mise à l’échelle robuste (robust scaling) si les valeurs aberrantes (outliers) dominent. Pour les variables catégorielles, choisissez l’encodage one-hot (one-hot encoding) pour une faible cardinalité, l’encodage par la cible (target encoding) ou les plongements appris (learned embeddings) pour les catégories à haute cardinalité (utilisez des Embeddings dans les modèles profonds ou le hachage de caractéristiques (feature hashing) pour le contrôle de la dimensionnalité). Pour le texte, effectuez une normalisation cohérente (minuscules, ponctuation, tokenisation) ; utilisez Word2Vec/BlazingText pour les plongements (embeddings) ou des pipelines TF-IDF/sparse pour les modèles linéaires ; BlazingText dans SageMaker prend en charge skip-gram/CBoW et est efficace à grande échelle. Pour la sélection de caractéristiques, utilisez la régularisation L1, l’importance basée sur les arbres (XGBoost/RandomForest), l’information mutuelle ou l’élimination récursive de caractéristiques (recursive feature elimination), et effectuez toujours la sélection de caractéristiques à l’intérieur des plis de validation croisée (cross-validation folds) pour éviter le biais de sélection. Le plus grand piège pratique est la fuite de données (leakage) : ne dérivez jamais de caractéristiques en utilisant des informations futures de la cible et n’appliquez jamais de prétraitement sur l’ensemble du jeu de données avant de le diviser.

Sécurité, contrôle d’accès, gouvernance et surveillance opérationnelle

Une ingénierie des données sécurisée et auditable est obligatoire. Chiffrez les données au repos en utilisant SSE-KMS pour les volumes S3 et EBS et utilisez le chiffrement côté client pour un contrôle supplémentaire ; gérez les clés avec des CMK AWS KMS et utilisez des politiques de clé et des autorisations (grants) pour appliquer le moindre privilège. Restreignez les jeux de données S3 à un VPC en utilisant un point de terminaison d’un VPC pour S3 (S3 VPC endpoint) et des politiques de compartiment précises ou des S3 Access Points limités au principal du VPC ; combinez cela avec des rôles IAM attachés à SageMaker, Glue, EMR ou Lambda pour appliquer le moindre privilège. Pour les informations personnelles identifiables (PII) sensibles, utilisez la tokenisation ou le chiffrement au niveau du champ et assurez-vous que KMS effectue la rotation des clés conformément à la politique. Sur le plan opérationnel, activez CloudTrail pour la journalisation de l’activité des API SageMaker et Glue, et CloudWatch pour les métriques des tâches ; utilisez SageMaker Model Monitor pour la détection de dérive (drift) et configurez des alertes pour ré-entraîner ou vérifier le biais des modèles. La gouvernance des données nécessite le Glue Data Catalog ou un magasin de métadonnées d’entreprise, le lignage des données (data lineage) et le balisage (tagging) pour les politiques de cycle de vie ; mettez en œuvre des règles de cycle de vie S3 (transition vers Glacier) pour les données froides. Les idées fausses courantes incluent le fait de supposer que les groupes de sécurité seuls sont suffisants (vous avez également besoin d’IAM, de politiques de compartiment et de points de terminaison d’un VPC), ou d’oublier d’activer le chiffrement sur les volumes des instances d’entraînement — incluez toujours le chiffrement EBS dans les définitions des tâches d’entraînement et validez l’accès avec des rôles de moindre privilège.

Problème pratique : Scénario d’utilisation

Scénario : MetroRetail exploite un environnement ML sur AWS où le flux de clics des clients est ingéré dans Kinesis Data Streams, stocké dans S3, et les modèles sont entraînés dans SageMaker. Le lac de données utilise le Glue Catalog et Athena pour les analystes.

Défi : Convertir les événements de clics CSV en streaming au format Parquet dans S3 avec une évolution de schéma, produire des vecteurs de caractéristiques (feature vectors) fiables pour un modèle de recommandation, et s’assurer que le pipeline peut monter en charge sans copier des jeux de données de plusieurs gigaoctets sur les instances d’entraînement.

Approche recommandée :

1. Utilisez Kinesis Data Streams pour l’ingestion, attachez un consommateur Lambda pour effectuer une validation légère et transférer les enregistrements vers un flux de livraison Kinesis Data Firehose configuré avec le Glue Schema Registry pour convertir le JSON/CSV en Parquet et écrire des fichiers Parquet partitionnés dans S3 (avec des indicateurs de tampon (buffer hints) ajustés à ~64–128 Mo).
2. Cataloguez le Parquet dans AWS Glue ; utilisez des tâches ETL Glue (Spark sans serveur) ou SageMaker Processing (conteneur Spark) pour construire des pipelines de caractéristiques reproductibles, en appliquant l’imputation (médiane pour les valeurs numériques asymétriques), StandardScaler, et des plongements catégoriels (categorical embeddings) pour les item_id à haute cardinalité.
3. Stockez les vecteurs de caractéristiques en ligne dans SageMaker Feature Store (magasin en ligne pour les recherches à faible latence) et les caractéristiques hors ligne dans S3 (magasin hors ligne du feature store via Parquet). Entraînez dans SageMaker en utilisant le mode Pipe pointant vers les manifestes Parquet de S3 pour diffuser les données en streaming et éviter les copies complètes.
4. Sécurisez S3 avec SSE-KMS, restreignez l’accès à l’aide d’un point de terminaison d’un VPC pour S3 et de politiques de compartiment strictes pour le VPC, et activez CloudTrail + SageMaker Model Monitor pour la journalisation de l’activité et les alertes de dérive.

Justification : Cette approche tire parti de la conversion gérée du streaming vers Parquet et de l’ETL sans serveur pour la mise à l’échelle, utilise le Feature Store pour la cohérence entre l’entraînement et l’inférence, évite les déplacements de données coûteux avec le mode Pipe, et applique le chiffrement et l’accès selon le principe du moindre privilège pour une mise en production.

Tous les domaines · Analyse exploratoire des données et visualisation →

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

Parcourir Amazon →