Amazon S3 come data lake

Su AWS il data lake per il machine learning è Amazon S3: storage a oggetti virtualmente illimitato, durabile e disaccoppiato dal compute. È la destinazione naturale dei dati grezzi e curati perché SageMaker (training job, Processing, batch transform) legge e scrive direttamente da S3, mentre servizi come Glue, Athena e Kinesis vi convergono. Organizza i dati per zone (raw, cleaned, curated) tramite prefissi e usa le storage class in funzione dell’accesso: S3 Standard per i dataset di training attivi, S3 Intelligent-Tiering quando i pattern di accesso sono imprevedibili, classi fredde (Glacier) solo per l’archivio non usato nel ciclo di addestramento.

Il criterio d’esame ricorrente: qualunque scenario che chieda “dove salvo i dati per il training” o “storage centrale, scalabile, integrato con SageMaker” punta a S3, non a EBS o EFS (che servono ad attach su singola istanza) né a un database relazionale.

Formati colonnari e partizionamento

Il layout fisico dei file su S3 incide su costo e latenza delle query. I formati colonnari come Parquet (e ORC) comprimono meglio e permettono a motori come Athena di leggere solo le colonne necessarie, riducendo i dati scansionati rispetto a CSV o JSON riga-per-riga. Poiché Athena fattura in base ai dati scansionati, convertire i dati in Parquet è una delle leve principali di ottimizzazione costi.

Il partizionamento completa il quadro: suddividendo i dati per chiavi ad alta selettività (es. year=/month=/day= o region=), il motore applica il partition pruning e scansiona solo le partizioni pertinenti. Attenzione al trade-off: troppe partizioni piccole generano overhead di metadata e file minuscoli. La combinazione vincente in domanda è quasi sempre “Parquet + partizionamento” per minimizzare costi e tempi di scansione.

Glue, Data Catalog e Athena

AWS Glue è il servizio serverless di ETL e di catalogazione. Un Glue crawler scansiona i dati su S3, ne inferisce lo schema e popola il Glue Data Catalog, il metastore centrale (database e tabelle) condiviso da Athena, Redshift Spectrum, EMR e i Glue job. I Glue ETL job (Spark) trasformano i dati, ad esempio convertendo CSV in Parquet partizionato.

Amazon Athena è il motore di query SQL serverless che interroga direttamente S3 usando le tabelle del Data Catalog: nessun cluster da gestire, si paga per query. È ideale per esplorazione ad hoc, feature engineering leggero e validazione dei dataset prima del training. Il pattern canonico d’esame: crawler → Data Catalog → Athena per analizzare dati su S3 senza spostarli e senza infrastruttura.

Kinesis per lo streaming

Per l’ingestione in tempo reale entra Amazon Kinesis. Con Kinesis Data Streams i dati sono ordinati per shard, durevoli e replayable (rileggibili entro il periodo di retention): utile quando servono più consumer o il riprocessing degli eventi. Amazon Data Firehose invece è la via più semplice per il delivery gestito verso destinazioni come S3, con buffering, conversione a Parquet e partizionamento dinamico integrati, senza gestire consumer. Regola pratica: se lo scenario chiede ordinamento, replay o fan-out a più consumer, è Data Streams; se chiede il caricamento gestito e trasformato verso S3 con minimo sforzo, è Firehose.

SageMaker Feature Store

Amazon SageMaker Feature Store centralizza, versiona e rende riutilizzabili le feature, eliminando il rischio di training/serving skew. Ha due componenti: l’online store, a bassa latenza e alto throughput, pensato per il recupero delle feature durante l’inferenza real-time; e l’offline store, ospitato su S3 in formato colonnare, pensato per costruire i dataset di training e per query batch/storiche. Si può ingerire in entrambi contemporaneamente. Il discrimine d’esame è la latenza: “feature per inferenza online a millisecondi” → online store; “dataset storico completo per addestrare o fare batch” → offline store su S3.

Trappole tipiche d’esame

  • Ridurre i costi delle query Athena → Parquet + partizionamento: convertire in colonnare e partizionare taglia i dati scansionati, che è la base di fatturazione; CSV non partizionato è la trappola costosa.
  • Serve replay/ordinamento degli eventi o più consumer → Kinesis Data Streams, non Firehose: Firehose è delivery gestito verso S3 e non offre replay né fan-out arbitrario.
  • Solo caricare stream su S3 con conversione a Parquet e minimo sforzo → Amazon Data Firehose: scegliere Data Streams qui aggiunge complessità inutile (gestione shard e consumer).
  • Inferenza real-time a bassa latenza sulle feature → online store; dataset di training storico → offline store su S3: invertirli è l’errore classico sul Feature Store.
  • Schema centrale condiviso da Athena/Redshift/EMR → Glue Data Catalog popolato da un crawler: non è Athena a “possedere” lo schema; il catalogo è il metastore comune.
  • Storage per dataset di training integrato con SageMaker → Amazon S3, non EBS/EFS o un RDBMS: EBS/EFS sono attaccati a singole istanze, S3 è il data lake disaccoppiato di riferimento.