Configurare gli intervalli di trigger di Structured Streaming

Apache Spark Structured Streaming elabora i dati in modo incrementale; il controllo dell'intervallo di trigger per l'elaborazione batch consente di usare Structured Streaming per carichi di lavoro, tra cui l'elaborazione quasi in tempo reale, l'aggiornamento dei database ogni 5 minuti o una volta all'ora o l'elaborazione batch di tutti i nuovi dati per un giorno o una settimana.

Poiché Databricks Auto Loader usa Structured Streaming per caricare i dati, comprendere il funzionamento dei trigger offre la massima flessibilità per controllare i costi durante l'inserimento dei dati con la frequenza desiderata.

Specifica degli intervalli di trigger basati sul tempo

Structured Streaming si riferisce agli intervalli di trigger basati sul tempo come "micro batch a intervalli fissi". Usando la processingTime parola chiave , specificare una durata di tempo come stringa, ad esempio .trigger(processingTime='10 seconds').

Quando si specifica un trigger intervallo troppo piccolo (inferiore a decine di secondi), il sistema potrebbe eseguire controlli non necessari per verificare se arrivano nuovi dati. Configurare il tempo di elaborazione per bilanciare i requisiti di latenza e la frequenza di arrivo dei dati nell'origine.

Configurazione dell'elaborazione batch incrementale

Importante

In Databricks Runtime 11.3 LTS e versioni successive l'impostazione Trigger.Once è deprecata. Databricks consiglia di usare Trigger.AvailableNow per tutti i carichi di lavoro di elaborazione batch incrementale.

L'opzione di trigger disponibile usa tutti i record disponibili come batch incrementale con la possibilità di configurare le dimensioni del batch con opzioni come maxBytesPerTrigger (le opzioni di ridimensionamento variano in base all'origine dati).

Azure Databricks supporta l'uso di per l'elaborazione Trigger.AvailableNow batch incrementale da molte origini structured streaming. La tabella seguente include la versione minima supportata di Databricks Runtime necessaria per ogni origine dati:

Origine	Versione minima di Databricks Runtime
Origini file (JSON, Parquet e così via)	9.1 LTS
Delta Lake	10,4 LTS
Autoloader	10,4 LTS
Apache Kafka	10,4 LTS
Cinesi	13.1

Qual è l'intervallo di trigger predefinito?

Il valore predefinito di Structured Streaming è costituito da micro batch a intervalli fissi di 500 ms. Databricks consiglia di specificare sempre un personalizzato trigger per ridurre al minimo i costi associati alla verifica dell'arrivo di nuovi dati e dell'elaborazione di batch sottodimensionati.

Modifica degli intervalli di trigger tra le esecuzioni

È possibile modificare l'intervallo di trigger tra le esecuzioni usando lo stesso checkpoint.

Se un processo Structured Streaming si arresta durante l'elaborazione di un micro batch, tale micro batch deve essere completato prima dell'applicazione del nuovo intervallo di trigger. Di conseguenza, è possibile osservare un'elaborazione micro batch con le impostazioni specificate in precedenza dopo la modifica dell'intervallo di trigger.

Quando si passa dall'intervallo basato sul tempo all'uso AvailableNowdi , questo potrebbe comportare un'elaborazione micro batch prima dell'elaborazione di tutti i record disponibili come batch incrementale.

Quando si passa da AvailableNow a un intervallo basato sul tempo, questo potrebbe comportare la continuazione dell'elaborazione di tutti i record disponibili quando è stato attivato l'ultimo AvailableNow processo. Si tratta del comportamento previsto.

Nota

Se si sta tentando di eseguire il ripristino da un errore di query associato a un batch incrementale, la modifica dell'intervallo di trigger non risolve questo problema perché il batch deve comunque essere completato. Databricks consiglia di aumentare la capacità di calcolo usata per elaborare il batch per provare a risolvere il problema. In rari casi, potrebbe essere necessario riavviare il flusso con un nuovo checkpoint.

Che cos'è la modalità di elaborazione continua?

Apache Spark supporta un intervallo di trigger aggiuntivo noto come elaborazione continua. Questa modalità è stata classificata come sperimentale a partire da Spark 2.3; rivolgersi al team dell'account di Azure Databricks per assicurarsi di comprendere i compromessi di questo modello di elaborazione.

Si noti che questa modalità di elaborazione continua non si riferisce affatto all'elaborazione continua applicata nelle tabelle live Delta.