Introduzione ai trasferimenti dell'archiviazione BLOB

BigQuery Data Transfer Service per l'archiviazione BLOB di Azure consente di pianificare e gestire automaticamente i job di caricamento ricorrenti dall'archiviazione BLOB di Azure e da Azure Data Lake Storage Gen2 a BigQuery.

Formati di file supportati

BigQuery Data Transfer Service attualmente supporta il caricamento di dati da Archiviazione BLOB 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 l'archiviazione BLOB supporta il caricamento dei dati compressi. I tipi di compressione supportati da BigQuery Data Transfer Service sono gli stessi di quelli supportati dai job di caricamento BigQuery. Per maggiori informazioni, consulta Caricare dati compressi e non compressi.

Prerequisiti per il trasferimento

Per caricare i dati da un'origine dati Archiviazione BLOB, raccogli prima quanto segue:

• Il nome dell'account Archiviazione BLOB, il nome del container e il percorso dei dati (facoltativo) per i dati di origine. Il campo Percorso dati è facoltativo; viene utilizzato per trovare corrispondenze con prefissi degli oggetti comuni e estensioni dei file. 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.

Parametrizzazione del runtime di trasferimento

Il percorso dati di Archiviazione BLOB e la tabella di destinazione possono essere entrambi parametrizzati, in modo da caricare i dati dai 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.

Importazione dati per i trasferimenti di BLOB di Azure

Puoi specificare in che modo vengono caricati i dati in BigQuery selezionando una Preferenza di scrittura nella configurazione di trasferimento quando configuri un trasferimento BLOB di Azure.

Sono disponibili due tipi di preferenze di scrittura: trasferimenti incrementali e trasferimenti troncati.

Trasferimenti incrementali

Una configurazione di trasferimento con una preferenza di scrittura APPEND o WRITE_APPEND, chiamata anche trasferimento incrementale, aggiunge in modo incrementale nuovi dati dopo il precedente trasferimento riuscito a una tabella di destinazione BigQuery. Quando una configurazione di trasferimento viene eseguita con una preferenza di scrittura APPEND, BigQuery Data Transfer Service filtra i file che sono stati modificati dopo l'esecuzione precedente del trasferimento riuscito. Per determinare quando un file viene modificato, BigQuery Data Transfer Service esamina i metadati del file per trovare una proprietà "Ora dell'ultima modifica". Ad esempio, BigQuery Data Transfer Service esamina la proprietà timestamp updated in un file Cloud Storage. Se BigQuery Data Transfer Service trova file con "ora dell'ultima modifica", che si sono verificati dopo il timestamp dell'ultimo trasferimento riuscito, BigQuery Data Transfer Service trasferisce questi file in un trasferimento incrementale.

Per dimostrare come funzionano i trasferimenti incrementali, considera l'esempio di trasferimento in Cloud Storage. Un utente crea un file in un bucket Cloud Storage alle ore 01-07-2023T00:00Z denominato file_1. Il timestamp updated per file_1 indica 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 01-07-2023T03:00Z.

• Il 01-07-2023T03:00Z inizia la prima esecuzione di trasferimento. Poiché questa è la prima esecuzione di trasferimento per questa configurazione, BigQuery Data Transfer Service tenta di caricare tutti i file corrispondenti all'URI di origine nella tabella BigQuery di destinazione. L'esecuzione del trasferimento riesce e BigQuery Data Transfer Service carica correttamente file_1 nella tabella BigQuery di destinazione.
• La successiva esecuzione di trasferimento, alle ore 2023-07-02T03:00Z, non rileva file in cui la proprietà timestamp updated è maggiore dell'ultima esecuzione di trasferimento riuscita (01-07-2023T03:00Z). Il trasferimento viene eseguito senza caricare altri dati nella tabella BigQuery di destinazione.

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

Seguendo lo stesso esempio, supponiamo che l'utente crei quindi un altro file nel bucket Cloud Storage alle ore 2023-07-03T00:00Z, denominato file_2. Il timestamp updated per file_2 indica l'ora in cui è stato creato il file.

• La successiva esecuzione di trasferimento, alle 2023-07-03T03:00Z, rileva che file_2 ha un timestamp updated maggiore rispetto all'ultima esecuzione di trasferimento riuscita (01-07-2023T03:00Z). Supponiamo che all'avvio del trasferimento l'esecuzione non vada a buon fine a causa di un errore temporaneo. In questo scenario, file_2 non viene caricato nella tabella BigQuery di destinazione. Il timestamp dell'ultima esecuzione di un trasferimento riuscito rimane 2023-07-01T03:00Z.
• La successiva esecuzione di trasferimento, alle 2023-07-04T03:00Z, rileva che file_2 ha un timestamp updated maggiore rispetto all'ultima esecuzione di trasferimento riuscita (01-07-2023T03:00Z). Questa volta, l'esecuzione del trasferimento viene completata senza problemi, quindi carica correttamente file_2 nella tabella BigQuery di destinazione.
• La successiva esecuzione di trasferimento, alle 2023-07-05T03:00Z, non rileva file in cui il timestamp di updated è maggiore dell'ultima esecuzione di trasferimento riuscita (04-07-2023T03:00Z). L'esecuzione del trasferimento va a buon fine senza caricare altri dati nella tabella BigQuery di destinazione.

L'esempio precedente mostra che quando un trasferimento non va a buon fine, nessun file viene trasferito nella tabella di destinazione BigQuery. Eventuali modifiche ai file vengono trasferite alla successiva esecuzione di trasferimento riuscita. Eventuali trasferimenti successivi riusciti a seguito di un trasferimento non riuscito non causano dati duplicati. Nel caso di un trasferimento non riuscito, puoi anche scegliere di attivare manualmente un trasferimento al di fuori del suo orario pianificato regolarmente.

Avviso: BigQuery Data Transfer Service si basa sulla proprietà "Ora dell'ultima modifica" in ogni file di origine per determinare quali file trasferire, come mostrato negli esempi di trasferimenti incrementali. In seguito alla modifica di queste proprietà, il trasferimento può saltare alcuni file o caricare lo stesso file più volte. Questa proprietà può avere nomi diversi in ogni sistema di archiviazione supportato da BigQuery Data Transfer Service. Ad esempio, gli oggetti Cloud Storage chiamano questa proprietà updated.

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 l'esecuzione di ogni trasferimento con i dati di tutti i file corrispondenti all'URI di origine. MIRROR sovrascrive una nuova copia dei dati nella tabella di destinazione. Se la tabella di destinazione utilizza un decoratore delle partizioni, l'esecuzione del trasferimento sovrascrive solo i dati nella partizione specificata. Una tabella di destinazione con un decorator 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 dati duplicati. Tuttavia, se esegui più configurazioni di trasferimento diverse che interessano la stessa tabella di destinazione BigQuery, ciò può causare la duplicazione dei dati da parte di BigQuery Data Transfer Service.

Supporto dei caratteri jolly per il percorso dei dati di Archiviazione BLOB

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

Anche se nel percorso dei dati possono essere utilizzati più caratteri jolly, è possibile apportare alcune ottimizzazioni quando viene utilizzato un solo carattere jolly:

• È previsto un limite più elevato per il numero massimo di file per esecuzione di trasferimento.
• Il carattere jolly estenderà i limiti della directory. Ad esempio, il percorso dati my-folder/*.csv corrisponderà al file my-folder/my-subfolder/my-file.csv.

Esempi di percorsi dati di archiviazione BLOB

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

Esempio: file singolo

Per caricare un singolo file da Archiviazione BLOB in BigQuery, specifica il nome file di Archiviazione BLOB:

my-folder/my-file.csv

Esempio: Tutti i file

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

*

Esempio: file con un prefisso comune

Per caricare da Archiviazione BLOB tutti i file 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 Archiviazione BLOB con un percorso simile, specifica il prefisso e il suffisso comuni:

my-folder/*.csv

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

Esempio: carattere jolly alla fine del percorso

Considera il seguente percorso dei dati:

logs/*

Sono 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

Sono selezionati tutti i seguenti file:

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

E nessuno dei seguenti file è selezionato:

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

Esempio: più caratteri jolly

L'utilizzo di più caratteri jolly, offre un maggiore controllo sulla selezione dei file, a scapito di limiti inferiori. Quando utilizzi più caratteri jolly, ogni singolo carattere jolly copre solo 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 è selezionato:

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

Firma di accesso condiviso

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

1. Crea o utilizza un utente di Archiviazione BLOB esistente per accedere all'account di archiviazione del container Archiviazione BLOB.

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

   1. In Servizi consentiti, seleziona Blob.
   2. Per Tipi di risorse consentiti, seleziona sia Container che Object.
   3. In Autorizzazioni consentite, seleziona Lettura ed Elenco.
   4. La scadenza predefinita per i token SAS è di 8 ore. Imposta una scadenza in linea con il tuo piano di trasferimento.
   5. Non specificare alcun indirizzo IP nel campo Indirizzi IP consentiti.
   6. Per Protocolli consentiti, seleziona Solo HTTPS.

   

3. Dopo la creazione del token SAS, prendi nota del valore del token SAS che viene restituito. Questo valore è necessario quando configuri i trasferimenti.

Limitazioni IP

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

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

Considerazioni sulla coerenza

Dopo l'aggiunta al container Archiviazione BLOB, un file dovrebbe richiedere circa 10 minuti per essere disponibile in BigQuery Data Transfer Service.

Importante: per ridurre la possibilità di perdere dati, pianifica i trasferimenti dell'archiviazione BLOB in modo che vengano eseguiti almeno 10 minuti dopo l'aggiunta dei file al container.

Best practice per il controllo dei costi del traffico in uscita

I trasferimenti dall'archiviazione BLOB potrebbero non riuscire se la tabella di destinazione non è configurata correttamente. Le possibili cause di una configurazione non corretta sono le seguenti:

• 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 aggiuntivi per il traffico in uscita di Archiviazione BLOB, prova innanzitutto un trasferimento con un sottoinsieme di file piccolo ma rappresentativo. Assicurati che il test sia ridotto sia per la dimensione dei dati che per il numero di file.

Inoltre, è importante notare che la corrispondenza dei prefissi per i percorsi dei dati avviene prima del trasferimento dei file da Archiviazione BLOB, ma la corrispondenza dei caratteri jolly avviene in Google Cloud. Questa distinzione potrebbe aumentare i costi del traffico in uscita da Blob Storage per i file trasferiti in Google Cloud ma non caricati in BigQuery.

Considera ad esempio questo percorso dati:

folder/*/subfolder/*.csv

Entrambi i seguenti file vengono trasferiti in Google Cloud perché 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 ulteriori informazioni, consulta i prezzi di BigQuery Data Transfer Service.

L'utilizzo di questo servizio può anche comportare costi esterni a Google. Per maggiori informazioni, consulta i prezzi di Storage BLOB.

Quote e limiti

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

Limite	Predefinita
Dimensione massima per esecuzione di trasferimento del job di caricamento	15 TB
Numero massimo di file per esecuzione di trasferimento quando il percorso dei dati di Archiviazione BLOB include 0 o 1 caratteri jolly	10.000.000 file
Numero massimo di file per esecuzione di trasferimento quando il percorso dei dati di Archiviazione BLOB include 2 o più caratteri jolly	10.000 file

Passaggi successivi

• Scopri di più sulla configurazione di un trasferimento dello spazio di archiviazione BLOB.
• Scopri di più sui parametri di runtime nei trasferimenti.
• Scopri di più su BigQuery Data Transfer Service.