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

By Laurynas Brazys · 3 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

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

Concetto fondamentale

L’ingegneria dei dati per il ML consiste nel produrre input riproducibili e verificabili per l’addestramento e l’inferenza dei modelli, minimizzando al contempo il leakage e l’onere operativo. Al centro di tutto vi sono semantiche di ingestion coerenti (tempo dell’evento, identificatore del record, schema), un catalogo di metadati canonico e trasformazioni ben definite che possono essere eseguite sia offline per l’addestramento del modello, sia online per l’inferenza in tempo reale. Architettate le vostre pipeline in modo che lo stesso codice di trasformazione (o le stesse definizioni dei record del Feature Store) supporti sia i set di dati di addestramento sia le feature online restituite al momento dell’inferenza; questo evita lo skew tra addestramento e servizio (train/serve skew). Per i problemi temporali, preservate il tempo dell’evento per ogni record e applicate join e suddivisioni consapevoli del tempo (time-aware) per prevenire il leakage delle etichette (label leakage); quando si utilizza SageMaker Feature Store, impostate un RecordIdentifierFeatureName e un EventTimeFeatureName in CreateFeatureGroup in modo che l’addestramento e l’inferenza a valle utilizzino chiavi identiche.

L’ingegneria delle feature (feature engineering) si suddivide in trasformazioni deterministiche e ripetibili e trasformazioni esplorative. Le trasformazioni deterministiche includono l’imputazione, la scalatura, la codifica categorica e le aggregazioni derivate (conteggi progressivi, feature basate su finestre temporali). Eseguite queste operazioni come codice che può essere eseguito in Glue ETL, SageMaker Processing o SageMaker Data Wrangler e che può essere salvato tramite checkpoint in uno store offline. Per le feature categoriche ad alta cardinalità, preferite la codifica target (target encoding) con fold di validazione incrociata o rappresentazioni basate sulla frequenza o su embedding, piuttosto che una codifica one-hot ingenua, per evitare l’esplosione combinatoria. Per le feature numeriche, preferite la standardizzazione (media/varianza) o le trasformazioni quantiliche, adatte alle pipeline, memorizzate come parametri in un artefatto del modello, in modo che la normalizzazione in produzione corrisponda a quella dell’addestramento.

Servizi e configurazioni chiave

AWS Glue fornisce il livello canonico di ETL e metadati per molte pipeline di ML. Utilizzate i Glue Crawlers per popolare il Glue Data Catalog per sorgenti S3 e JDBC, quindi create job ETL Glue basati su Spark o job visuali di Glue Studio per pulire e trasformare i dati. Configurate i job Glue con GlueVersion (ad esempio 3.0), WorkerType (G.1X, G.2X), NumberOfWorkers, JobBookmarks per l’elaborazione incrementale e DefaultArguments come "--additional-python-modules" per includere librerie come awswrangler o pydeequ. Per l’ingestion da MySQL on-premise, stabilite una connessione Glue con un URL JDBC e utilizzate i job Glue o AWS DMS per catturare il CDC (Change Data Capture) in una landing zone S3; quando si utilizza DMS, selezionate il caricamento completo (full-load) seguito dal CDC e scegliete come destinazione S3 in formato Parquet per feature offline efficienti.

SageMaker Feature Store è l’opzione centrale per la gestione delle feature, con un basso onere operativo su larga scala. CreateFeatureGroup richiede FeatureDefinitions, RecordIdentifierFeatureName, EventTimeFeatureName, OnlineStoreConfig (con EnableOnlineStore=True per abilitare uno store a bassa latenza basato su DynamoDB) e OfflineStoreConfig con S3Uri e DataCatalogConfig per esporre le feature offline tramite Athena/Glue. Eseguite l’ingestion con BatchPutRecord o PutRecord a seconda del throughput; includete il FeatureGroupArn e il RoleArn che concede al servizio i permessi PutRecord. Lo store offline persiste i file Parquet in S3 e si integra automaticamente con il Glue Data Catalog, abilitando query di addestramento riproducibili. Per le feature in tempo reale, usate GetRecord sullo store online; per i join di addestramento massivi (bulk), preferite il percorso S3 Parquet dello store offline.

Per la governance dei modelli e i flussi di lavoro di deployment, utilizzate SageMaker Model Registry e SageMaker Pipelines. Registrate i modelli addestrati con CreateModelPackage o con lo step RegisterModel delle Pipelines e impostate ModelApprovalStatus su "PendingManualApproval" per imporre un gate di approvazione manuale. Integrate le Pipelines con AWS CodePipeline o aggiungete una Lambda personalizzata che faccia passare le versioni del model_package allo stato "Approved" tramite UpdateModelPackage quando autorizzate. Per il monitoraggio del drift e del bias, combinate SageMaker Clarify per l’analisi del bias e della baseline con SageMaker Model Monitor per il rilevamento continuo del drift dei dati e delle etichette (data/label drift). Utilizzate ClarifyProcessor (sagemaker.processing.ProcessingJob) per la valutazione del bias on-demand, puntandolo agli artefatti Parquet dello store offline o ai campioni in streaming raccolti da Model Monitor.

Pattern di progettazione e compromessi

Scegliere architetture offline-first quando il throughput del training e le join complesse sono importanti: aggregare e persistere feature windowed di grandi dimensioni in S3 Parquet (tramite processi Glue/EMR/Glue Spark), catalogarle in Glue Data Catalog e versionare i set di dati con prefissi S3 e l’object-versioning. Questo approccio favorisce la riproducibilità e uno storage a basso costo, ma aumenta la latenza nel servire feature aggiornate. Quando sono richieste feature a bassa latenza, eseguire il mirroring di un sottoinsieme su Feature Store Online (DynamoDB) o su un livello di caching; il compromesso è l’overhead operativo per mantenere coerenti gli store online e offline. Utilizzare le pipeline integrate

undefined

di Feature Store o l’ingestion di flussi tramite Kinesis Data Streams + Lambda che scrive su Feature Store per ottenere aggiornamenti quasi in tempo reale, mantenendo al contempo una vista canonica offline.

Per la sperimentazione iterativa rispetto al throughput di produzione, SageMaker Pipelines con caching offre un notevole vantaggio: abilitare

undefined

negli step della pipeline in modo che le trasformazioni ad alta intensità di calcolo e persino gli step di training vengano saltati quando i loro input (parametri, checksum dei dati) non sono cambiati. Ciò riduce la latenza di avvio per le esecuzioni consecutive rispetto al provisioning ripetuto di risorse di calcolo identiche. Per un’inferenza a latenza estremamente bassa, si scambierà il costo con la complessità: gli endpoint multi-modello o la provisioned concurrency riducono la variabilità del cold-start ma aumentano i costi; l’uso di Feature Store online più un container del modello leggero minimizza l’orchestrazione per richiesta.

Le scelte dell’algoritmo e del preprocessing presentano dei compromessi: l’XGBoost integrato eccelle nei task di frode su dati tabulari e fornisce

undefined

per affrontare lo sbilanciamento delle classi senza ricampionamento, il che è leggero dal punto di vista operativo. Tuttavia, i modelli deep con embedding gestiscono le variabili categoriche ad alta cardinalità in modo più elegante, ma richiedono più infrastruttura e pipeline di feature. Ove possibile, utilizzare trasformazioni automatizzate: SageMaker Data Wrangler e Glue DataBrew forniscono trasformazioni visive e ripetibili (imputazione, normalizzazione, ricampionamento) e possono esportare i flussi in script o su Feature Store, riducendo i tempi di ingegnerizzazione.

Errori comuni e criteri decisionali

Un errore frequente è non allineare le trasformazioni tra la fase di training e quella di inferenza. Archiviare i parametri di trasformazione (scaler, encoder) con il modello o nel Feature Store, in modo che la pre-elaborazione online sia identica a quella del training. Un’altra trappola è l’uso del one-hot encoding per categorie ad alta cardinalità, che causa un’eccessiva dimensionalità delle feature; è preferibile usare embedding, hashing o codifiche basate sulla frequenza del target (target-frequency encoding) e convalidarle tramite procedure cross-validate che prevengano il leakage. Anche gli errori di sicurezza sono comuni: quando si esegue il training su dati sensibili in S3, imporre l’uso di SSE-KMS (KmsKeyId), limitare l’accesso con policy dei bucket S3 e ruoli IAM (principal sagemaker.amazonaws.com) ed eseguire i processi di training in un VPC con endpoint gateway S3, in modo che i dati non attraversino la rete internet pubblica.

Per decidere tra un ETL basato su processi Glue e l’uso di SageMaker Processing/Data Wrangler, si valutano la frequenza e la complessità: Glue è ottimizzato per ETL Spark scalabili e pianificati su più sorgenti e si integra con il Glue Data Catalog; Data Wrangler e SageMaker Processing sono adatti per una sperimentazione rapida e per l’esportazione diretta verso il Feature Store o i processi di training. Per il rilevamento delle anomalie, utilizzare Amazon Lookout for Metrics per il rilevamento statistico automatico di anomalie su serie temporali senza operazioni di MLOps complesse, ma scegliere Deequ in esecuzione su Glue per controlli di qualità dei dati personalizzabili e consapevoli del lineage, in grado di inviare le metriche a delle dashboard.

Scenario d’uso pratico

Azienda: FinEdge

FinEdge sta costruendo un servizio di rilevamento frodi che deve addestrare modelli a partire da log transazionali batch giornalieri in Amazon S3 e da profili cliente archiviati in un database MySQL on-premise. I dati devono rimanere crittografati e isolati; le versioni del modello richiedono un’approvazione manuale prima del deployment in produzione; i modelli devono avere una valutazione on-demand di bias e drift; l’inferenza necessita di un recupero delle feature a bassa latenza.

1. Ingestione e centralizzazione: Usare AWS DMS per eseguire un caricamento iniziale completo (full load) e una replica CDC (Change Data Capture) dal MySQL on-premise a una landing zone S3 come file Parquet. Configurare DMS con le impostazioni del target S3 e assicurare l’uso di SSL per la sorgente JDBC. Usare un Glue Crawler per registrare sia i log transazionali S3 sia i profili cliente in formato Parquet provenienti da DMS nel Glue Data Catalog. Impostare i parametri del processo Glue: GlueVersion 3.0, WorkerType G.2X, NumberOfWorkers adeguato al volume giornaliero e abilitare i JobBookmarks per esecuzioni incrementali.

2. Ingegneria delle feature e archiviazione: Creare trasformazioni Spark in Glue o usare SageMaker Data Wrangler per iterazioni interattive sulle feature e per l’esportazione. Rendere persistenti le feature aggregate deterministiche su S3 come file Parquet e creare un FeatureGroup in SageMaker Feature Store con

undefined

specificando le FeatureDefinitions, RecordIdentifierFeatureName=“transaction_id”, EventTimeFeatureName=“event_time”, OnlineStoreConfig con EnableOnlineStore=True e OfflineStoreConfig S3Uri che punta al data lake canonico e DataCatalogConfig per collegare la tabella Glue. Ingestire i dati tramite

undefined

per caricamenti massivi e

undefined

per aggiornamenti transazionali.

3. Training e registro dei modelli: Usare SageMaker Pipelines per pre-elaborazione, training e registrazione. Includere uno step

undefined

che registri il modello in un ModelPackageGroupName e imposti ModelApprovalStatus=“PendingManualApproval”. Agganciare un’azione di approvazione manuale di AWS CodePipeline o usare l’API SageMaker

undefined

per spostare i pacchetti approvati allo stato “Approved”. Per lo squilibrio delle classi, impostare l’iperparametro di XGBoost “scale_pos_weight” in base al rapporto tra le classi calcolato nelle statistiche di base per evitare la complessità del ricampionamento.

4. Governance, monitoraggio e controlli on-demand: Creare baseline con SageMaker Clarify usando un ClarifyProcessor per calcolare le metriche di bias e salvare le baseline su S3/FeatureStore offline. Eseguire il deployment di Model Monitor con

undefined

per il drift dei dati/feature; per una valutazione on-demand di bias o drift, eseguire programmaticamente un ClarifyProcessor o

undefined

per analizzare il traffico catturato di recente o lo snapshot dell’online store. Archiviare gli output del monitoraggio su S3 e visualizzare le anomalie tramite dashboard QuickSight. Proteggere S3 usando SSE-KMS, limitare l’accesso tramite ruoli IAM con il principio del privilegio minimo e collocare training e inferenza in un VPC con un endpoint S3.

Motivazione della scelta AWS: Questo approccio utilizza Glue e DMS per un’ingestione e metadati scalabili e verificabili tramite il Glue Data Catalog; SageMaker Feature Store per feature coerenti tra online e offline e recupero a bassa latenza; SageMaker Pipelines e Model Registry per controllare il ciclo di vita del modello con un overhead operativo minimo e supporto integrato per l’approvazione manuale; Clarify e Model Monitor per fornire analisi di bias/drift on-demand e continue. La combinazione preserva l’isolamento tramite crittografia (SSE-KMS, endpoint VPC), riduce il lavoro di ingegneria utilizzando servizi gestiti per l’ingestione e la gestione delle feature, e impone la creazione di artefatti di ML riproducibili e verificabili.

Tutti i domini · Addestramento del modello e ottimizzazione degli iperparametri →

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

Sfoglia Amazon →