Elaborazione dei dati in batch e in streaming in Azure Databricks

Questo articolo descrive le differenze principali tra batch e streaming, due semantiche di elaborazione dati diverse usate per i carichi di lavoro di ingegneria dei dati, tra cui inserimento, trasformazione ed elaborazione in tempo reale.

Lo streaming è comunemente associato a bassa latenza e all'elaborazione continua da bus di messaggi, ad esempio Apache Kafka.

Tuttavia, in Azure Databricks ha una definizione più estesa. Il motore sottostante delle pipeline dichiarative di Lakeflow (Apache Spark e Structured Streaming) ha un'architettura unificata per l'elaborazione batch e di streaming:

• Il motore può trattare origini come l'archiviazione di oggetti cloud e Delta Lake come origini di streaming per un'elaborazione incrementale efficiente.
• L'elaborazione dei flussi può essere eseguita sia in modalità a richiesta che continua, offrendo la flessibilità necessaria per controllare i compromessi tra costi e prestazioni per i carichi di lavoro di streaming.

Di seguito sono riportate le differenze semantiche fondamentali che distinguono batch e streaming, inclusi i relativi vantaggi e svantaggi e considerazioni per la scelta dei carichi di lavoro.

Semantica di gruppo

Con l'elaborazione batch, il motore non tiene traccia dei dati già elaborati nell'origine. Tutti i dati attualmente disponibili nell'origine vengono elaborati al momento dell'elaborazione. In pratica, un'origine dati batch viene in genere partizionata logicamente, ad esempio per giorno o area, per limitare la rielaborazione dei dati.

Ad esempio, il calcolo del prezzo medio delle vendite degli articoli, aggregato a una granularità oraria, per un evento di vendita eseguito da una società di e-commerce può essere pianificato come elaborazione batch per calcolare il prezzo medio delle vendite ogni ora. Con il batch, i dati delle ore precedenti vengono rielaborati ogni ora e i risultati calcolati in precedenza vengono sovrascritti per riflettere i risultati più recenti.

Semantica di streaming

Con l'elaborazione dei flussi di dati, il motore tiene traccia dei dati elaborati e elabora solo i nuovi dati nelle esecuzioni successive. Nell'esempio precedente è possibile pianificare l'elaborazione in streaming anziché l'elaborazione batch per calcolare il prezzo medio di vendita ogni ora. Con lo streaming, solo i nuovi dati aggiunti all'origine dall'ultima esecuzione vengono elaborati. I risultati appena calcolati devono essere aggiunti ai risultati calcolati in precedenza per controllare i risultati completi.

Batch contro streaming

Nell'esempio precedente, lo streaming è migliore dell'elaborazione batch perché non elabora gli stessi dati elaborati nelle esecuzioni precedenti. Tuttavia, l'elaborazione in streaming diventa più complessa con scenari come dati fuori ordine e in ritardo nell'origine.

Un esempio di dati di arrivo in ritardo è se alcuni dati di vendita della prima ora non arrivano all'origine fino alla seconda ora:

• Nell'elaborazione batch, i dati di arrivo in ritardo della prima ora verranno elaborati con i dati della seconda ora e i dati esistenti della prima ora. I risultati precedenti della prima ora verranno sovrascritti e corretti con i dati di arrivo in ritardo.
• Nell'elaborazione del flusso di dati, i dati in arrivo in ritardo dalla prima ora verranno elaborati senza i dati della prima ora che sono stati già elaborati. La logica di elaborazione deve archiviare le informazioni sulla somma e sul conteggio dei calcoli medi della prima ora per aggiornare correttamente i risultati precedenti.

Queste complessità di streaming vengono in genere introdotte quando l'elaborazione è con mantenimento dello stato, ad esempio join, aggregazioni e deduplicazioni.

Per l'elaborazione in streaming senza stato, come l'aggiunta di nuovi dati dalla sorgente, la gestione dei dati fuori ordine e in ritardo è meno complessa, perché i dati in ritardo possono essere aggiunti ai risultati precedenti man mano che arrivano alla sorgente.

La tabella seguente illustra i vantaggi e i svantaggi dell'elaborazione batch e di streaming e le diverse funzionalità del prodotto che supportano queste due semantiche di elaborazione in Databricks Lakeflow.

	Gruppo	Trasmissione in diretta
Vantaggi	La logica di elaborazione è semplice. I risultati sono sempre accurati e riflettono tutti i dati disponibili nell'origine.	Vengono elaborati in modo efficiente solo i nuovi dati. Più velocemente, potrebbe gestire i requisiti di latenza da ore a minuti, secondi e millisecondi.
Svantaggi	Non è altrettanto efficiente; i dati verranno rielaborati in una particolare partizione batch. Più lento potrebbe gestire i requisiti di latenza da ore a minuti, ma non secondi o millisecondi.	La logica di elaborazione potrebbe essere complessa, soprattutto per l'elaborazione con stato, ad esempio join, aggregazioni, deduplicazioni e così via. I risultati non possono sempre essere accurati, considerando i dati non ordinati e di arrivo in ritardo.
Prodotti di ingegneria dei dati	Flusso di visualizzazione materializzato delle pipeline dichiarative di Lakeflow e vista materializzata. Databricks Runtime - Apache Spark (spark.read.load() e spark.write.save()).	Lakeflow Connect. Aggiungere flusso, applicare il flusso di cambiamento nelle pipeline dichiarative di Lakeflow, alla tabella di streaming e alla destinazione. Databricks Runtime - Spark Structured Streaming (spark.readStream.load() e spark.writeStream.start()).

Consigli

La tabella seguente illustra la semantica di elaborazione consigliata in base alle caratteristiche dei carichi di lavoro di elaborazione dati a ogni livello dell'architettura medallion.

Livello medaglione	Caratteristiche del carico di lavoro	Raccomandazione
Bronzo	Carichi di lavoro di acquisizione. In genere non è necessaria alcuna elaborazione senza stato per l'accodamento incrementale da origini dati. Le dimensioni dei dati sono in genere maggiori.	L'elaborazione di streaming è in genere una scelta migliore, dato che gli utenti possono trarre vantaggio dai vantaggi dello streaming, ma non vengono esposti alle complessità dell'elaborazione di streaming con stato.
Argento	Carichi di lavoro di trasformazione. In genere comporta sia l'elaborazione senza stato, come il filtraggio, sia l'elaborazione con stato, come i join, le aggregazioni e le deduplicazioni.	Usare l'elaborazione batch (con aggiornamento incrementale nelle viste materializzate) per evitare le complessità dell'elaborazione di streaming stateful. Usare l'elaborazione di streaming come opzione per i casi d'uso in cui l'efficienza e la latenza sono molto più importanti rispetto all'accuratezza dei risultati. Tenere presente le complessità introdotte dall'elaborazione dello streaming con stato.
Oro	Carichi di lavoro di aggregazione dell'ultimo miglio. In genere comporta l'elaborazione di dati con stato, ad esempio join e aggregazioni. Le dimensioni dei dati sono in genere inferiori.	Usare l'elaborazione batch (con aggiornamento incrementale nelle viste materializzate) per evitare le complessità dell'elaborazione di streaming stateful.