Introduzione ai trasferimenti di dati da Blob Storage

Il BigQuery Data Transfer Service per Azure Blob Storage consente di pianificare e gestire automaticamente i job di caricamento ricorrenti da Azure Blob Storage e Azure Data Lake Storage Gen2 in BigQuery.

Formati di file supportati

BigQuery Data Transfer Service supporta il caricamento di dati da Blob Storage nei seguenti formati:

• Valori separati da virgola (CSV)
• JSON (delimitato da nuova riga)
• Avro
• Parquet
• ORC

Tipi di compressione supportati

BigQuery Data Transfer Service per Blob Storage supporta il caricamento di dati compressi. I tipi di compressione supportati da BigQuery Data Transfer Service sono gli stessi dei tipi di compressione supportati dai job di caricamento di BigQuery. Per saperne di più, consulta Caricare dati compressi e non compressi.

Prerequisiti per il trasferimento

Per caricare i dati da un'origine dati Blob Storage, raccogli prima quanto segue:

• Il nome dell'account Blob Storage, il nome del container e il percorso dei dati (facoltativo) per i dati di origine. Il campo del percorso dei dati è facoltativo; viene utilizzato per trovare i prefissi degli oggetti e le estensioni dei file comuni. Se il percorso dei dati viene omesso, vengono trasferiti tutti i file nel container.
• Un token di firma di accesso condiviso (SAS) di Azure che concede l'accesso in lettura all'origine dati. Per maggiori dettagli sulla creazione di un token SAS, consulta Firma di accesso condiviso (SAS).

Parametrizzazione del runtime di trasferimento

Sia il percorso dei dati di Blob Storage sia la tabella di destinazione possono essere parametrizzati, consentendoti di caricare i dati da container organizzati per data. I parametri utilizzati dai trasferimenti di Blob Storage sono gli stessi utilizzati dai trasferimenti di Cloud Storage. Per maggiori dettagli, consulta Parametri di runtime nei trasferimenti.

Acquisizione dei dati per i trasferimenti Azure Blob

Puoi specificare come caricare i dati in BigQuery selezionando una preferenza di scrittura nella configurazione del trasferimento quando configuri un trasferimento Azure Blob.

Trasferimenti incrementali

Una configurazione del trasferimento con una preferenza di scrittura APPEND o WRITE_APPEND, chiamata anche trasferimento incrementale, aggiunge in modo incrementale i nuovi dati a una tabella di destinazione BigQuery dall'ultimo trasferimento riuscito. Quando viene eseguita una configurazione del trasferimento con una preferenza di scrittura APPEND , BigQuery Data Transfer Service filtra i file modificati dall'ultima esecuzione del trasferimento riuscita. Per determinare quando un file viene modificato, BigQuery Data Transfer Service esamina i metadati del file per una proprietà "last modified time" (ora dell'ultima modifica). Ad esempio, BigQuery Data Transfer Service esamina la proprietà del timestamp updated in un file di Cloud Storage. Se BigQuery Data Transfer Service trova file con un'ora dell'ultima modifica successiva al timestamp dell'ultimo trasferimento riuscito, li trasferisce in un trasferimento incrementale.

Per mostrare come funzionano i trasferimenti incrementali, considera il seguente esempio di trasferimento di Cloud Storage. Un utente crea un file in un bucket Cloud Storage all'ora 2023-07-01T00:00Z denominato file_1. Il updated timestamp per file_1 è l'ora in cui è stato creato il file. L'utente crea quindi un trasferimento incrementale dal bucket Cloud Storage, pianificato per essere eseguito una volta al giorno alle 03:00Z, a partire dal 2023-07-01T03:00Z.

• Alle 03:00Z del 1° luglio 2023 inizia la prima esecuzione del trasferimento. Poiché si tratta della prima esecuzione del trasferimento per questa configurazione, BigQuery Data Transfer Service tenta di caricare tutti i file che corrispondono all'URI di origine nella tabella BigQuery di destinazione. L'esecuzione del trasferimento è riuscita e BigQuery Data Transfer Service ha caricato correttamente file_1 nella tabella BigQuery di destinazione.
• La successiva esecuzione del trasferimento, alle 03:00Z del 2 luglio 2023, non rileva file in cui la proprietà del timestamp updated è maggiore dell'ultima esecuzione del trasferimento riuscita (03:00Z del 1° luglio 2023). L'esecuzione del trasferimento è riuscita senza caricare altri dati nella tabella BigQuery di destinazione.

L'esempio precedente mostra come BigQuery Data Transfer Service esamina la proprietà del timestamp updated del file di origine per determinare se sono state apportate modifiche ai file di origine e per trasferirle, se ne sono state rilevate.

Seguendo lo stesso esempio, supponiamo che l'utente crei un altro file nel bucket Cloud Storage alle 00:00Z del 3 luglio 2023, denominato file_2. Il updated timestamp per file_2 è l'ora in cui è stato creato il file.

• La successiva esecuzione del trasferimento, alle 03:00Z del 3 luglio 2023, rileva che file_2 ha un timestamp updated maggiore dell'ultima esecuzione del trasferimento riuscita (03:00Z del 1° luglio 2023). Supponiamo che all'avvio dell'esecuzione del trasferimento si verifichi un errore temporaneo. In questo scenario, file_2 non viene caricato nella tabella BigQuery di destinazione. Il timestamp dell'ultima esecuzione del trasferimento riuscita rimane alle 03:00Z del 1° luglio 2023.
• La successiva esecuzione del trasferimento, alle 03:00Z del 4 luglio 2023, rileva che file_2 ha un timestamp updated maggiore dell'ultima esecuzione del trasferimento riuscita (03:00Z del 1° luglio 2023). Questa volta, l'esecuzione del trasferimento viene completata senza problemi, quindi file_2 viene caricato correttamente nella tabella BigQuery di destinazione.
• La successiva esecuzione del trasferimento, alle 03:00Z del 5 luglio 2023, non rileva file in cui il timestamp updated è maggiore dell'ultima esecuzione del trasferimento riuscita (03:00Z del 4 luglio 2023). L'esecuzione del trasferimento è riuscita senza caricare altri dati nella tabella BigQuery di destinazione.

L'esempio precedente mostra che, quando un trasferimento non riesce, non vengono trasferiti file alla tabella di destinazione BigQuery. Le modifiche ai file vengono trasferite alla successiva esecuzione del trasferimento riuscita. I trasferimenti riusciti successivi a un trasferimento non riuscito non causano la duplicazione dei dati. In caso di trasferimento non riuscito, puoi anche scegliere di attivare manualmente un trasferimento al di fuori dell'orario pianificato.

Trasferimenti troncati

Una configurazione di trasferimento con una preferenza di scrittura MIRROR o WRITE_TRUNCATE, chiamata anche trasferimento troncato, sovrascrive i dati nella tabella di destinazione BigQuery durante ogni esecuzione del trasferimento con i dati di tutti i file che corrispondono all'URI di origine. MIRROR sovrascrive una nuova copia dei dati nella tabella di destinazione. Se la tabella di destinazione utilizza un decoratore di partizione, l'esecuzione del trasferimento sovrascrive solo i dati nella partizione specificata. Una tabella di destinazione con un decoratore di partizione ha il formato my_table${run_date}, ad esempio my_table$20230809.

La ripetizione degli stessi trasferimenti incrementali o troncati in un giorno non causa la duplicazione dei dati. Tuttavia, se esegui più configurazioni di trasferimento diverse che interessano la stessa tabella di destinazione BigQuery, BigQuery Data Transfer Service potrebbe duplicare i dati.

Supporto dei caratteri jolly per il percorso dei dati di Blob Storage

Puoi selezionare i dati di origine suddivisi in più file specificando uno o più caratteri jolly asterisco (*) nel percorso dei dati.

Anche se è possibile utilizzare più caratteri jolly nel percorso dei dati, è possibile eseguire alcune ottimizzazioni quando viene utilizzato un solo carattere jolly:

• Esiste un limite più elevato al numero massimo di file per esecuzione del trasferimento.
• Il carattere jolly si estenderà ai limiti delle directory. Ad esempio, il percorso dei dati my-folder/*.csv corrisponderà al file my-folder/my-subfolder/my-file.csv.

Esempi di percorsi dei dati di Blob Storage

Di seguito sono riportati esempi di percorsi di dati validi per un trasferimento di Blob Storage. Tieni presente che i percorsi dei dati non iniziano con /.

Esempio: singolo file

Per caricare un singolo file da Blob Storage in BigQuery, specifica il nome del file di Blob Storage:

my-folder/my-file.csv

Esempio: tutti i file

Per caricare tutti i file da un container Blob Storage in BigQuery, imposta il percorso dei dati su un singolo carattere jolly:

*

Esempio: file con un prefisso comune

Per caricare tutti i file da Blob Storage che condividono un prefisso comune, specifica il prefisso comune con o senza un carattere jolly:

my-folder/

o

my-folder/*

Esempio: file con un percorso simile

Per caricare tutti i file da Blob Storage con un percorso simile, specifica il prefisso e il suffisso comuni:

my-folder/*.csv

Quando utilizzi un solo carattere jolly, questo si estende alle directory. In questo esempio, vengono selezionati tutti i file CSV in my-folder, nonché tutti i file CSV in ogni sottocartella di my-folder.

Esempio: carattere jolly alla fine del percorso

Considera il seguente percorso dei dati:

logs/*

Vengono selezionati tutti i seguenti file:

logs/logs.csv
logs/system/logs.csv
logs/some-application/system_logs.log
logs/logs_2019_12_12.csv

Esempio: carattere jolly all'inizio del percorso

Considera il seguente percorso dei dati:

*logs.csv

Vengono selezionati tutti i seguenti file:

logs.csv
system/logs.csv
some-application/logs.csv

E nessuno dei seguenti file viene selezionato:

metadata.csv
system/users.csv
some-application/output.csv

Esempio: più caratteri jolly

Utilizzando più caratteri jolly, hai un maggiore controllo sulla selezione dei file, a scapito di limiti inferiori. Quando utilizzi più caratteri jolly, ogni singolo carattere jolly si estende solo a una singola sottodirectory.

Considera il seguente percorso dei dati:

*/*.csv

Vengono selezionati entrambi i seguenti file:

my-folder1/my-file1.csv
my-other-folder2/my-file2.csv

E nessuno dei seguenti file viene selezionato:

my-folder1/my-subfolder/my-file3.csv
my-other-folder2/my-subfolder/my-file4.csv

Firma di accesso condiviso (SAS)

Il token SAS di Azure viene utilizzato per accedere ai dati di Blob Storage per tuo conto. Per creare un token SAS per il trasferimento:

1. Crea o utilizza un utente Blob Storage esistente per accedere all'account di archiviazione per il container Blob Storage.

2. Crea un token SAS a livello di account di archiviazione. Per creare un token SAS utilizzando il portale di Azure:

   1. In Servizi consentiti, seleziona Blob.
   2. In Tipi di risorse consentiti, seleziona sia Container sia Oggetto.
   3. In Autorizzazioni consentite, seleziona Lettura ed Elenco.
   4. Il tempo di scadenza predefinito per i token SAS è di 8 ore. Imposta un tempo di scadenza adatto alla pianificazione del trasferimento.
   5. Non specificare indirizzi IP nel campo Indirizzi IP consentiti.
   6. In Protocolli consentiti, seleziona Solo HTTPS.

   

3. Dopo aver creato il token SAS, prendi nota del valore del token SAS restituito. Questo valore è necessario quando configuri i trasferimenti.

Limitazioni IP

Se limiti l'accesso alle risorse di Azure utilizzando un firewall di Azure Storage, devi aggiungere gli intervalli IP utilizzati dai worker di BigQuery Data Transfer Service all'elenco degli IP consentiti.

Per aggiungere intervalli IP come IP consentiti ai firewall di Azure Storage, consulta Limitazioni IP.

Considerazioni sulla coerenza

Dopo l'aggiunta al container Blob Storage, un file dovrebbe essere disponibile per BigQuery Data Transfer Service in circa 5 minuti.

Best practice per il controllo dei costi in uscita

I trasferimenti da Blob Storage potrebbero non riuscire se la tabella di destinazione non è configurata correttamente. Le possibili cause di una configurazione errata includono:

• La tabella di destinazione non esiste.
• Lo schema della tabella non è definito.
• Lo schema della tabella non è compatibile con i dati trasferiti.

Per evitare costi di uscita aggiuntivi da Blob Storage, testa prima un trasferimento con un sottoinsieme di file piccolo ma rappresentativo. Assicurati che questo test sia piccolo sia in termini di dimensioni dei dati sia di numero di file.

È anche importante notare che la corrispondenza dei prefissi per i percorsi dei dati avviene prima del trasferimento dei file da Blob Storage, mentre la corrispondenza dei caratteri jolly avviene all'interno Google Cloud. Questa distinzione potrebbe aumentare i costi di uscita di Blob Storage per i file trasferiti a Google Cloud BigQuery ma non caricati.

Ad esempio, considera questo percorso dei dati:

folder/*/subfolder/*.csv

Entrambi i seguenti file vengono trasferiti a Google Cloudperché hanno il prefisso folder/:

folder/any/subfolder/file1.csv
folder/file2.csv

Tuttavia, solo il file folder/any/subfolder/file1.csv viene caricato in BigQuery perché corrisponde al percorso dei dati completo.

Prezzi

Per maggiori informazioni, consulta Prezzi di BigQuery Data Transfer Service.

L'utilizzo di questo servizio può comportare costi al di fuori di Google. Per maggiori informazioni, consulta Prezzi di Blob Storage.

Quote e limiti

BigQuery Data Transfer Service utilizza i job di caricamento per caricare i dati di Blob Storage in BigQuery. Tutte le quote e i limiti di BigQuery per i job di caricamento si applicano ai trasferimenti ricorrenti di Blob Storage, con le seguenti considerazioni aggiuntive:

Passaggi successivi

• Scopri di più sulla configurazione di un trasferimento di Blob Storage.
• Scopri di più sui parametri di runtime nei trasferimenti.
• Scopri di più su BigQuery Data Transfer Service.