Elaborazione batch e in tempo reale a confronto

Ogni soluzione dati deve decidere quando e con quale frequenza i dati vengono elaborati. Le due modalità fondamentali sono l’elaborazione batch e l’elaborazione in tempo reale (stream processing). Capire la differenza — e soprattutto sapere quale scegliere in uno scenario — è uno degli obiettivi centrali del DP-900.

Elaborazione batch

Nel batch processing i dati vengono prima raccolti e accumulati, poi elaborati tutti insieme a intervalli pianificati (ogni ora, ogni notte, a fine mese). L’elaborazione lavora quindi su un insieme di dati “fermo”, già completo al momento in cui parte il job.

Caratteristiche principali:

• Latenza alta: c’è un ritardo tra l’arrivo del dato e la sua elaborazione; i risultati non sono immediati.
• Throughput elevato: si processano grandi volumi in modo efficiente, sfruttando meglio le risorse di calcolo.
• Costo ottimizzato: le risorse si accendono solo quando il job gira, senza dover restare sempre attive.
• Ideale quando la freschezza del dato non è critica.

Esempio tipico: la fatturazione mensile. Tutte le transazioni del mese vengono raccolte e, a fine periodo, un unico processo calcola gli importi e genera le fatture. Non serve elaborare ogni transazione nell’istante in cui avviene.

Su Azure, servizi come Azure Data Factory (orchestrazione di pipeline), Azure Synapse Analytics e Microsoft Fabric con i suoi pipeline e notebook sono strumenti tipici per carichi batch.

Elaborazione in tempo reale (stream processing)

Nello stream processing ogni evento viene elaborato in continuo, quasi nell’istante in cui viene generato. I dati arrivano come un flusso costante e potenzialmente infinito, e il sistema reagisce evento per evento (o su piccole “finestre” temporali).

Caratteristiche principali:

• Bassa latenza: risposta in millisecondi o secondi.
• Flusso continuo e illimitato: non esiste un “dataset completo”, i dati continuano ad arrivare.
• Volume per singolo evento tipicamente piccolo, ma frequenza molto alta.
• Ideale quando serve reagire subito.

Esempio tipico: una dashboard IoT live che mostra temperatura e vibrazioni dei macchinari di una fabbrica. Ogni sensore invia letture di continuo, e la dashboard deve aggiornarsi immediatamente per far scattare un alert se un valore supera la soglia.

Su Azure, i servizi chiave sono Azure Stream Analytics, Azure Event Hubs e Azure IoT Hub per l’ingestione degli eventi, oltre alle capacità di Real-Time Intelligence in Microsoft Fabric.

Quando usare cosa

Il criterio di scelta ruota attorno a una domanda: quanto in fretta serve il risultato?

• Serve una risposta immediata a eventi che arrivano di continuo → stream processing.
• Basta elaborare grandi volumi periodicamente, accettando un ritardo → batch processing.

Altri fattori:

Molte architetture moderne sono ibride: usano lo streaming per gli alert immediati e il batch per l’analisi storica approfondita degli stessi dati.

Trappole tipiche d’esame

• Scenario: “Devi generare i report di vendita consolidati ogni notte su milioni di transazioni.” → È un caso di batch processing (dati accumulati, elaborati a intervalli, latenza non critica).
• Scenario: “Una dashboard deve mostrare in tempo reale i dati dei sensori di produzione e lanciare allarmi immediati.” → È stream/real-time processing, non batch.
• Scenario: “Quale servizio Azure useresti per analizzare un flusso continuo di eventi da dispositivi IoT?” → Azure Stream Analytics (con Event Hubs o IoT Hub per l’ingestione), non Data Factory.
• Trappola concettuale: “Il batch ha sempre performance peggiori del real-time.” → Falso. Il batch ha latenza più alta ma throughput più elevato: è più efficiente per grandi volumi; sono ottimizzati per obiettivi diversi.
• Scenario: “Serve orchestrare una pipeline che copia e trasforma dati da più sorgenti una volta al giorno.” → È batch, gestibile con Azure Data Factory o le pipeline di Microsoft Fabric, non con Stream Analytics.