Amazon MLS-C01: Ingegneria dei dati e ingegneria delle feature — Guida allo studio

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

Fa parte della AWS Machine Learning Specialty MLS-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Ingestion e storage dei dati, e formati dei file

La progettazione di un data lake pronto per il ML inizia con la scelta del giusto pattern di ingestion e del formato di persistenza. Per la telemetria in tempo reale, utilizzare Kinesis Data Streams (elaborazione a bassa latenza) o Kinesis Data Firehose (consegna gestita). Firehose può consegnare i dati direttamente in Amazon S3 ed eseguire la conversione del formato dei record lato server in Parquet/ORC se combinato con AWS Glue Schema Registry e una trasformazione Lambda; scegliere Data Streams + Kinesis Data Analytics o Lambda se si necessita di arricchimenti personalizzati o risposte inferiori al secondo. Per la migrazione di massa (bulk), utilizzare AWS DataSync, Database Migration Service (DMS) per sorgenti RDS/OLTP, o Snowball per trasferimenti offline su scala terabyte. Su S3, archiviare in formato colonnare Parquet per carichi di lavoro analitici (predicate pushdown, compressione come Snappy, chiavi di partizione ottimizzate per i pattern di query) e in formato TFRecord per alimentare pipeline TensorFlow che richiedono letture sequenziali ad alto throughput. Attenzione all’esplosione di file di piccole dimensioni: bufferizzare le scritture (buffering di Firehose, batching di Glue) per produrre oggetti S3 dimensionati per i framework big-data (da decine a centinaia di MB). L’evoluzione dello schema è comune: utilizzare Glue Catalog e Schema Registry per versionare gli schemi; usare partizionamento e convenzioni di denominazione per evitare costose scansioni complete delle tabelle (full-table scan). Una trappola comune è l’uso della modalità File (File mode) nell’elaborazione a valle, che copia interi dataset sui nodi di calcolo; preferire lo streaming (modalità Pipe di SageMaker), Redshift Spectrum o Athena alla copia massiva quando i dataset contengono milioni di record.

ETL serverless e su cluster: Glue, EMR, Redshift e SageMaker

Le scelte per l’ETL dipendono da scala, personalizzazione, profilo di costo e necessità di librerie. AWS Glue fornisce ETL Spark serverless con catalogazione, crawler e orchestrazione dei job integrata: eccellente per trasformazioni frequenti e basate su eventi in cui si desidera una scalabilità gestita. EMR è preferibile quando si necessita di ecosistemi Spark/Hadoop personalizzati, cluster a lunga esecuzione o librerie specializzate (GraphX, build personalizzate di MLlib) e si può usare S3 come data lake sottostante. Per l’analisi senza ingestion, utilizzare Redshift Spectrum o Athena per interrogare direttamente i file Parquet/ORC in S3; Redshift è migliore per join complessi e carichi di lavoro di BI. Per la preparazione dei dati per il modello, i job di SageMaker Processing forniscono container gestiti per eseguire pre-elaborazioni scalabili in Spark o Python, garantendo che il codice di preprocessing venga eseguito vicino all’addestramento e possa essere versionato con il job di training. Quando si avvia un training SageMaker con algoritmi integrati, fornire come minimo l’immagine di training, il ruolo IAM, il tipo/numero di istanze (instance_type/count) e l’URI S3 per i dati di addestramento; considerare la modalità Pipe (Pipe mode) per lo streaming dei record ed evitare la copia su EBS per dataset con milioni di record. Trappole comuni: scegliere Glue per trasformazioni a latenza estremamente bassa (usare invece Lambda/Kinesis) o copiare inutilmente dati da S3 in HDFS/EBS quando Redshift Spectrum/Athena sarebbero sufficienti.

Feature engineering, pipeline di trasformazione e selezione

La feature engineering deve essere riproducibile e isolata dal data leakage. Implementare il preprocessing come pipeline di livello produzione (Pipeline di scikit-learn, pipeline di Spark ML, o SageMaker Processing + Feature Store) in modo che le stesse trasformazioni vengano applicate sia in fase di training che di inferenza. Gestire i valori mancanti (missingness) con una selezione di strategie: imputazione semplice (media/mediana/moda) per piccole lacune; metodi basati su modelli (KNN, MICE iterativo) quando altre feature possono predire i valori mancanti. Scalare le feature numeriche con StandardScaler o MinMax per i modelli basati su gradiente; applicare una scalatura robusta (robust scaling) se dominano gli outlier. Per le variabili categoriche, scegliere il one-hot encoding per bassa cardinalità, il target encoding o learned embeddings per categorie ad alta cardinalità (usare Embeddings nei modelli deep o feature hashing per il controllo della dimensionalità). Per il testo, eseguire una normalizzazione coerente (minuscolo, punteggiatura, tokenizzazione); usare Word2Vec/BlazingText per gli embedding o pipeline TF-IDF/sparse per i modelli lineari; BlazingText in SageMaker supporta skip-gram/CBoW ed è efficiente su larga scala. Per la selezione delle feature, usare regolarizzazione L1, importanza basata su alberi (XGBoost/RandomForest), mutua informazione o eliminazione ricorsiva delle feature (recursive feature elimination), ed eseguire sempre la selezione delle feature all’interno dei fold della cross-validation per evitare bias di selezione. La più grande trappola pratica è il leakage: non derivare mai feature utilizzando informazioni future sul target né applicare il preprocessing sull’intero dataset prima di suddividerlo (splitting).

Sicurezza, controllo degli accessi, governance e monitoraggio operativo

Un’ingegneria dei dati sicura e verificabile è obbligatoria. Crittografare i dati a riposo (at rest) utilizzando SSE-KMS per i volumi S3 ed EBS e usare la crittografia lato client per un controllo aggiuntivo; gestire le chiavi con le CMK di AWS KMS e utilizzare policy delle chiavi e grant per applicare il principio del privilegio minimo (least privilege). Limitare l’accesso ai dataset S3 a un VPC utilizzando un endpoint VPC di S3 e policy di bucket precise o S3 Access Points con ambito limitato al principal del VPC; combinare questo con ruoli IAM associati a SageMaker, Glue, EMR o Lambda per applicare il principio del privilegio minimo. Per dati PII sensibili, utilizzare la tokenizzazione o la crittografia a livello di campo e assicurarsi che KMS esegua la rotazione delle chiavi secondo la policy. A livello operativo, abilitare CloudTrail per la registrazione delle attività API di SageMaker e Glue e CloudWatch per le metriche dei processi; utilizzare SageMaker Model Monitor per il rilevamento del drift e impostare allarmi per rieseguire l’addestramento o verificare il bias dei modelli. La governance dei dati richiede il Glue Data Catalog o un metadata store aziendale, il tracciamento del lignaggio dei dati (data lineage) e l’uso di tag per le policy di ciclo di vita; implementare regole di ciclo di vita di S3 (transizione a Glacier) per i dati freddi (cold data). Tra gli errori comuni vi è il presupporre che i security group da soli siano sufficienti (sono necessari anche IAM, policy di bucket ed endpoint VPC), o dimenticare di abilitare la crittografia sui volumi delle istanze di addestramento: includere sempre la crittografia EBS nelle definizioni dei processi di addestramento e convalidare l’accesso con ruoli basati sul principio del privilegio minimo.

Problema Pratico: Scenario d’Uso

Scenario: MetroRetail gestisce un ambiente ML su AWS in cui il clickstream dei clienti viene ingerito tramite Kinesis Data Streams, archiviato in S3 e i modelli vengono addestrati in SageMaker. Il data lake utilizza Glue Catalog e Athena per gli analisti.

Sfida: Convertire gli eventi di click in formato CSV provenienti da uno stream in formato Parquet su S3, gestendo l’evoluzione dello schema; produrre vettori di feature affidabili per un modello di raccomandazione; e garantire che la pipeline sia scalabile senza copiare dataset di svariati gigabyte sulle istanze di addestramento.

Approccio Raccomandato:

1. Utilizzare Kinesis Data Streams per l’ingestion, collegare un consumer Lambda per eseguire una validazione leggera e inoltrare i record a un delivery stream di Kinesis Data Firehose configurato con Glue Schema Registry per convertire da JSON/CSV a Parquet e scrivere file Parquet partizionati su S3 (con buffer hints ottimizzati a circa 64–128 MB).
2. Catalogare i dati Parquet in AWS Glue; utilizzare processi ETL di Glue (Spark serverless) o SageMaker Processing (container Spark) per costruire pipeline di feature riproducibili, applicando l’imputazione (mediana per valori numerici con distribuzione asimmetrica), StandardScaler e embedding categoriali per item_id ad alta cardinalità.
3. Archiviare i vettori di feature online in SageMaker Feature Store (online store per ricerche a bassa latenza) e le feature offline in S3 (offline store del feature store tramite Parquet). Eseguire l’addestramento in SageMaker utilizzando la modalità Pipe, puntando ai manifest Parquet di S3 per trasmettere i dati in streaming ed evitare copie complete.
4. Proteggere S3 con SSE-KMS, limitare l’accesso utilizzando un endpoint VPC di S3 e policy di bucket restrittive per il VPC, e abilitare CloudTrail + SageMaker Model Monitor per la registrazione delle attività e gli allarmi di drift.

Logica: Questo approccio sfrutta la conversione gestita da streaming a Parquet e l’ETL serverless per garantire la scalabilità, utilizza il Feature Store per la coerenza tra addestramento e inferenza, evita costosi spostamenti di dati con la modalità Pipe e impone la crittografia e l’accesso basato sul principio del privilegio minimo per essere pronto per la produzione.

Tutti i domini · Analisi esplorativa dei dati e visualizzazione →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Amazon →