Introduzione ai trasferimenti dell'archiviazione BLOB
BigQuery Data Transfer Service per Archiviazione BLOB di Azure 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 attualmente supporta il caricamento dei 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 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 di BigQuery. Per maggiori informazioni, consulta la pagina Caricare dati compressi e non compressi.
Prerequisiti per il trasferimento
Per caricare i dati da un'origine dati per l'archiviazione BLOB, raccogli innanzitutto quanto segue:
- Il nome dell'account Archiviazione BLOB, il nome del container e il percorso dei dati (facoltativo) dei dati di origine. Il campo del percorso dei dati è facoltativo ed è utilizzato per abbinare prefissi di oggetti comuni e le estensioni dei file. Se il percorso dei dati viene omesso, tutti i file nel container vengono trasferiti.
- Un token della 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
È possibile parametrizzare sia il percorso dati di Archiviazione BLOB che la tabella di destinazione, in modo da caricare i dati dai container organizzati per data. I parametri utilizzati dai trasferimenti dell'archiviazione BLOB sono gli stessi utilizzati dai trasferimenti di Cloud Storage. Per maggiori dettagli, consulta Parametri di runtime nei trasferimenti.
Importazione dati per trasferimenti BLOB di Azure
Puoi specificare la modalità di caricamento dei 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 poiché il precedente trasferimento è andato a buon fine 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 del trasferimento precedente. Per determinare quando un file viene modificato, BigQuery Data Transfer Service esamina i metadati del file per 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 l'"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 il seguente esempio di trasferimento in Cloud Storage. Un utente crea un file in un bucket Cloud Storage all'indirizzo 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 l'esecuzione una volta al giorno alle 03:00 Z, a partire dal 01/07/2023T03:00Z.
- Il giorno 01/07/2023T03:00Z inizia il primo 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 ha esito positivo e BigQuery Data Transfer Service carica correttamente
file_1
nella tabella BigQuery di destinazione. - La prossima esecuzione del trasferimento, il 02/07/2023T03:00Z, non rileva nessun file in cui la proprietà timestamp
updated
è maggiore dell'ultima esecuzione di trasferimento riuscita (01/07/2023T03:00Z). L'esecuzione del trasferimento ha esito positivo senza caricare altri dati nella tabella BigQuery di destinazione.
L'esempio precedente mostra come BigQuery Data Transfer Service considera la proprietà del timestamp updated
del file di origine per determinare se sono state apportate modifiche ai file di origine e per trasferire queste eventuali modifiche rilevate.
Seguendo lo stesso esempio, supponiamo che l'utente crei un altro file denominato file_2
nel bucket Cloud Storage all'ora 2023-07-03T00:00Z. Il timestamp updated
per file_2
indica l'ora in cui è stato creato il file.
- L'esecuzione successiva del trasferimento, il 03/07/2023T03:00Z, rileva che il timestamp
updated
difile_2
è maggiore dell'ultima esecuzione del trasferimento riuscita (01/07/2023T03:00Z). Supponiamo che l'avvio del trasferimento non vada a buon fine a causa di un errore temporaneo. In questo scenario,file_2
non viene caricato nella tabella BigQuery di destinazione. L'ultimo timestamp eseguito correttamente per l'esecuzione del trasferimento rimane al 01-07-2023T03:00Z. - La prossima esecuzione del trasferimento, il 04/07/2023T03:00Z, rileva che il timestamp
updated
difile_2
è maggiore dell'ultima esecuzione del trasferimento riuscita (01/07/2023T03:00Z). Questa volta, l'esecuzione del trasferimento viene completata senza problemi, quindi viene caricato correttamentefile_2
nella tabella BigQuery di destinazione. - La prossima esecuzione del trasferimento, il 05/07/2023T03:00Z, non rileva nessun file il cui timestamp
updated
è maggiore dell'ultima esecuzione del trasferimento riuscita (04/07/2023T03:00Z). 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 nella tabella di destinazione BigQuery. Tutte le modifiche apportate ai file vengono trasferite alla successiva esecuzione di trasferimento riuscita. Eventuali trasferimenti riusciti successivi in seguito a un trasferimento non riuscito non generano dati duplicati. Nel caso di un trasferimento non riuscito, puoi anche scegliere di attivarlo manualmente al di fuori dell'orario regolarmente 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 di trasferimento con i dati provenienti da 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 partizioni, l'esecuzione del trasferimento sovrascrive solo i dati nella partizione specificata. Una tabella di destinazione con un decorator della 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 che interessano la stessa tabella di destinazione BigQuery, BigQuery Data Transfer Service può duplicare i dati.
Supporto dei caratteri jolly per il percorso dati di Archiviazione BLOB
Puoi selezionare i dati di origine separati in più file specificando uno o più caratteri jolly * (*
) nel percorso dei dati.
Sebbene sia possibile utilizzare più di un carattere jolly nel percorso dati, è possibile eseguire alcune ottimizzazioni quando viene utilizzato un solo carattere jolly:
- Esiste un limite più elevato al numero massimo di file per esecuzione di trasferimento.
- Il carattere jolly si estenderà fino ai limiti delle directory. Ad esempio, il percorso dati
my-folder/*.csv
corrisponderà al filemy-folder/my-subfolder/my-file.csv
.
Esempi di percorsi dati per l'archiviazione BLOB
Di seguito sono riportati alcuni esempi di percorsi di dati validi per un trasferimento nell'archiviazione BLOB. Tieni presente che i percorsi dei dati non iniziano con /
.
Esempio: file singolo
Per caricare un singolo file da Blob Storage in BigQuery, specifica il nome file di Blob Storage:
my-folder/my-file.csv
Esempio: Tutti i file
Per caricare tutti i file da un container di archiviazione BLOB 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, vengono applicate le directory. In questo esempio, sono selezionati ogni file CSV in my-folder
, così come ogni file CSV in ogni sottocartella di my-folder
.
Esempio: carattere jolly alla fine del percorso
Considera il seguente percorso 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 dati:
*logs.csv
Sono selezionati tutti i seguenti file:
logs.csv
system/logs.csv
some-application/logs.csv
Inoltre, nessuno dei seguenti file è selezionato:
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, ma con limiti inferiori. Quando utilizzi più caratteri jolly, ogni singolo carattere jolly copre solo una singola sottodirectory.
Considera il seguente percorso dati:
*/*.csv
Sono selezionati entrambi i seguenti file:
my-folder1/my-file1.csv
my-other-folder2/my-file2.csv
Inoltre, 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 SAS di Azure viene utilizzato per accedere ai dati di archiviazione BLOB per conto tuo. Per creare un token SAS per il trasferimento:
- Crea o utilizza un utente esistente per l'archiviazione BLOB per accedere all'account di archiviazione del container Archiviazione BLOB.
Crea un token SAS a livello di account di archiviazione. Per creare un token SAS utilizzando il portale di Azure, segui questi passaggi:
- In Servizi consentiti, seleziona Blob.
- In Tipi di risorse consentiti, seleziona sia Contenitore sia Oggetto.
- In Autorizzazioni consentite, seleziona Lettura ed Elenco.
- La scadenza predefinita per i token SAS è di 8 ore. Imposta una scadenza adatta alla tua pianificazione di trasferimento.
- Non specificare alcun indirizzo IP nel campo Indirizzi IP consentiti.
- In Protocolli consentiti, seleziona Solo HTTPS.
Dopo la creazione del token SAS, prendi nota del valore del token SAS che viene restituito. Questo valore ti serve quando configuri i trasferimenti.
Restrizioni IP
Se limiti l'accesso alle tue risorse Azure utilizzando un firewall Archiviazione di Azure, 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 Archiviazione di Azure, vedi Limitazioni IP.
Considerazioni sulla coerenza
Dopo l'aggiunta di un file al container di archiviazione BLOB, dovrebbero essere necessari circa 10 minuti prima che un file sia disponibile in BigQuery Data Transfer Service.
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 includono:
- La tabella di destinazione non esiste.
- Lo schema della tabella non è definito.
- Lo schema della tabella non è compatibile con i dati da trasferire.
Per evitare costi aggiuntivi per il traffico in uscita dall'archiviazione BLOB, testa prima un trasferimento con un sottoinsieme di file piccolo ma rappresentativo. Assicurati che le dimensioni del test siano ridotte per quanto riguarda le dimensioni dei dati e il numero di file.
È anche importante notare che la corrispondenza dei prefissi per i percorsi dei dati avviene prima che i file vengano trasferiti da Blob Storage, 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 che vengono trasferiti a Google Cloud ma non caricati in BigQuery.
Prendiamo come 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, in BigQuery viene caricato solo il file folder/any/subfolder/file1.csv
, perché corrisponde al percorso completo dei dati.
Prezzi
Per ulteriori informazioni, consulta la pagina relativa ai prezzi di BigQuery Data Transfer Service.
Utilizzando questo servizio puoi anche incorrere in costi esterni a Google. Per ulteriori informazioni, consulta la pagina relativa ai prezzi di archiviazione BLOB.
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 dell'archiviazione BLOB, con le seguenti considerazioni aggiuntive:
Limite | Predefinito |
---|---|
Dimensione massima per esecuzione di trasferimento del job di caricamento | 15 TB |
Numero massimo di file per esecuzione di trasferimento quando il percorso dati di Archiviazione BLOB include 0 o 1 caratteri jolly | 10.000.000 di file |
Numero massimo di file per esecuzione di trasferimento quando il percorso dati di Archiviazione BLOB include due o più caratteri jolly | 10.000 file |
Passaggi successivi
- Scopri di più sulla configurazione di un trasferimento nell'archiviazione BLOB.
- Scopri di più sui parametri di runtime nei trasferimenti.
- Scopri di più su BigQuery Data Transfer Service.