Introduzione al caricamento dei dati

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

Metodi di caricamento dei dati

Puoi caricare (o importare) i dati in BigQuery in diversi modi:

  • 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 un tabella.
  • Utilizzare un'applicazione o un servizio di terze parti.

Caricamento in batch

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

Le opzioni per il caricamento in batch in BigQuery includono:

  • Carica i job. Carica i dati da Cloud Storage o da un file locale tramite creando un job di caricamento. I record possono essere in formato Avro, CSV, JSON, ORC o Parquet.
  • SQL. La LOAD DATA L'istruzione SQL 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 Storage Write. L'API Storage Write ti consente di elaborare in batch un numero arbitrariamente elevato di record e di eseguirne il commit in un'unica operazione atomica. Se l'operazione di commit non va a buon fine, puoi riprovare l'operazione. A differenza dei job di caricamento BigQuery, L'API StorageWrite non richiede la gestione temporanea dei dati in archiviazione intermedia come Cloud Storage.
  • Altri servizi gestiti. Utilizza altri servizi gestiti per esportare i dati da un almacenamento dati esterno e importarli in BigQuery. Ad esempio: puoi caricare i dati dalle esportazioni di Firestore.

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

Il caricamento collettivo 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 base a una pianificazione.

Streaming

Con lo streaming, invii continuamente piccoli batch di dati in tempo reale, in modo che i dati siano disponibili per le query non appena arrivano. Le opzioni per lo streaming in BigQuery includono:

  • API StorageWrite. L'API Storage Write supporta l'importazione di streaming con velocità effettiva elevata con la semantica di consegna "exactly-once".
  • Dataflow. Utilizza Dataflow con l'SDK Apache Beam per configurare una pipeline in modalità flusso che scriva in BigQuery. Per ulteriori informazioni, consulta il connettore BigQuery I/O nella documentazione di Apache Beam e il tutorial Trasmissione di stream da Pub/Sub a BigQuery.
  • Datastream. Datastream utilizza la funzionalità di Change Data Capture di BigQuery e API Storage Scrivi per replicare i dati e gli aggiornamenti degli schemi dai database operativi direttamente in BigQuery. Segui questa guida introduttiva per un esempio di replica da un database Cloud SQL per PostgreSQL a BigQuery.
  • BigQuery Connector per SAP. BigQuery Connector for 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 i 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 di dati includono:

  • Utilizzare il data Manipulation Language (DDL) Istruzioni DML per eseguire inserimenti collettivi in una tabella o una query di archiviazione esistente crea una nuova tabella.

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

  • Eseguire una query e salvare i risultati in una tabella. Puoi accodare i risultati a una tabella esistente o scrivere in una nuova tabella. Per ulteriori informazioni, consulta Scrivere i risultati delle query.

Applicazioni di terze parti

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

Scelta di un metodo di importazione dei dati

Ecco alcuni aspetti da considerare quando scegli un'importazione dati .

Origine dati. L'origine dei dati o il formato dei dati possono determinare se il caricamento in batch o l'inserimento di flussi di dati sono più semplici da implementare e gestire. Considera 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 fonti di terze parti non supportate dal BigQuery Data Transfer Service, trasforma i dati in un formato supportato tramite il caricamento in batch e utilizza tale metodo .

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

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

  • Per i dati dell'applicazione, come gli eventi dell'applicazione o uno stream di log, potrebbe essere più semplice trasmettere i dati in tempo reale anziché implementare il caricamento batch.

Dati in lenta evoluzione rispetto a dati in rapida evoluzione. Se devi importare e analizzare quasi in tempo reale, valuta la possibilità di trasmetterli in flussi. Con lo streaming, i dati sono disponibili per le query non appena arriva ogni record. Evita di utilizzare istruzioni DML per inviare un numero elevato di aggiornamenti o inserimenti di singole righe. Per aggiornati di frequente, spesso è preferibile trasmettere in streaming un log delle modifiche e utilizzare per ottenere gli ultimi risultati. Un'altra opzione è usare Cloud SQL come di elaborazione delle transazioni online (OLTP) e di utilizzare query federate per unire per inserire i dati in BigQuery.

Se i dati di origine cambiano lentamente o non hai bisogno di essere aggiornati continuamente i risultati, valuta l'utilizzo di un job di caricamento. Ad esempio, se utilizzi i dati per eseguire un giornaliero o orario, i job di caricamento possono essere meno costosi e possono utilizzare Google Cloud.

Un altro scenario è costituito dai dati che arrivano di rado 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 Run funziona per chiamare l'API per i flussi di dati in risposta a un trigger.

Affidabilità della soluzione. BigQuery ha un livello di servizio di Google (SLA). Tuttavia, devi considerare anche l'affidabilità della soluzione specifica che implementi. Considera le seguenti punti:

  • Con formati a tipi non rigidi come JSON o CSV, i dati errati possono causare il fallimento di un intero job di caricamento. Valuta se hai bisogno di un passaggio di pulizia dei dati prima del caricamento e come rispondere agli errori. Inoltre, valuta la possibilità di utilizzare con caratteri di forte impatto come Avro, ORC o Parquet.
  • I job di caricamento periodico richiedono la pianificazione, utilizzando Cloud Composer, cron o un altro strumento. Il componente di pianificazione potrebbe essere un punto di errore nel soluzione.
  • Con lo streaming, puoi verificare l'efficacia di ogni record e generare rapidamente report un errore. Valuta la possibilità di scrivere i messaggi con errori in una coda di messaggi non elaborati per analizzarli ed elaborarli in un secondo momento. Per ulteriori informazioni sugli errori di streaming di BigQuery, consulta la pagina Risoluzione dei problemi relativi agli inserimenti di flussi di dati.
  • I job di streaming e di caricamento sono soggetti a quote. Per informazioni su come gestire gli errori di quota, consulta Risoluzione degli errori di quota di BigQuery.
  • Le soluzioni di terze parti potrebbero differire in termini di configurabilità, affidabilità, garanzie di ordinamento e altri fattori, quindi prendili in considerazione prima di adottare una soluzione.

Latenza. Valuta la quantità di dati che carichi e quanto velocemente devono essere disponibili. Lo streaming offre la latenza più bassa dei dati disponibili per l'analisi. I job di caricamento periodici hanno una latenza più elevata, perché i nuovi dati disponibili al termine di ogni job di caricamento.

Per impostazione predefinita, i job di caricamento utilizzano un pool di slot condivisi. Un carico il job potrebbe attendere in stato di attesa finché non saranno disponibili slot, soprattutto se per caricare una grande quantità di dati. Se i tempi di attesa sono inaccettabili, puoi acquistare slot dedicati anziché utilizzare il pool di slot condiviso. Per ulteriori informazioni, consulta la pagina Introduzione alle prenotazioni.

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

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

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

  • Dati flat o campi nidificati e ripetuti. Avro, CSV, JSON, ORC e Tutti i Parquet supportano i dati piatti. 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 anche la duplicazione dei dati quando il caricamento dei dati.

  • Nuove righe incorporate. Quando carichi dati da file JSON, le righe devono essere delimitato da una nuova riga. BigQuery si aspetta che i file JSON delimitati da una nuova riga contengano un singolo record per riga.

  • Codifica. BigQuery supporta la codifica UTF-8 sia per i dati nidificati o ripetuti sia per i dati in formato piano. BigQuery supporta 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 quando carichi i dati, consulta Specifica dei campi nidificati e ripetuti.

Caricare dati da altri servizi Google

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

Altri servizi Google supportano le esportazioni di dati avviate da BigQuery Data Transfer Service. Per saperne di più sui servizi che supportano le esportazioni avviate da BigQuery Data Transfer Service, consulta BigQuery Data Transfer Service.

Quote

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 ulteriori informazioni, consulta Set di dati pubblici di BigQuery.
Set di dati condivisi
Puoi condividere i set di dati archiviati in BigQuery. Se qualcuno ha condiviso un set di dati con te, puoi eseguire query su quel set di dati senza i dati.
Origini dati esterne
BigQuery può eseguire query su determinate forme di dati esterni, senza dover caricare i dati nello spazio di archiviazione BigQuery. Questo approccio consente di sfruttare le funzionalità di analisi a BigQuery senza spostare i dati archiviati altrove. Per informazioni sui vantaggi e sulle limitazioni di questo approccio, consulta le origini dati esterne.
File di log
Cloud Logging offre un'opzione per esportare i file di log in in BigQuery. Consulta: Configura e gestisci i sink per ulteriori informazioni.

Monitora l'utilizzo dei job di caricamento

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

  • Utilizza Cloud Monitoring. Per ulteriori informazioni, vedi Metriche BigQuery. Nello specifico, puoi monitorare la quantità di dati e il numero di righe caricate in una tabella specifica. Se i tuoi job di caricamento caricano dati in una tabella specifica, un proxy per monitorare l'utilizzo dei dati di caricamento dei job di caricamento.

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

Caso d'uso di esempio

Gli esempi riportati di seguito illustrano i metodi da utilizzare in base al 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 sugli eventi dai log degli endpoint. Gli eventi vengono generati continuamente e devono essere disponibili per le query in BigQuery il prima possibile. Poiché l'aggiornamento dei dati è fondamentale questo caso d'uso, API StorageWrite è la scelta migliore per importare i dati in BigQuery. Un'architettura consigliata per mantenere questi endpoint essenziali è l'invio di eventi a Pub/Sub, da dove vengono utilizzati da una pipeline Dataflow in modalità flusso che trasmette direttamente in BigQuery.

Un problema di affidabilità principale per questa architettura è come gestire l'errore di inserimento di un record in BigQuery. Se ogni record è importante non possono andare persi, i dati devono essere inseriti nel buffer prima di tentare di inserirli. Nella all'architettura consigliata di cui sopra, Pub/Sub può svolgere il ruolo buffer con le sue funzionalità di conservazione dei messaggi. Dataflow la pipeline deve essere configurata per riprovare a inserire i flussi di dati BigQuery con backoff esponenziale troncato. Dopo la capacità di Pub/Sub quando il buffer è esaurito, ad esempio, in caso di prolungata indisponibilità di BigQuery o in caso di errore di rete, i dati devono essere resi persistenti Il client necessita 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 Guida all'affidabilità di Google Pub/Sub.

Un altro caso di errore da gestire è quello di un record dannoso. Un resoconto di veleni è o un record rifiutato da BigQuery perché non riesce a inserire con un errore non ripetibile o un record che non è stato eseguito correttamente inserito dopo il numero massimo di nuovi tentativi. Entrambi i tipi di record devono essere archiviati in un "coda messaggi non recapitabili" da parte della pipeline Dataflow per ulteriori indagini.

Se è richiesta la semantica "exactly-once", crea un flusso di scrittura in di tipo impegnato, con compensazioni record fornite dal cliente. In questo modo vengono evitati i duplicati, poiché l'operazione di scrittura viene eseguita solo se il valore dell'offset corrisponde all'offset di accodamento successivo. Se non fornisci un offset, i record vengono aggiunti alla fine corrente dello stream e la ripetizione di un'aggiunta non riuscita potrebbe comportare la visualizzazione del record più di una volta nello stream.

Se non sono necessarie garanzie di esecuzione esattamente una volta, la scrittura nello stream predefinito consente un throughput più elevato e non viene conteggiata ai fini del limite di quota per la creazione di stream di scrittura.

Stima il throughput della tua rete e assicurati in anticipo di disporre di una quota adeguata per gestire il throughput.

Se il tuo carico di lavoro genera o elabora dati a una frequenza molto irregolare, prova a smussare gli eventuali picchi di carico sul client e a trasmettere in streaming in BigQuery con un throughput costante. In questo modo puoi semplificare la pianificazione delle capacità. Se non è possibile, assicurati di essere pronto a gestire gli errori 429 (risorsa esaurita) se e quando il throughput supera la quota durante picchi brevi.

Elaborazione dei dati in batch

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

Caricamento in batch di dati con job di caricamento è l'approccio giusto per questo caso d'uso, perché la latenza non è un problema a condizione che la scadenza sia rispettata. Assicurati che i tuoi bucket Cloud Storage soddisfare i requisiti per le località per caricare i dati nel set di dati BigQuery.

Il risultato di un job di caricamento BigQuery è atomico: vengono inseriti tutti i record o nessuno. Come best practice, quando inserisci tutti i dati in un singolo job di caricamento, crea una nuova tabella utilizzando la disposizione WRITE_TRUNCATE della risorsa JobConfigurationLoad. Questo è importante quando si ripete un job di caricamento non riuscito, in quanto il client potrebbe non sarà in grado di distinguere tra i job non riusciti e quelli non riusciti causata, ad esempio, dalla comunicazione dello stato di operazione riuscita al client.

Supponendo che i dati da importare siano stati copiati 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 con i tentativi di nuovo caricamento. Durante il caricamento dei dati in modo incrementale, la quota predefinita è sufficiente per eseguire un job di caricamento ogni 5 minuti e hanno una quota non consumata per almeno 1 nuovo tentativo per job in media.

Passaggi successivi