Amazon S3: storage universale e cuore del data lake

Amazon S3 è object storage ad altissima durabilità e capacità praticamente illimitata: è il punto di atterraggio naturale per un data lake, dove dati grezzi, curati e aggregati convivono in formati aperti (Parquet, ORC, JSON, CSV) e vengono interrogati da AWS Glue, Amazon Athena o Redshift Spectrum senza doverli copiare altrove. Il vantaggio chiave è il disaccoppiamento fra storage e compute: più motori leggono lo stesso bucket, ciascuno con il proprio ciclo di vita.

La scelta della storage class governa costo e latenza. S3 Standard serve dati “hot” ad accesso frequente; S3 Standard-IA e One Zone-IA riducono il costo di storage ma aggiungono un costo di retrieval, adatti a dati “warm” letti di rado. Le classi Glacier (Instant Retrieval, Flexible Retrieval, Deep Archive) coprono l’archiviazione “cold”, con tempi di recupero da millisecondi a ore secondo la classe e costi di storage decrescenti.

Quando i pattern d’accesso sono imprevedibili o cambiano nel tempo, S3 Intelligent-Tiering sposta automaticamente gli oggetti fra tier ad accesso frequente e infrequente in base all’uso reale, senza costi di retrieval e senza dover conoscere in anticipo la frequenza. È la risposta giusta ogni volta che lo scenario dice “pattern d’accesso sconosciuti o variabili”.

Le S3 Lifecycle policy automatizzano invece le transizioni fra classi in base all’età dell’oggetto (es. dopo 30 giorni verso Standard-IA, dopo 90 verso Glacier) e l’expiration che elimina i dati scaduti. Differenza da ricordare: Lifecycle è una regola deterministica basata sul tempo; Intelligent-Tiering reagisce dinamicamente all’accesso.

Amazon Redshift: il data warehouse per analytics

Amazon Redshift è un data warehouse colonnare MPP pensato per query analitiche complesse (aggregazioni, join, BI) su grandi volumi di dati strutturati. Si sceglie quando servono join ripetuti, dashboard e reportistica su schemi a stella, non per lookup puntuali ad altissimo throughput.

Le prestazioni dipendono da come i dati sono distribuiti fra i nodi. La distribution key determina il ripartizionamento delle righe: lo stile KEY colloca sullo stesso slice le righe che condividono la colonna di join, riducendo lo shuffle; ALL replica l’intera tabella su ogni nodo, utile per dimension table piccole; EVEN distribuisce uniformemente quando non c’è una chiave di join dominante. La sort key ordina fisicamente i dati e abilita lo zone-map pruning, accelerando i filtri per intervallo (tipicamente per data). Una distribution key scelta male produce data skew e broadcasting costoso.

Con Redshift Spectrum si interrogano direttamente i file del data lake su S3 senza caricarli, combinando dati “hot” nel warehouse e dati storici su S3.

Amazon DynamoDB: NoSQL a bassa latenza

Amazon DynamoDB è un database NoSQL key-value/document, serverless e completamente gestito, con latenza a singola cifra in millisecondi a qualsiasi scala. È la scelta per accessi per chiave ad alto throughput: profili utente, cataloghi, sessioni, IoT, carrelli. Il modello si progetta partendo dagli access pattern, non dalla normalizzazione: la partition key deve avere alta cardinalità per distribuire il carico ed evitare hot partition.

DynamoDB non è un motore analitico: query ad-hoc, aggregazioni e scan estese sono costose e lente. Per l’analytics si esporta verso S3 (data lake) e si interroga con Athena o Redshift, oppure si usano gli stream verso pipeline downstream.

Abbinare workload e data store

Il criterio di fondo: object storage economico e aperto (S3) per data lake e staging; warehouse colonnare (Redshift) per BI e query complesse su dati strutturati; NoSQL (DynamoDB) per accessi per chiave a bassa latenza e alto volume. In un’architettura reale i tre coesistono e si scambiano dati.

Trappole tipiche d’esame

  • Pattern d’accesso sconosciuti o variabili → S3 Intelligent-Tiering: ottimizza il costo automaticamente; scegliere manualmente Standard-IA rischia costi di retrieval se poi l’accesso è frequente.
  • Archiviazione a lungo termine al minimo costo con recupero raro → S3 Glacier Deep Archive: è la classe più economica; accettabile solo se i tempi di recupero nell’ordine delle ore vanno bene.
  • Transizione a classe più economica dopo N giorni → S3 Lifecycle policy, non Intelligent-Tiering: quando la regola è basata sull’età deterministica dell’oggetto, la risposta è Lifecycle.
  • Join ripetuti fra due grandi tabelle lenti in Redshift → distribution key KEY sulla colonna di join: co-localizza le righe ed elimina il broadcasting; ALL è corretta solo per dimension table piccole.
  • Lookup per chiave a millisecondi ad altissima scala → DynamoDB, non Redshift: il warehouse è per analytics, non per accessi puntuali ad alto throughput.
  • Query SQL analitiche su dati già in S3 senza ingestion → Redshift Spectrum o Athena: si interroga il data lake in place, evitando di caricare tutto nel warehouse.