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, poiché Auto Loader potrebbe identificare nuovi file sia tramite notifiche di file che tramite l'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 tal caso, è possibile configurare un lavoro di Structured Streaming Trigger.AvailableNow (disponibile in Databricks Runtime 10.4 LTS e versioni successive) e pianificare la sua 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 il
È 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 50 GB di dati o 1000 file più recenti (in base all'ora di modifica dei file), e questi vengono usati per inferire 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 struttura /key=value/. 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 interpreta le colonne di partizione come essere 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 dell'impatto sulle prestazioni. Quando il flusso viene riavviato, preleva lo schema evoluto dal percorso dello schema e inizia l'esecuzione senza alcun costo aggiuntivo derivante dall'inferenza.
Qual è l'impatto sulle prestazioni durante l'inserimento dei dati quando si utilizza l'inferenza dello schema di Auto Loader?
Ci si dovrebbe aspettare che l'inferenza dello schema richieda alcuni minuti per le directory di origine molto grandi durante la fase iniziale. Non è consigliabile osservare riscontri significativi sulle prestazioni altrimenti durante l'esecuzione del flusso. Se esegui il codice in un notebook di Azure Databricks, puoi vedere gli aggiornamenti di stato che indicano quando Auto Loader farà l'elenco della directory per il campionamento e l'inferenza dello schema 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.