Introduzione ai trasferimenti dei report di Cloud Storage

BigQuery Data Transfer Service per Cloud Storage consente di pianificare i caricamenti di dati ricorrenti dai bucket Cloud Storage a BigQuery. Il percorso dei dati archiviati in Cloud Storage e la tabella di destinazione possono essere parametrizzati, consentendoti di caricare i dati da bucket Cloud Storage organizzati per data.

Formati di file supportati

BigQuery Data Transfer Service supporta il caricamento dei dati da Cloud Storage in uno dei seguenti formati:

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

Tipi di compressione supportati

BigQuery Data Transfer Service per Cloud 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 saperne di più, vedi Caricamento di dati compressi e non compressi.

Importazione dei dati per i trasferimenti di Cloud Storage

Puoi specificare come vengono caricati i dati in BigQuery selezionando una preferenza di scrittura nella configurazione del trasferimento quando configuri un trasferimento Cloud Storage.

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à updated timestamp 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.

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.

Percorso della risorsa Cloud Storage

Per caricare i dati da un'origine dati Cloud Storage, devi fornire il percorso dei dati.

Il percorso della risorsa Cloud Storage contiene il nome del bucket e l'oggetto (nome file). Ad esempio, se il bucket Cloud Storage si chiama mybucket e il file di dati si chiama myfile.csv, il percorso della risorsa sarà gs://mybucket/myfile.csv.

BigQuery non supporta i percorsi delle risorse Cloud Storage che includono più barre consecutive dopo la doppia barra iniziale. I nomi degli oggetti Cloud Storage possono contenere più caratteri barra ("/") consecutivi. Tuttavia, BigQuery converte più barre consecutive in una singola barra. Ad esempio, il seguente percorso della risorsa, sebbene valido in Cloud Storage, non funziona in BigQuery: gs://bucket/my//object//name.

Per recuperare il percorso della risorsa Cloud Storage:

  1. Apri la console Cloud Storage.

    Console Cloud Storage

  2. Sfoglia fino alla posizione dell'oggetto (file) che contiene i dati di origine.

  3. Fai clic sul nome dell'oggetto.

    Viene visualizzata la pagina Dettagli oggetto.

  4. Copia il valore fornito nel campo URI gsutil, che inizia con gs://.

Supporto dei caratteri jolly per i percorsi delle risorse Cloud Storage

Se i dati di Cloud Storage sono suddivisi in più file che condividono un nome base comune, puoi utilizzare un carattere jolly nel percorso della risorsa quando carichi i dati.

Per aggiungere un carattere jolly al percorso della risorsa Cloud Storage, aggiungi un asterisco (*) al nome base. Ad esempio, se hai due file denominati fed-sample000001.csv e fed-sample000002.csv, il percorso della risorsa sarà gs://mybucket/fed-sample*. Questo carattere jolly può essere utilizzato nella consoleGoogle Cloud o in Google Cloud CLI.

Puoi utilizzare più caratteri jolly per gli oggetti (nomi file) all'interno dei bucket. Il carattere jolly può essere visualizzato in qualsiasi punto del nome dell'oggetto.

I caratteri jolly non espandono una directory in un gs://bucket/. Ad esempio, gs://bucket/dir/* trova i file nella directory dir, ma non nella sottodirectory gs://bucket/dir/subdir/.

Non puoi nemmeno trovare corrispondenze con i prefissi senza caratteri jolly. Ad esempio, gs://bucket/dir non corrisponde a gs://bucket/dir/file.csv né a gs://bucket/file.csv

Tuttavia, puoi utilizzare più caratteri jolly per i nomi dei file all'interno dei bucket. Ad esempio, gs://bucket/dir/*/*.csv corrisponde a gs://bucket/dir/subdir/file.csv.

Per esempi di supporto dei caratteri jolly in combinazione con nomi di tabelle con parametri, consulta Parametri runtime nei trasferimenti.

Quote e limiti

BigQuery Data Transfer Service utilizza i job di caricamento per caricare i dati di Cloud Storage in BigQuery.

Tutte le quote e i limiti di BigQuery sui job di caricamento si applicano ai job di caricamento ricorrenti di Cloud Storage, con le seguenti considerazioni aggiuntive:

Valore Limite
Dimensione massima per esecuzione del trasferimento del job di caricamento 15 TB
Numero massimo di file per esecuzione del trasferimento 10.000 file

Prezzi

Quando i dati vengono trasferiti su BigQuery, vengono applicati i prezzi standard di BigQuery per l'archiviazione e le query.

Per i trasferimenti tra località da Cloud Storage, i prezzi sono determinati dalla località del bucket Cloud Storage e dalla località del set di dati BigQuery di destinazione. Per saperne di più, consulta Trasferimento di dati all'interno di Google Cloud.

Per ulteriori informazioni sui prezzi, consulta la pagina Prezzi di BigQuery.

Passaggi successivi