Introduzione al caricamento dei dati

Questo documento fornisce una panoramica del caricamento dei dati in BigQuery.

Panoramica

Esistono diversi modi per importare i dati in BigQuery:

  • Caricare in batch un set di record di dati.
  • Trasmetti in streaming singoli record o batch di record.
  • Utilizza le query per generare nuovi dati e aggiungere o sovrascrivere i risultati in una tabella.
  • Utilizzare un'applicazione o un servizio di terze parti.

Caricamento in batch

Con il caricamento in batch, i dati di origine vengono caricati in una tabella BigQuery con un'unica operazione batch. Ad esempio, un'origine dati potrebbe essere un file CSV, un database esterno o un insieme di file di log. I job ETL tradizionali di estrazione, trasformazione e caricamento (ETL) rientrano in questa categoria.

Le opzioni per il caricamento in batch in BigQuery includono:

  • Job di caricamento. Carica i dati da Cloud Storage o da un file locale creando un job di caricamento. I record possono essere in formato Avro, CSV, JSON, ORC o Parquet.
  • SQL. L'istruzione SQL LOAD DATA carica i dati da uno o più file in una tabella nuova o esistente. Puoi utilizzare l'istruzione LOAD DATA per caricare file Avro, CSV, JSON, ORC o Parquet.
  • BigQuery Data Transfer Service. Utilizza BigQuery Data Transfer Service per automatizzare il caricamento dei dati dalle app Google Software as a Service (SaaS) o da applicazioni e servizi di terze parti.
  • API BigQuery StorageWrite. L'API StorageWrite consente di elaborare in batch un numero arbitrariamente elevato di record ed eseguirne il commit in una singola operazione atomica. Se l'operazione di commit non va a buon fine, puoi riprovare in sicurezza. A differenza dei job di caricamento di BigQuery, l'API StorageWrite non richiede la gestione temporanea dei dati nell'archiviazione intermedia, ad esempio in Cloud Storage.
  • Altri servizi gestiti. Usa altri servizi gestiti per esportare i dati da un datastore esterno e importarli in BigQuery. Ad esempio, puoi caricare i dati dalle esportazioni di Firestore.

Quando scegli un metodo di caricamento in batch, la maggior parte dei pattern basati su file dovrebbe utilizzare un job di caricamento o un'istruzione SQL LOAD DATA per caricare i dati in batch. In genere gli altri servizi dovrebbero utilizzare BigQuery Data Transfer Service o esportare dati dai servizi Google.

Il caricamento in batch può essere eseguito come operazione una tantum o in base a una pianificazione ricorrente. Puoi ad esempio eseguire le seguenti operazioni:

  • Puoi eseguire i trasferimenti di BigQuery Data Transfer Service in base a una pianificazione.
  • Puoi utilizzare un servizio di orchestrazione come Cloud Composer per pianificare i job di caricamento.
  • Puoi utilizzare un cron job per caricare i dati in una pianificazione.

Dispositivi di streaming

Con i flussi di dati, invii continuamente batch di dati più piccoli in tempo reale, in modo che i dati siano disponibili per l'esecuzione di query non appena arrivano. Le opzioni per l'inserimento di flussi in BigQuery includono quanto segue:

  • API StorageWrite. L'API StorageWrite supporta l'importazione di flussi di dati a velocità effettiva elevata con semantica di consegna "exactly-once".
  • Dataflow. Utilizza Dataflow con l'SDK Apache Beam per configurare una pipeline di flusso che scrive su BigQuery. Per ulteriori informazioni, consulta il connettore BigQuery I/O nella documentazione di Apache Beam e il tutorial sul flusso di dati da Pub/Sub a BigQuery.
  • Datastream. Datastream utilizza la funzionalità Change Data Capture di BigQuery e l'API StorageWrite per replicare i dati e gli aggiornamenti dello schema dai database operativi direttamente in BigQuery. Segui questa quickstart per un esempio di replica da un database Cloud SQL per PostgreSQL in BigQuery.
  • Connettore BigQuery per SAP. BigQuery Connector per SAP consente la replica quasi in tempo reale dei dati SAP direttamente in BigQuery. Per ulteriori informazioni, consulta la guida alla pianificazione di BigQuery Connector per SAP.
  • Pub/Sub. Pub/Sub è un servizio di messaggistica che puoi utilizzare per coordinare le pipeline di analisi dei flussi di dati e di integrazione dei dati. Puoi utilizzare le sottoscrizioni BigQuery per scrivere messaggi direttamente in una tabella BigQuery esistente.

Dati generati

Puoi utilizzare SQL per generare dati e archiviare i risultati in BigQuery. Le opzioni per la generazione dei dati includono:

  • Utilizza le istruzioni DML (data manipolaion language) per eseguire inserimenti collettivi in una tabella esistente o archiviare i risultati delle query in una nuova tabella.

  • Utilizza un'istruzione CREATE TABLE ... AS per creare una nuova tabella dal risultato di una query.

  • Eseguire una query e salvare i risultati in una tabella. Puoi aggiungere i risultati a una tabella esistente o scrivere in una nuova tabella. Per maggiori informazioni, consulta Scrittura dei risultati di una query.

Applicazioni di terze parti

Alcuni servizi e applicazioni di terze parti forniscono connettori per importare dati in BigQuery. I dettagli di come configurare e gestire la pipeline di importazione dipendono dall'applicazione. Ad esempio, per caricare i dati da origini esterne nell'archiviazione di BigQuery, puoi utilizzare Informatica Data Loader o Fivetran Data Pipelines. Per maggiori informazioni, vedi Caricare i dati utilizzando un'applicazione di terze parti.

Scelta di un metodo di importazione dati

Ecco alcune considerazioni da considerare quando si sceglie un metodo di importazione dati.

Origine dati. L'origine dei dati o il formato dei dati possono determinare se il caricamento in batch o il flusso di dati sono più semplici da implementare e gestire. Tieni presente quanto segue:

  • Se BigQuery Data Transfer Service supporta l'origine dati, il trasferimento dei dati direttamente in BigQuery potrebbe essere la soluzione più semplice da implementare.

  • Per i dati provenienti da origini di terze parti non supportate da BigQuery Data Transfer Service, trasforma i dati in un formato supportato dal caricamento in batch e utilizza questo metodo.

  • Se i dati provengono da Spark o Hadoop, valuta la possibilità di utilizzare i connettori BigQuery per semplificare l'importazione dati.

  • Per i file locali, prendi in considerazione i job di caricamento in batch, soprattutto se BigQuery supporta il formato file senza richiedere una fase di trasformazione o pulizia dei dati.

  • Per i dati delle applicazioni, ad esempio eventi dell'applicazione o un flusso di log, potrebbe essere più semplice trasmettere i dati in tempo reale, piuttosto che implementare il caricamento in batch.

Dati in rapida evoluzione e in rapida evoluzione. Se devi importare e analizzare dati quasi in tempo reale, valuta la possibilità di trasmettere i dati in modalità flusso. Con il flusso di dati, i dati sono disponibili per l'esecuzione di query non appena arrivano i record. Evita di utilizzare istruzioni DML per inviare un numero elevato di singoli aggiornamenti o inserimenti di righe. Per i dati aggiornati di frequente, spesso è meglio trasmettere un log delle modifiche in modalità flusso e utilizzare una vista per ottenere i risultati più recenti. Un'altra opzione è quella di utilizzare Cloud SQL come database di elaborazione delle transazioni online (OLTP) e di utilizzare query federate per unire i dati in BigQuery.

Se i dati di origine cambiano lentamente o non hai bisogno di risultati aggiornati continuamente, valuta la possibilità di utilizzare un job di caricamento. Ad esempio, se utilizzi i dati per eseguire un report giornaliero o orario, i job di caricamento possono essere meno costosi e utilizzare meno risorse di sistema.

Un altro scenario riguarda i dati che arrivano raramente o in risposta a un evento. In questo caso, valuta la possibilità di utilizzare Dataflow per trasmettere i dati in modalità flusso o utilizzare Cloud Functions per chiamare l'API Streaming in risposta a un trigger.

Affidabilità della soluzione. BigQuery ha un accordo sul livello del servizio (SLA). Tuttavia, devi anche considerare l'affidabilità della soluzione specifica che implementi. Tieni presente quanto segue:

  • Con i formati a basso livello come JSON o CSV, i dati non validi possono impedire l'intero job di caricamento. Valuta se ti serve una fase di pulizia dei dati prima di caricarli e valuta come rispondere agli errori. Valuta anche l'utilizzo di un formato ben digitato come Avro, ORC o Parquet.
  • I job di caricamento periodici richiedono la pianificazione, tramite Cloud Composer, cron o un altro strumento. Il componente di pianificazione potrebbe essere un punto di errore nella soluzione.
  • Con i flussi di dati, puoi verificare l'efficacia di ogni record e segnalare rapidamente un errore. Valuta la possibilità di scrivere i messaggi non riusciti in una coda di messaggi non elaborati per analizzarli ed elaborarli in seguito. Per ulteriori informazioni sugli errori di flussi di dati BigQuery, consulta Risoluzione dei problemi di inserimento di flussi di dati.
  • I job di flusso e caricamento sono soggetti a quotas. Per informazioni su come gestire gli errori di quota, consulta Risoluzione dei problemi relativi agli errori di quota di BigQuery.
  • Le soluzioni di terze parti potrebbero differire in termini di configurabilità, affidabilità, garanzie di ordinazione e altri fattori, quindi prendili in considerazione prima di adottare una soluzione.

Latenza. Valuta quanti dati carichi e quando devi renderli disponibili. I flussi di dati offrono la minore latenza dei dati disponibili per l'analisi. I job di caricamento periodici hanno una latenza più elevata, perché i nuovi dati sono disponibili solo al termine di ogni job di caricamento.

I job di caricamento utilizzano un pool condiviso di slot per impostazione predefinita. Un job di caricamento potrebbe attendere in stato di attesa fino a quando non sono disponibili slot, soprattutto se carichi una grande quantità di dati. Se ciò genera tempi di attesa inaccettabili, puoi acquistare slot dedicati anziché utilizzare il pool di slot condiviso. Per maggiori informazioni, consulta la sezione Introduzione alle prenotazioni.

Le prestazioni delle query per le origini dati esterne potrebbero essere inferiori a quelle per i dati archiviati in BigQuery. Se è importante ridurre al minimo la latenza delle query, ti consigliamo di caricare i dati in BigQuery.

Formato di importazione dati: Scegli un formato di importazione dati in base ai seguenti fattori:

  • Supporto di schemi. Le esportazioni Avro, ORC, Parquet e Firestore sono formati autodescrittivi. BigQuery crea lo schema della tabella automaticamente in base ai dati di origine. Per i dati JSON e CSV, puoi fornire uno schema esplicito oppure utilizzare il rilevamento automatico degli schemi.

  • Dati flat o campi nidificati e ripetuti. Avro, CSV, JSON, ORC e Parquet supportano tutti i dati flat. Le esportazioni Avro, JSON, ORC, Parquet e Firestore supportano anche i dati con campi nidificati e ripetuti. I dati nidificati e ripetuti sono utili per esprimere dati gerarchici. I campi nidificati e ripetuti riducono inoltre la duplicazione dei dati durante il caricamento dei dati.

  • Nuove righe incorporate. Quando carichi dati da file JSON, le righe devono essere delimitate da nuova riga. BigQuery prevede che i file JSON delimitato da nuova riga contengano un solo record per riga.

  • Codifica. BigQuery supporta la codifica UTF-8 sia per i dati nidificati, ripetuti e piatti. BigQuery supporta la codifica ISO-8859-1 per i dati flat solo per i file CSV.

Carica dati nidificati e ripetuti

Puoi caricare i dati in campi nidificati e ripetuti nei seguenti formati:

  • Avro
  • JSON (delimitato da nuova riga)
  • ORC
  • Parquet
  • Esportazioni di Datastore
  • Esportazioni Firestore

Per informazioni su come specificare i campi nidificati e ripetuti nello schema, durante il caricamento dei dati, consulta Specifica dei campi nidificati e ripetuti.

Carica dati da altri servizi Google

Alcuni servizi Google esportano i dati in BigQuery usando query, esportazioni o trasferimenti pianificati. Per ulteriori informazioni sui servizi che supportano le esportazioni in BigQuery, vedi Caricare i dati dai servizi Google.

Altri servizi Google supportano le esportazioni di dati avviate da BigQuery Data Transfer Service. Per ulteriori informazioni sui servizi che supportano le esportazioni avviate da BigQuery Data Transfer Service, vedi BigQuery Data Transfer Service.

Quota

Per informazioni sulle quote, consulta le sezioni seguenti:

Alternative al caricamento dei dati

Nelle seguenti situazioni non è necessario caricare i dati prima di eseguire le query:

Set di dati pubblici
I set di dati pubblici sono set di dati archiviati in BigQuery e condivisi con il pubblico. Per maggiori informazioni, consulta Set di dati pubblici BigQuery.
Set di dati condivisi
Puoi condividere i set di dati archiviati in BigQuery. Se qualcuno ha condiviso con te un set di dati, puoi eseguire query su quel set di dati senza doverli caricare.
Origini dati esterne
BigQuery può eseguire query su determinati tipi di dati esterni, senza caricarli nello spazio di archiviazione di BigQuery. Questo approccio ti consente di sfruttare le funzionalità di analisi di BigQuery senza spostare i dati archiviati altrove. Per informazioni sui vantaggi e sulle limitazioni di questo approccio, consulta le origini dati esterne.
File di logging
Cloud Logging offre un'opzione per esportare i file di log in BigQuery. Per ulteriori informazioni, consulta Configurare e gestire i sink.

Monitora l'utilizzo dei job di caricamento

Puoi monitorare l'utilizzo dei job di caricamento in due modi:

  • Utilizza Cloud Monitoring. Per ulteriori informazioni, consulta Metriche BigQuery. In particolare, puoi monitorare la quantità di dati e il numero di righe caricate in una tabella specifica. Se i job di caricamento caricano dati in una tabella specifica, questo può essere un proxy per monitorare l'utilizzo dei dati di caricamento dei job di caricamento.

  • Usa INFORMATION_SCHEMA.JOBS_BY_PROJECT. Puoi utilizzare la vista INFORMATION_SCHEMA.JOBS_BY_PROJECT per ottenere il numero di job di caricamento per tabella al giorno.

Caso d'uso di esempio

I seguenti esempi spiegano i metodi da utilizzare in base al tuo caso d'uso e come utilizzarli con altre soluzioni di analisi dei dati.

Trasmetti il flusso di dati utilizzando l'API Storage Scrivi

Supponiamo che esista una pipeline che elabora i dati degli eventi dai log degli endpoint. Gli eventi vengono generati continuamente e devono essere disponibili per l'esecuzione di query in BigQuery il prima possibile. Poiché l'aggiornamento dei dati è fondamentale per questo caso d'uso, l'API StorageWrite è la scelta migliore per importare i dati in BigQuery. Un'architettura consigliata per mantenere snelli questi endpoint è l'invio di eventi a Pub/Sub, da dove vengono consumati da una pipeline Dataflow in modalità flusso che invia direttamente i flussi a BigQuery.

Un problema di affidabilità fondamentale per questa architettura è come affrontare l'impossibilità di inserire un record in BigQuery. Se ogni record è importante e non può essere perso, i dati devono essere inseriti nel buffer prima di tentare l'inserimento. Nell'architettura consigliata sopra, Pub/Sub può svolgere il ruolo di buffer con le sue funzionalità di conservazione dei messaggi. La pipeline Dataflow deve essere configurata in modo da riprovare gli inserimenti di flussi di dati BigQuery con backoff esponenziale troncato. Una volta esaurita la capacità di Pub/Sub come buffer, ad esempio in caso di prolungata indisponibilità di BigQuery o di errore di rete, i dati devono essere mantenuti sul client e quest'ultimo ha bisogno di un meccanismo per riprendere l'inserimento dei record persistenti una volta ripristinata la disponibilità. Per ulteriori informazioni su come gestire questa situazione, consulta il post del blog della guida all'affidabilità di Google Pub/Sub.

Un altro caso di errore da gestire è quello dei record di veleno. Un record di poileon è un record rifiutato da BigQuery perché non riesce a essere inserito con un errore non riprovabile o perché non è stato inserito correttamente dopo il numero massimo di nuovi tentativi. Entrambi i tipi di record devono essere archiviati in una "coda dei messaggi non recapitabili" dalla pipeline Dataflow per ulteriori indagini.

Se è richiesta la semantica "exactly-once", crea un flusso di scrittura in tipo impegnato, con gli offset del record forniti dal client. Ciò evita i duplicati, poiché l'operazione di scrittura viene eseguita solo se il valore di offset corrisponde all'offset dell'aggiunta successiva. Se non viene fornito un offset, i record vengono aggiunti alla fine attuale del flusso e il tentativo di aggiunta non riuscita potrebbe far sì che il record venga visualizzato più di una volta nel flusso.

Se non sono necessarie garanzie "exactly-once", la scrittura nel flusso predefinito consente una velocità effettiva più elevata e non viene conteggiata ai fini del limite di quota per la creazione di flussi di scrittura.

Stima la velocità effettiva della tua rete e assicurati in anticipo di disporre di una quota adeguata per la velocità effettiva.

Se il carico di lavoro genera o elabora i dati a una velocità molto irregolare, prova a ridurre eventuali picchi di carico sul client e a inviare flussi a BigQuery con una velocità effettiva costante. Questo può semplificare la pianificazione della capacità. Se questo non è possibile, assicurati di essere pronto a gestire gli errori 429 (risorse esaurite) se e quando la velocità effettiva supera la quota durante brevi picchi.

Elaborazione dei dati in batch

Supponiamo che esista una pipeline di elaborazione batch notturna che deve essere completata entro una scadenza fissa. I dati devono essere disponibili entro questa scadenza per un'ulteriore elaborazione da parte di un altro processo batch al fine di generare report da inviare a un ente regolatore. Questo caso d'uso è comune in settori regolamentati come la finanza.

Il caricamento in batch dei dati con job di caricamento è l'approccio giusto per questo caso d'uso, perché la latenza non è un problema purché sia possibile rispettare la scadenza. Assicurati che i bucket Cloud Storage soddisfino i requisiti per le località per il caricamento dei dati nel set di dati BigQuery.

Il risultato di un job di caricamento BigQuery è atomico. Tutti i record vengono inseriti o nessuno lo fa. Come best practice, quando inserisci tutti i dati in un singolo job di caricamento, crea una nuova tabella utilizzando l'istruzione WRITE_TRUNCATE della risorsa JobConfigurationLoad. Questo è importante quando si ripete un job di caricamento non riuscito, poiché il client potrebbe non essere in grado di distinguere tra i job non riusciti e l'errore causato, ad esempio quando comunica lo stato di operazione riuscita al client.

Supponendo che i dati da importare siano già stati copiati correttamente in Cloud Storage, è sufficiente riprovare con il backoff esponenziale per risolvere gli errori di importazione.

È consigliabile che un job batch notturno non raggiunga la quota predefinita di 1500 caricamenti per tabella al giorno,anche in caso di nuovi tentativi. Quando i dati vengono caricati in modo incrementale, la quota predefinita è sufficiente per l'esecuzione di un job di caricamento ogni 5 minuti e presenta una quota non consumata per almeno 1 nuovo tentativo per job in media.

Passaggi successivi