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

  • Job di caricamento. 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 applicazioni e servizi di terze parti.
  • API BigQuery StorageWrite. L'API Storage Scrivi ti consente elaborare in batch un numero arbitrariamente elevato di record e eseguirne il commit in una una singola 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 un datastore esterno e importarlo in BigQuery. Ad esempio: puoi caricare i dati dalle esportazioni di Firestore.

Quando si sceglie un metodo di caricamento in batch, la maggior parte dei pattern basati su file deve utilizzare uno dei seguenti load job o LOAD DATAistruzione SQL per caricare i dati in batch. Gli altri servizi usano BigQuery Data Transfer Service o esportano 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 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. Opzioni per lo streaming in BigQuery include:

  • API StorageWrite. L'API StorageWrite supporta l'importazione di flussi di dati a velocità effettiva elevata con distribuzione "exactly-once" la semantica.
  • Dataflow. Utilizza Dataflow con SDK Apache Beam per configurare una pipeline di flusso che scrive in BigQuery. Per ulteriori informazioni, vedi Connettore BigQuery I/O nella documentazione di Apache Beam e nel tutorial sul flusso di dati da Pub/Sub a BigQuery.
  • Datastream. Datastream utilizza la funzionalità 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 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 Guida alla pianificazione di BigQuery Connector per SAP.
  • Pub/Sub. Pub/Sub è un servizio di 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:

  • 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 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 un o scrivere in una nuova tabella. Per ulteriori informazioni, vedi Scrittura dei 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 dati da origini esterne puoi usare Informatica Data Loader o Fivetran Data Pipelines. Per ulteriori informazioni, vedi 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 le seguenti punti:

  • Se BigQuery Data Transfer Service supporta l'origine dati, il trasferimento dei dati direttamente in BigQuery potrebbe essere la soluzione più 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 quasi in tempo reale, valuta la possibilità di trasmetterli in flussi. Con i flussi di dati, i dati vengono disponibile per l'esecuzione di query non appena arriva ogni record. Evita di utilizzare DML. per inviare un numero elevato di singoli aggiornamenti o inserimenti di righe. Per aggiornati di frequente, spesso è preferibile trasmettere in streaming un log delle modifiche e utilizzare per ottenere gli ultimi risultati. Un'altra opzione è quella di 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 devi aggiornarli 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 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 livello di servizio di Google (SLA). Tuttavia, devi considerare anche l'affidabilità della soluzione specifica che implementi. Considera le seguenti punti:

  • Con i formati a basso livello come JSON o CSV, i dati non validi possono rendere un'intera del job di caricamento non riuscito. Valuta se ti serve una fase di pulizia dei dati prima caricamento e valutare come rispondere agli errori. Inoltre, valuta la possibilità di utilizzare con caratteri di forte impatto 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 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 non riusciti in una coda di messaggi non elaborati per analisi ed elaborazioni successive. 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 dei problemi relativi alle quote 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ù alta perché i nuovi dati vengono disponibili al termine di ogni job di caricamento.

I job di caricamento utilizzano un pool condiviso di slot per impostazione predefinita. 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 ciò crea tempi di attesa inaccettabili, può acquistare slot dedicati, anziché utilizzare il pool di slot condiviso. Per ulteriori informazioni le informazioni, vedi 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 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 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 prevede l'utilizzo del formato delimitato da nuova riga file JSON in modo che contengano un singolo record per riga.

  • Codifica. BigQuery supporta la codifica UTF-8 per nidificati o ripetuti e dati fissi. 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 campi nidificati e ripetuti nello schema quando carichi i dati, controlla Specifica dei campi nidificati e ripetuti.

Carica dati da altri servizi Google

Alcuni servizi Google esportano dati in BigQuery utilizzando per eseguire 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 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 archiviati in BigQuery e condivisi con per il pubblico. Per ulteriori informazioni, vedi Set di dati pubblici 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 capacità di analisi a BigQuery senza spostare i dati archiviati altrove. Per sui vantaggi e i limiti di questo approccio, vedi origini dati esterne.
File di logging
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 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 usare 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 per utilizzarle 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 questo caso d'uso, API Storage Scrivi è 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.

Uno dei principali problemi di affidabilità di 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. La documentazione di un veleno è 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, 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.

Stimare la velocità effettiva della rete e assicurarti in anticipo di disporre di una quota adeguata per gestire la velocità effettiva.

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. Questo può semplificare e la pianificazione della 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 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 un'ulteriore elaborazione 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, o tutti i record o non farlo. 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 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.

Presupponendo 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 il quota predefinita di 1500 caricamenti per tabella al giorno,anche con nuovi tentativi. 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