Batch vs streaming: il primo bivio

Prima di scegliere un servizio, chiarisci il pattern di ingestione. Il batch raccoglie i dati in blocchi a intervalli (orari, giornalieri) ed è adatto a carichi tolleranti alla latenza: ETL notturni, caricamenti massivi, consolidamento di file. Lo streaming processa i record in modo continuo, con latenza dell’ordine dei secondi, ed è la scelta per clickstream, telemetria IoT, log applicativi e metriche in tempo reale. L’esame DEA-C01 (passing score 700/1000) propone spesso scenari in cui una parola chiave — “real-time”, “near-real-time”, “una volta al giorno”, “senza gestire server” — indica già il servizio corretto.

Amazon Kinesis: Data Streams vs Data Firehose

Kinesis Data Streams (KDS) è uno stream durevole pensato per l’elaborazione custom: più consumer indipendenti (Lambda, applicazioni con Kinesis Client Library, Managed Service for Apache Flink) leggono lo stesso stream, con retention configurabile e replay dei dati. La capacità si misura in shard: in modalità provisioned ogni shard sostiene circa 1 MB/s o 1.000 record/s in scrittura e 2 MB/s in lettura. Il calcolo del throughput determina il numero di shard: dividi il volume atteso in ingresso per la capacità di un singolo shard e prendi il massimo tra il vincolo in MB/s e quello in record/s. La modalità on-demand elimina il dimensionamento manuale scalando in automatico, con un modello di costo diverso.

Kinesis Data Firehose (Amazon Data Firehose) è invece delivery gestita, near-real-time, senza shard da amministrare: bufferizza per dimensione o intervallo di tempo e consegna a destinazioni come Amazon S3, Amazon Redshift o OpenSearch. È l’opzione naturale per alimentare una S3 landing zone: può trasformare i record con Lambda e convertirli in formati colonnari (Parquet, ORC) prima della scrittura. Non offre però consumer multipli né replay. Regola pratica: se ti basta far “atterrare” dati grezzi con minimo overhead, scegli Firehose; se ti serve logica real-time o più consumer, scegli Data Streams (eventualmente con Firehose a valle).

Amazon MSK e AWS DMS

Amazon MSK (Managed Streaming for Apache Kafka) è la scelta quando esiste già un ecosistema Kafka o ne servono le API, i topic/partition e strumenti come Kafka Connect o lo Schema Registry. Rispetto a Kinesis riduci l’onere operativo del cluster mantenendo la compatibilità Kafka; MSK Serverless elimina anche il dimensionamento dei broker. Preferisci MSK quando il requisito cita esplicitamente Kafka, migrazioni da cluster self-managed o portabilità dell’ecosistema.

AWS DMS (Database Migration Service) serve a ingerire dati dai database, non dagli stream. Supporta full load (copia iniziale completa) seguito da CDC (change data capture), che replica in continuo insert, update e delete dalla sorgente. È lo strumento tipico per portare un database relazionale (o alcuni NoSQL) verso target come Amazon S3, Redshift o un altro database, mantenendoli sincronizzati. Quando lo scenario parla di “database di origine”, “carico iniziale più modifiche incrementali” o “sincronizzazione continua”, pensa a DMS.

Trappole tipiche d’esame

  • Serve solo consegnare log su S3 senza gestire infrastruttura → soluzione: usa Kinesis Data Firehose, non Data Streams; gli shard di KDS sono overhead inutile quando basta la delivery bufferizzata verso una S3 landing zone.
  • Servono più consumer indipendenti o replay dei dati → soluzione: scegli Kinesis Data Streams; Firehose consegna a una sola destinazione e non conserva i record per riletture.
  • “Latenza sub-secondo per consumer” → soluzione: attiva l’enhanced fan-out su Data Streams; Firehose è near-real-time (buffer a tempo o dimensione), non real-time puro.
  • Il requisito cita Kafka o Kafka Connect → soluzione: vai su Amazon MSK, non su Kinesis; la compatibilità con le API Kafka è il discriminante, anche se entrambi fanno streaming.
  • Carico iniziale del database più modifiche continue → soluzione: AWS DMS con full load + CDC; Kinesis e MSK ingeriscono eventi, non fanno replica CDC nativa da un database relazionale.
  • Throughput in crescita imprevedibile su Data Streams → soluzione: valuta la modalità on-demand invece di ricalcolare gli shard a mano, per scalare in automatico ed evitare throttling da sotto-provisioning.