Domande frequenti sul caricatore automatico

Trovare le risposte alle domande frequenti sul caricatore automatico di Databricks.

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

Con l'impostazione predefinita (cloudFiles.allowOverwrites = false), i file vengono elaborati esattamente una volta. Quando un file viene aggiunto o sovrascritto, il caricatore automatico non può garantire quale versione del file verrà elaborata. Per consentire al caricatore automatico di elaborare nuovamente il file quando viene aggiunto o sovrascritto, è possibile impostare su cloudFiles.allowOverwritestrue. In questo caso, il caricatore automatico è garantito di elaborare la versione più recente del file. Tuttavia, il caricatore automatico non può garantire quale versione intermedia viene elaborata.

Prestare attenzione se si abilita cloudFiles.allowOverwrites in modalità di notifica dei file. In modalità di notifica file, il caricatore automatico potrebbe identificare i nuovi file tramite le notifiche dei file e l'elenco di directory. Poiché l'ora dell'evento di notifica file e l'ora di modifica dei file possono variare, il caricatore automatico potrebbe ricevere due timestamp diversi e inserire lo stesso file due volte, anche se il file non è stato aggiornato.

Con cloudFiles.allowOverwrites l'abilitazione, è necessario gestire manualmente i record duplicati. Il caricatore automatico rielaborerà l'intero file anche quando viene aggiunto o parzialmente aggiornato. In generale, Azure Databricks consiglia di usare il caricatore automatico per inserire solo file non modificabili e usando l'impostazione cloudFiles.allowOverwrites = falsepredefinita . Per altre domande, contattare il team dell'account Azure Databricks.

In che modo il caricatore automatico determina se un file è stato inserito o meno?

Il caricatore automatico inserisce normalmente ogni file una sola volta in base al percorso del file. Tuttavia, se si imposta l'opzione allowOverwrites su true, Il caricatore automatico usa anche il timestamp dell'ultima modifica del file per determinare se un file è nuovo o è stato aggiornato e deve essere reinserito. Vedere Il caricatore automatico elabora nuovamente il file quando il file viene accodato o sovrascritto?

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.

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 dei risultati delle 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 nell'inserimento dei dati quando si utilizza l'inferenza dello schema con 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 dovresti notare cali significativi nelle prestazioni 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.

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 un servizio 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. Consultare Gestire le code di notifica dei file per ogni flusso dell’Auto Loader separatamente (versione classica).

Se gli eventi di file sono abilitati nel percorso esterno in Unity Catalog, il servizio eventi file può creare gli eventi di file nel fornitore di servizi cloud, così non è necessario configurare Auto Loader per crearli per ogni flusso. Consulta Usare la modalità di notifica file con gli eventi di file

È 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 tua directory di input non entri in conflitto con il prefisso di notifica esistente (ad esempio, le suddette directory padre-figlio).

È possibile condividere una coda SQS tra il caricatore automatico e altre applicazioni?

Databricks non consiglia di condividere una coda SQS tra il caricatore automatico e altre applicazioni. In alternativa, inoltra le notifiche di eventi S3 ad un topic SNS, poi sottoscrivi a tale topic una coda SQS separata per ogni applicazione. Usare un criterio di filtro delle sottoscrizioni SNS per assicurarsi che solo i messaggi pertinenti vengano inoltrati a ogni coda. Fornire quindi la coda dedicata a Auto Loader.

Come si verifica che gli eventi di file siano configurati correttamente?

Fare clic sul pulsante Test connessione nella pagina della posizione esterna. Se si configurano correttamente gli eventi dei file, vedrai un segno di spunta verde per l'elemento Lettura eventi dei file. Se hai appena creato il percorso esterno e abilitato gli eventi dei file in modalità Automatic, il test mostra Skipped mentre Azure Databricks configura le notifiche per il percorso esterno. Attendere alcuni minuti, quindi fare di nuovo clic su Test connessione . Se Azure Databricks non dispone delle autorizzazioni necessarie per configurare o leggere dagli eventi di file, verrà visualizzato un errore per l'elemento File Events Read.

È possibile evitare un elenco di directory completo durante l'esecuzione iniziale?

No Anche se includeExistingFiles è impostato su false, il caricatore automatico esegue un elenco di directory per individuare i file creati dopo l'avvio del flusso e sincronizzarsi con la cache degli eventi dei file (per assicurare una posizione di lettura valida nella cache e archiviarla nel checkpoint del flusso).

È necessario impostare cloudFiles.backfillInterval per evitare file mancanti?

No Azure Databricks ha consigliato in precedenza questa impostazione per modalità di notifica file classica perché i sistemi di notifiche di archiviazione cloud potrebbero provocare file mancanti o in ritardo. Azure Databricks esegue ora elenchi di directory completi nella posizione esterna. Il primo elenco completo della directory inizia non appena gli eventi relativi ai file vengono abilitati nella posizione esterna. Ogni successivo elenco avviene 24 ore dopo l'ultima scansione completa, purché vi sia almeno un flusso Auto Loader che utilizza eventi di file per acquisire i dati.

Ho configurato gli eventi di file con una coda di archiviazione fornita, ma la coda non è stata configurata correttamente e ho perso i file. Come è possibile assicurarsi che il caricatore automatico inserisca i file mancanti quando la coda è stata configurata in modo errato?

Prima di tutto, verifica che l'errata configurazione della coda sia risolta. Per verificare, fare clic sul pulsante Test Connessione nella pagina della posizione esterna. Se si configurano correttamente gli eventi di file, viene visualizzato un segno di spunta verde per l'elemento Leggi eventi file .

Azure Databricks esegue un elenco di directory completo per percorsi esterni con eventi dei file abilitati. Questo elenco di directory individua tutti i file che non sono stati rilevati durante il periodo di configurazione errata e li archivia nella cache degli eventi di file.

Dopo la correzione della configurazione errata e Azure Databricks completa l'elenco di directory, Il caricatore automatico continua a leggere dalla cache degli eventi di file e inserisce automaticamente eventuali file mancanti durante il periodo di configurazione errata.

Come si esegue il ripristino da un CF_MANAGED_FILE_EVENTS_INVALID_CONTINUATION_TOKEN errore?

Questo errore si verifica quando il token di continuazione archiviato nel checkpoint del caricatore automatico per il servizio eventi file non è valido.

Alcune cause comuni:

• cloudFiles.useManagedFileEvents è stato disattivato e poi riacceso.
• Modifica della posizione o del volume esterno della fonte.
• Modifica della coda fornita.

Per ripristinare:

1. Imposta .option("cloudFiles.listOnStart", "true") e .option("cloudFiles.validateOptions", false) nella tua query di streaming.
2. Riavvia lo streaming Auto Loader esegue un elenco di directory completo all'avvio e ignora il token di continuazione non valido.
3. Dopo un micro batch riuscito, rimuovere entrambe le opzioni e riavviare il flusso.

Per altre informazioni sull'opzione cloudFiles.listOnStart , vedere Notifica file.

Come posso pulire le risorse di notifica degli eventi create da Auto Loader?

È possibile usare il 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.