Introduzione ai trasferimenti da Blob Storage

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 BigQuery. Per maggiori informazioni, vedi Caricamento di 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 Percorso dati è facoltativo e viene utilizzato per corrispondere a prefissi di oggetti ed estensioni di 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 informazioni dettagliate sulla creazione di un token SAS, vedi Firma di accesso condiviso (SAS).

Parametrizzazione del runtime di trasferimento

Sia il percorso dei dati di Archiviazione blob 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, vedi Parametri di runtime nei trasferimenti.

Importazione 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.

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 all'ultima tabella di destinazione BigQuery trasferita correttamente. Quando una configurazione di trasferimento viene eseguita 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à "Ora 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 un "orario dell'ultima modifica" successivo 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 timestamp updated per file_1 è l'ora in cui è stato creato il file. L'utente quindi crea un trasferimento incrementale dal bucket Cloud Storage, pianificato per essere eseguito una volta al giorno alle ore 03:00 UTC, a partire dal 1° luglio 2023 alle ore 03:00 UTC.

• Il primo aggiornamento del trasferimento inizia il giorno 2023-07-01T03:00Z. Poiché si tratta della prima esecuzione del 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 va a buon fine e BigQuery Data Transfer Service carica correttamente file_1 nella tabella BigQuery di destinazione.
• La successiva esecuzione del trasferimento, il giorno 02/07/2023 alle ore 03:00 UTC, non rileva file in cui la proprietà timestamp updated è maggiore dell'ultima esecuzione del trasferimento riuscita (01/07/2023 alle ore 03:00 UTC). L'esecuzione del trasferimento va a buon fine senza caricare dati aggiuntivi 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 trasferire queste modifiche, se sono state rilevate.

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

• La successiva esecuzione del trasferimento, il giorno 03-07-2023 alle ore 03:00 UTC, rileva che file_2 ha un timestamp updated successivo all'ultima esecuzione del trasferimento riuscita (01-07-2023 alle ore 03:00 UTC). 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 riuscito rimane 2023-07-01T03:00Z.
• La successiva esecuzione del trasferimento, il giorno 04-07-2023 alle ore 03:00 UTC, rileva che file_2 ha un timestamp updated successivo all'ultima esecuzione del trasferimento riuscita (01-07-2023 alle ore 03:00 UTC). 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 ore 03:00 del 5 luglio 2023, non rileva file in cui il timestamp updated è maggiore dell'ultima esecuzione del trasferimento riuscita (alle ore 03:00 del 4 luglio 2023). L'esecuzione del trasferimento ha esito positivo senza caricare dati aggiuntivi nella tabella BigQuery di destinazione.

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

Avviso :BigQuery Data Transfer Service si basa sulla proprietà "Ora ultima modifica" di ogni file di origine per determinare quali file trasferire, come mostrato negli esempi di trasferimento incrementale. La modifica di queste proprietà può causare l'omissione di determinati file durante il trasferimento o il caricamento dello 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 ogni esecuzione del 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 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 dati duplicati. 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.

Sebbene sia possibile utilizzare più di un carattere jolly nel percorso dei dati, è possibile eseguire alcune ottimizzazioni quando viene utilizzato un solo carattere jolly:

• Esiste un limite più elevato per il numero massimo di file per esecuzione del trasferimento.
• Il carattere jolly si estenderà ai limiti della directory. Ad esempio, il percorso 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 dei 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 Blob Storage:

my-folder/my-file.csv

Esempio: tutti i file

Per caricare tutti i file da un contenitore 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/*

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

Inoltre, non è selezionato nessuno dei seguenti file:

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

Esempio: più caratteri jolly

Utilizzando più caratteri jolly, ottieni 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

Sono selezionati entrambi i seguenti file:

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

Inoltre, non è selezionato nessuno dei seguenti file:

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

Firma di accesso condiviso

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 tuo container Blob Storage.

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

   1. Per Servizi consentiti, seleziona Blob.
   2. Per Tipi di risorse consentiti, seleziona sia Contenitore che Oggetto.
   3. Per Autorizzazioni consentite, seleziona Lettura ed Elenco.
   4. Il tempo di scadenza predefinito per i token SAS è di 8 ore. Imposta una scadenza adatta alla tua pianificazione dei trasferimenti.
   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 SAS token restituito. Questo valore ti servirà per configurare i trasferimenti.

Limitazioni IP

Se limiti l'accesso alle tue risorse Azure utilizzando un firewall 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, vedi Limitazioni IP.

Considerazioni sulla coerenza

Serviranno circa 5 minuti prima che un file diventi disponibile per BigQuery Data Transfer Service dopo essere stato aggiunto al contenitore Blob Storage.

Importante :per ridurre la possibilità di perdere dati, pianifica i trasferimenti di Blob Storage in modo che avvengano almeno 5 minuti dopo l'aggiunta dei file al contenitore.

Best practice per il controllo dei costi di 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 di Blob Storage aggiuntivi, 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 che di numero di file.

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

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, in BigQuery viene caricato solo il file folder/any/subfolder/file1.csv, perché corrisponde al percorso completo dei dati.

Prezzi

Per ulteriori informazioni, vedi Prezzi di BigQuery Data Transfer Service.

Inoltre, utilizzando questo servizio potresti incorrere in costi esterni a 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 sui job di caricamento si applicano ai trasferimenti ricorrenti di Blob Storage, con le seguenti considerazioni aggiuntive:

Limite	Predefinito
Dimensione massima per esecuzione del trasferimento del job di caricamento	15 TB
Numero massimo di file per esecuzione del trasferimento quando il percorso dati di Blob Storage include 0 o 1 caratteri jolly	10.000.000 di file
Numero massimo di file per esecuzione del trasferimento quando il percorso dei dati di Blob Storage include due o più caratteri jolly	10.000 file

Passaggi successivi

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