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 accodare o sovrascrivere i risultati in una tabella.
  • Utilizzi 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 file, un database esterno o un insieme di file di log. Estratto tradizionale, I job ETL (trasformazione e caricamento) 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 Writer. 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 dei job di caricamento.
  • Puoi utilizzare un cron job per caricare i dati in una pianificazione.

Streaming

Con i flussi di dati, invii continuamente batch di dati più piccoli in tempo reale, i dati sono disponibili per l'esecuzione di query non appena arrivano. Le opzioni per lo streaming in BigQuery includono:

  • API Storage Write. L'API StorageWrite supporta l'importazione di flussi di dati a velocità effettiva elevata con distribuzione "exactly-once" la semantica.
  • 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à CDC (Change Data Capture) di BigQuery e l'API Storage Write per replicare i dati e gli aggiornamenti dello schema dai database operativi direttamente in BigQuery. Segui questa guida rapida per un esempio di replica da un database Cloud SQL per PostgreSQL in BigQuery.
  • Connettore BigQuery 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 aggiungere i risultati a un 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 offrono connettori che possono importare i dati in BigQuery. I dettagli su come per configurare e gestire la pipeline di importazione dipende 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 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 delle applicazioni, ad esempio eventi delle applicazioni o un flusso di log, potrebbero essere è più facile trasmettere i dati in modalità flusso in tempo reale, anziché implementare Caricamento in corso.

Dati in rapida evoluzione e in rapida evoluzione. Se devi importare e analizzare i dati quasi in tempo reale, valuta la possibilità di utilizzarli in streaming. Con i flussi di dati, i dati vengono disponibile per l'esecuzione di query non appena arriva ogni record. Evita di utilizzare istruzioni DML per inviare un numero elevato di aggiornamenti o inserimenti di singole righe. Per i dati aggiornati di frequente, spesso è meglio eseguire lo streaming di un log delle modifiche e utilizzare una visualizzazione per ottenere i risultati più recenti. Un'altra opzione è utilizzare Cloud SQL come database OLTP (Online Transaction Processing) e le query federate per unire i dati in BigQuery.

Se i dati di origine cambiano lentamente o se 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 possono 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 Run funziona per chiamare l'API per i flussi di dati in risposta a un trigger.

Affidabilità della soluzione. BigQuery ha un Accordo sul livello del servizio (SLA). Tuttavia, devi anche prendere in considerazione l'affidabilità della particolare soluzione che implementi. Considera quanto segue:

  • 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. Valuta anche la possibilità di utilizzare un formato fortemente tipizzato 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 nella soluzione.
  • Con lo streaming, puoi verificare l'esito di ogni record e segnalare rapidamente 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 Per gli errori di flussi di dati BigQuery, vedi Risoluzione dei problemi di inserimento di flussi di dati.
  • I job di flusso e 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 e altri fattori, per cui è bene valutarli prima di adottare una soluzione.

Latenza. Considera la quantità di dati da caricare e quanto tempo devono trascorrere disponibili. I flussi di dati offrono la più bassa latenza di dati disponibili e 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.

Per impostazione predefinita, i job di caricamento utilizzano un pool di slot condivisi. Un job di caricamento potrebbe rimanere in stato di attesa finché non sono disponibili slot, soprattutto se carichi una quantità molto elevata di dati. Se ciò crea tempi di attesa inaccettabili, può 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 non essere elevate quanto quelle 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 lo schema della tabella automaticamente in base ai dati di origine. Per i dati JSON e CSV, puoi: fornire uno schema esplicito oppure puoi usare rilevamento automatico dello schema.

  • Dati flat o campi nidificati e ripetuti. Avro, CSV, JSON, ORC e Tutti i Parquet supportano i dati piatti. Avro, JSON, ORC, Parquet e Le esportazioni di Firestore supportano anche i dati con stringhe nidificate e ripetute campi. 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 di Firestore

Per informazioni su come specificare i campi nidificati e ripetuti nello schema quando carichi i dati, consulta Specificare i 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, consulta 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.

Quote

Per informazioni sulle quote, consulta le sezioni seguenti:

Alternative al caricamento dei dati

Non è necessario caricare i dati prima di eseguire query nelle seguenti situazioni:

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 caricarli nello spazio di archiviazione BigQuery. Questo approccio consente di sfruttare le funzionalità di analisi a BigQuery senza spostare i dati archiviati altrove. Per sui vantaggi e sui limiti di questo approccio, vedi origini dati esterne.
File di logging
Cloud Logging offre un'opzione per esportare i file di log 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, consulta Metriche di BigQuery. Nello specifico, puoi monitorare la quantità di dati e il numero di righe caricate una tabella specifica. Se i job di caricamento caricano i dati in una tabella specifica, questa può essere un'entità proxy per monitorare l'utilizzo dei dati di caricamento dei job.

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

Eseguire lo streaming dei dati utilizzando l'API Storage Write

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. R architettura consigliata per mantenere questi endpoint, è l'invio di eventi a Pub/Sub, dove vengono utilizzate da una pipeline Dataflow in modalità flusso che invia flussi di dati direttamente a BigQuery.

Una delle principali preoccupazioni di affidabilità per questa architettura è come gestire gli errori per inserire 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 vedi la situazione Guida all'affidabilità di Google Pub/Sub post del blog.

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

Se sono necessarie la semantica esatta una volta e la funzionalità di commit, crea uno stream di scrittura in tipo di commit con gli offset dei record forniti dal client. In questo modo vengono evitati i duplicati, mentre viene eseguita solo se il valore di offset corrisponde all'offset dell'aggiunta successiva. Se non specifichi un offset, i record vengono aggiunti alla fine corrente della un flusso di dati e un nuovo tentativo di aggiunta non riuscita potrebbe far sì che il record venga visualizzato più di una volta nello stream.

Se non sono necessarie garanzie "exactly-once", nello stream predefinito consente una velocità effettiva più elevata e non viene inoltre conteggiata nei limite di quota sulla creazione di flussi di scrittura.

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

Se il carico di lavoro genera o elabora dati a una velocità molto non uniforme, cercare di attenuare eventuali picchi di carico sul client e trasmettere in streaming BigQuery con una velocità effettiva costante. In questo modo puoi semplificare la pianificazione delle capacità. Se ciò non è possibile, assicurati di poter gestire Errori di 429 (risorsa esaurita) 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 debba essere completata entro una scadenza fissa. I dati devono essere disponibili entro questa scadenza per essere sottoposti a 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 quello finanziario.

Il caricamento batch dei dati con i job di caricamento è l'approccio giusto per questo caso d'uso perché la latenza non è un problema, a condizione che la scadenza possa essere 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, o tutti i record vengono inseriti o nessuno lo fa. Come best practice, quando inserisci tutti i dati in un singolo un job di caricamento, crea una nuova tabella utilizzando l'istruzione WRITE_TRUNCATE di il JobConfigurationLoad risorsa. Questo è importante quando si ritenta un job di caricamento non riuscito, in quanto il client potrebbe non essere in grado di distinguere tra i job non riusciti e l'errore causato, ad esempio, dalla comunicazione dello stato di successo al client.

Supponendo che i dati da importare siano già stati copiati correttamente in Cloud Storage, riprovare con il backoff esponenziale è sufficiente per risolvere i problemi 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