Domande frequenti sul caricatore automatico

Domande frequenti sul caricatore automatico di Databricks.

Il caricatore automatico elabora nuovamente il file quando il file viene accodato o sovrascritto?

I file vengono elaborati esattamente una volta, a meno che non cloudFiles.allowOverwrites sia abilitato. Quando un file viene aggiunto o sovrascritto, Azure Databricks non può garantire quale versione del file verrà elaborata. È anche consigliabile prestare attenzione quando si abilita cloudFiles.allowOverwrites in modalità di notifica file, in cui il caricatore automatico potrebbe identificare i nuovi file tramite notifiche di file e elenco di directory. A causa della discrepanza tra l'ora dell'evento di notifica file e l'ora di modifica dei file, il caricatore automatico potrebbe ottenere due timestamp diversi e quindi inserire lo stesso file due volte, anche quando il file viene scritto una sola volta.

In generale, Databricks consiglia di usare il caricatore automatico per inserire solo file non modificabili ed evitare di impostare cloudFiles.allowOverwrites. Se questo non soddisfa i requisiti, contattare il team dell'account Azure Databricks.

Se i file di dati non arrivano continuamente, ma a intervalli regolari, ad esempio, una volta al giorno, devo comunque usare questa origine e ci sono dei vantaggi?

In questo caso, è possibile configurare un Trigger.AvailableNow processo di streaming strutturato (disponibile in Databricks Runtime 10.4 LTS e versioni successive) e pianificare l'esecuzione dopo l'ora di arrivo prevista del file. Il caricatore automatico funziona bene sia con gli aggiornamenti poco frequenti che con gli aggiornamenti frequenti. Anche se gli aggiornamenti eventualmente sono molto grandi, il caricatore automatico viene ridimensionato correttamente in base alle dimensioni di input. Le tecniche di individuazione dei file efficienti del caricatore automatico e le funzionalità di evoluzione dello schema rendono auto loader il metodo consigliato per l'inserimento incrementale dei dati.

Cosa accade se si modifica la posizione del checkpoint quando si riavvia il flusso?

Una posizione del checkpoint mantiene informazioni importanti di identificazione di un flusso. La modifica della posizione del checkpoint significa che il flusso precedente è stato abbandonato e avviato un nuovo flusso.

È necessario creare in anticipo i servizi di notifica degli eventi?

No. Se si sceglie la modalità di notifica file e si forniscono le autorizzazioni necessarie, il caricatore automatico può creare automaticamente servizi di notifica file. Vedere Che cos'è la modalità di notifica file del caricatore automatico?

Ricerca per categorie pulire le risorse di notifica degli eventi create dal caricatore automatico?

È possibile usare Cloud Resource Manager per elencare ed eliminare le risorse. È anche possibile eliminare queste risorse manualmente usando l'interfaccia utente o le API del provider di servizi cloud.

È possibile eseguire più query di streaming da directory di input diverse nello stesso bucket/contenitore?

Sì, purché non siano directory padre-figlio; ad esempio, prod-logs/ e prod-logs/usage/ non funzionerebbe perché /usage è una directory figlio di /prod-logs.

È possibile usare questa funzionalità quando sono presenti notifiche sui file esistenti nel bucket o nel contenitore?

Sì, purché la directory di input non sia in conflitto con il prefisso di notifica esistente, ad esempio le directory padre-figlio precedenti.

In che modo il caricatore automatico deduce lo schema?

Quando il dataframe viene definito per la prima volta, il caricatore automatico elenca la directory di origine e sceglie la più recente (in base all'ora di modifica dei file) 50 GB di dati o 1000 file e le usa per dedurre lo schema dei dati.

Il caricatore automatico deduce anche le colonne di partizione esaminando la struttura di directory di origine e cerca i percorsi di file che contengono la /key=value/ struttura. Se la directory di origine ha una struttura incoerente, ad esempio:

base/path/partition=1/date=2020-12-31/file1.json
// inconsistent because date and partition directories are in different orders
base/path/date=2020-12-31/partition=2/file2.json
// inconsistent because the date directory is missing
base/path/partition=3/file3.json

Il caricatore automatico deduce le colonne di partizione come vuote. Usare cloudFiles.partitionColumns per analizzare in modo esplicito le colonne dalla struttura di directory.

Come si comporta il caricatore automatico quando la cartella di origine è vuota?

Se la directory di origine è vuota, il caricatore automatico richiede di fornire uno schema perché non sono presenti dati per eseguire l'inferenza.

Quando il caricatore automatico deduce lo schema? Si evolve automaticamente dopo ogni micro batch?

Lo schema viene dedotto quando il dataframe viene definito per la prima volta nel codice. Durante ogni micro batch, le modifiche dello schema vengono valutate in tempo reale; pertanto, non è necessario preoccuparsi dei risultati delle prestazioni. Quando il flusso viene riavviato, preleva lo schema evoluto dal percorso dello schema e inizia l'esecuzione senza alcun sovraccarico dall'inferenza.

Qual è l'impatto sulle prestazioni sull'inserimento dei dati quando si usa l'inferenza dello schema del caricatore automatico?

L'inferenza dello schema dovrebbe richiedere alcuni minuti per le directory di origine molto grandi durante l'inferenza dello schema iniziale. Non è consigliabile osservare riscontri significativi sulle prestazioni altrimenti durante l'esecuzione del flusso. Se si esegue il codice in un notebook di Azure Databricks, è possibile visualizzare gli aggiornamenti dello stato che specificano quando il caricatore automatico elenca la directory per il campionamento e l'inferenza dello schema dei dati.

A causa di un bug, un file non valido ha modificato drasticamente lo schema. Cosa è necessario fare per eseguire il rollback di una modifica dello schema?

Per assistenza, contattare il supporto di Databricks.