Introduzione a BigQuery Omni

Con BigQuery Omni, puoi eseguire analisi di BigQuery Dati archiviati in Amazon Simple Storage Service (Amazon S3) o Azure Blob Storage utilizzando BigLake tabelle.

Molte organizzazioni archiviano i dati in più cloud pubblici. Spesso, questi dati terminano poiché è difficile ottenere insight su tutti i dati. Tu vuoi essere in grado di analizzare i dati con uno strumento per i dati multi-cloud che è economico, veloce e non crea un ulteriore sovraccarico di lavoro la governance dei dati. Utilizzando BigQuery Omni, riduciamo questi con un'interfaccia unificata.

Per eseguire l'analisi di BigQuery sui tuoi dati esterni, devi Innanzitutto, devi connetterti ad Amazon S3 o Archiviazione BLOB. Se Se vuoi eseguire query su dati esterni, devi creare un BigLake che fa riferimento ad Amazon S3 o Dati di Archiviazione BLOB.

Puoi anche spostare i dati da un cloud all'altro per combinarli tra loro utilizzando eseguire il trasferimento cross-cloud o eseguire query sui dati tra cloud utilizzando join cross-cloud. BigQuery Omni offre una soluzione di analisi cross-cloud con la capacità di analizzare i dati dove si trovano e la flessibilità di replicarli laddove necessario. Per saperne di più, consulta Caricare i dati con trasferimento cross-cloud e i join cross-cloud.

Architettura

L'architettura di BigQuery separa il computing dall'archiviazione, consentendo fare lo scale out di BigQuery in base alle esigenze per gestire carichi di lavoro di grandi dimensioni. BigQuery Omni estende questa architettura eseguendo BigQuery in altri cloud. Di conseguenza, per il trasferimento fisico dei dati nello spazio di archiviazione BigQuery. In fase di elaborazione si verificano dove i dati si trovano già.

Architettura di BigQuery Omni

I risultati della query possono essere restituiti a Google Cloud tramite una connessione sicura. ad esempio, da visualizzare nella console Google Cloud. In alternativa, puoi scrivere i risultati direttamente nei bucket Amazon S3 o nell'archiviazione BLOB. In questo caso, non c'è uno spostamento tra cloud dei risultati della query.

BigQuery Omni utilizza i ruoli AWS IAM standard o Azure Active Directory per accedere ai dati del tuo abbonamento. Delega la lettura o la scrittura a BigQuery Omni e potrai revocarlo in qualsiasi momento.

Flusso di dati durante l'esecuzione di query sui dati

L'immagine seguente descrive come si spostano i dati tra Google Cloud e AWS o Azure per le query seguenti:

  • Istruzione SELECT
  • Istruzione CREATE EXTERNAL TABLE
Spostamento di dati tra Google Cloud e AWS o Azure per le query.
Figura 1: spostamento dei dati tra Google Cloud e AWS o Azure per le query.
  1. Il piano di controllo BigQuery riceve i job di query da te tramite Console Google Cloud, strumento a riga di comando bq, metodo API o libreria client.
  2. Il piano di controllo BigQuery invia i job di query per l'elaborazione a piano dati BigQuery su AWS o Azure.
  3. Il piano dati BigQuery riceve la query dal piano di controllo attraverso una connessione VPN.
  4. Il piano dati BigQuery legge i dati della tabella Bucket Amazon S3 o archiviazione BLOB.
  5. Il piano dati BigQuery esegue il job di query sui dati della tabella. L'elaborazione dei dati della tabella avviene nella regione AWS o Azure specificata.
  6. Il risultato della query viene trasmesso dal piano dati al piano di controllo tramite la connessione VPN.
  7. Il piano di controllo BigQuery riceve i risultati del job di query per la visualizzazione in risposta al job di query. Questi dati vengono memorizzati a 24 ore.
  8. Il risultato della query ti viene restituito.

Per saperne di più, consulta Eseguire query sui dati Amazon S3 e dati di archiviazione BLOB.

Flusso di dati durante l'esportazione dei dati

L'immagine seguente descrive come si spostano i dati tra Google Cloud e AWS o Azure durante un'istruzione EXPORT DATA.

Spostamento di dati tra Google Cloud e AWS o Azure per le query di esportazione.
Figura 2: spostamento dei dati tra Google Cloud e AWS o Azure per le query di esportazione.
  1. Il piano di controllo BigQuery riceve i tuoi job di query di esportazione tramite la console Google Cloud, lo strumento a riga di comando bq, un metodo API o una libreria client. La contiene il percorso di destinazione del risultato della query Bucket Amazon S3 o archiviazione BLOB.
  2. Il piano di controllo BigQuery invia i job delle query di esportazione per l'elaborazione al piano dati BigQuery (su AWS o Azure).
  3. Il piano dati BigQuery riceve la query di esportazione dal controllo tramite la connessione VPN.
  4. Il piano dati BigQuery legge i dati della tabella Bucket Amazon S3 o archiviazione BLOB.
  5. Il piano dati BigQuery esegue il job di query sui dati della tabella. L'elaborazione dei dati della tabella avviene nella regione AWS o Azure specificata.
  6. BigQuery scrive il risultato della query nella destinazione specificata del tuo bucket Cloud Storage nel bucket Amazon S3 o BLOB.

Per saperne di più, consulta Esportare i risultati delle query in Amazon S3 e Archiviazione BLOB.

Vantaggi

Rendimento. Puoi ottenere gli approfondimenti più velocemente, perché i dati non vengono copiati e le query vengono eseguite nella stessa regione in cui si trovano i dati.

Costo. Risparmia sui costi del trasferimento di dati in uscita perché i dati spostare l'attività. Non sono previsti costi aggiuntivi per l'account AWS o Azure relativi a: BigQuery Omni Analytics, perché le query vengono eseguite sui cluster gestiti da Google. Ti viene addebitato solo il costo dell'esecuzione delle query, utilizzando Modello di determinazione dei prezzi BigQuery.

Sicurezza e governance dei dati. Puoi gestire i dati in AWS o Azure abbonamento. Non è necessario spostare o copiare i dati non elaborati dal pubblico cloud. Tutto il calcolo avviene nel multi-tenant di BigQuery che viene eseguito all'interno della stessa regione dei tuoi dati.

Architettura serverless. Come il resto di BigQuery, BigQuery Omni è un'offerta serverless. Google implementa e gestisce che eseguono BigQuery Omni. Non devi eseguire il provisioning di alcuna risorsa per gestire qualsiasi cluster.

Facilità di gestione. BigQuery Omni offre uno strumento un'interfaccia di gestione tramite Google Cloud. BigQuery Omni può utilizzare il tuo account Google Cloud e i progetti BigQuery esistenti. Tu scrivere una query GoogleSQL nella console Google Cloud per eseguire query AWS o Azure e vedere i risultati visualizzati nella console Google Cloud.

Trasferimento cross-cloud. Puoi caricare i dati in BigQuery standard da bucket S3 e da archiviazione BLOB. Per ulteriori informazioni, vedi Trasferire i dati di Amazon S3 e Dati di Archiviazione BLOB in BigQuery.

Memorizzazione nella cache dei metadati per migliorare le prestazioni

Puoi utilizzare i metadati memorizzati nella cache per migliorare le prestazioni delle query su Tabelle BigLake che fanno riferimento ai dati Amazon S3. È particolarmente utile nei casi in cui lavorare con grandi quantità di file o se i dati sono hive partizionati.

I metadati includono nomi di file, informazioni di partizionamento e dati metadati da file, come i conteggi delle righe. Puoi scegliere se attivare o meno per la memorizzazione nella cache dei metadati su una tabella. Query con un numero elevato di file e con Hive i filtri di partizione traggono il massimo vantaggio dalla memorizzazione nella cache dei metadati.

Se non abiliti la memorizzazione nella cache dei metadati, le query sulla tabella devono leggere un'origine dati esterna per ottenere metadati degli oggetti. La lettura di questi dati aumenta latenza delle query; l'elenco di milioni di file dall'origine dati esterna può richiedere diversi minuti. Se attivi la memorizzazione nella cache dei metadati, le query possono evitare di elencare i file dall'origine dati esterna e può eseguire il partizionamento ed eliminare i file più rapidamente.

Esistono due proprietà che controllano questa funzionalità:

  • Massima obsolescenza: specifica quando le query utilizzano i metadati memorizzati nella cache.
  • La modalità cache dei metadati specifica in che modo vengono raccolti i metadati.

Se hai abilitato la memorizzazione nella cache dei metadati, specifichi l'intervallo massimo l'inattività dei metadati accettabile per le operazioni sulla tabella. Per Ad esempio, se specifichi un intervallo di 1 ora, verranno eseguite le operazioni utilizzare i metadati memorizzati nella cache se sono stati aggiornati nell'ultima ora. Se la copia cache I metadati sono più vecchi di questo valore, l'operazione torna al recupero da con Amazon S3. Puoi specificare un intervallo di inattività compreso tra 30 minuti e 7 giorni.

Puoi scegliere di aggiornare la cache automaticamente o manualmente:

  • Per gli aggiornamenti automatici, la cache viene aggiornata a un criterio definito dal sistema intervallo, solitamente compreso tra 30 e 60 minuti. Aggiornamento di Cache è un buon approccio se i file Amazon S3 vengono aggiunti, eliminati o modificati a caso intervalli. Se devi controllare la tempistica dell'aggiornamento, ad esempio per per attivare l'aggiornamento al termine di un job di estrazione, trasformazione e caricamento, utilizzando aggiornamento manuale.

  • Per gli aggiornamenti manuali, esegui Sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE procedura per aggiornare la cache dei metadati in base a una pianificazione che soddisfi i tuoi requisiti. Aggiornare manualmente la cache è un buon approccio se i file Amazon S3 vengono aggiunti, eliminati o modificati a intervalli noti come output di una pipeline.

    Se emetti più aggiornamenti manuali simultanei, solo uno avrà esito positivo.

Se non viene aggiornata, la cache dei metadati scade dopo 7 giorni.

Sia gli aggiornamenti manuali che quelli automatici della cache vengono eseguiti con Priorità delle query INTERACTIVE.

Se scegli di utilizzare gli aggiornamenti automatici, ti consigliamo di creare una reservation (prenotazione), quindi creare una compito con un tipo di prestazione BACKGROUND per il progetto che esegue i job di aggiornamento della cache dei metadati. In questo modo aggiornare i job rispetto alla concorrenza con le query degli utenti per le risorse, e potrebbero non riuscire se non sono disponibili risorse sufficienti.

È necessario considerare come l'intervallo di inattività e la modalità di memorizzazione nella cache dei metadati interagiscono prima di impostarli. Considera i seguenti esempi:

  • Se aggiorni manualmente la cache dei metadati per una tabella e imposti l'intervallo di inattività a 2 giorni, devi eseguire BQ.REFRESH_EXTERNAL_METADATA_CACHE procedura di sistema ogni 2 giorni o meno se vuoi che le operazioni sulla tabella utilizzino i metadati memorizzati nella cache.
  • Se aggiorni automaticamente la cache dei metadati per una tabella impostare l'intervallo di inattività su 30 minuti, è possibile che alcuni dei tuoi operazioni sulla tabella potrebbero leggere Amazon S3 se l'aggiornamento della cache dei metadati richiede più tempo rispetto al solito finestra di 30-60 minuti.

Per trovare informazioni sui job di aggiornamento dei metadati, esegui una query INFORMATION_SCHEMA.JOBS visualizzazione, come mostrato nell'esempio seguente:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Per maggiori informazioni, consulta Memorizzazione nella cache dei metadati.

Tabelle abilitate per la cache con viste materializzate

Puoi utilizzare viste materializzate su metadati Amazon Simple Storage Service (Amazon S3) abilitati per la cache tabelle per migliorare le prestazioni e l'efficienza dell'esecuzione di query su dati strutturati Amazon S3. Queste viste materializzate funzionano come le viste materializzate rispetto alle tabelle di archiviazione gestite da BigQuery, con i relativi vantaggi aggiornamento automatico e ottimizzazione intelligente.

Per rendere disponibili i dati Amazon S3 in una vista materializzata in un regione BigQuery supportata per i join, creando una replica della vista materializzata. Puoi creare repliche delle vista materializzata solo visualizzazioni di materiali autorizzate.

Limitazioni

Oltre alle limitazioni per le tabelle BigLake, si applicano le seguenti limitazioni BigQuery Omni, che include tabelle basate su BigLake su dati Amazon S3 e Blob Storage:

  • Lavorare con i dati in BigQuery Omni regioni non è supportata Versioni Enterprise Plus. Per ulteriori informazioni sulle versioni, consulta Introduzione a Versioni di BigQuery.
  • OBJECT_PRIVILEGES, STREAMING_TIMELINE_BY_*, TABLE_SNAPSHOTS, TABLE_STORAGE, TABLE_CONSTRAINTS, KEY_COLUMN_USAGE CONSTRAINT_COLUMN_USAGE e PARTITIONS INFORMATION_SCHEMA visualizzazioni non sono disponibili per le tabelle BigLake in base Dati di Amazon S3 e Archiviazione BLOB.
  • Le viste materializzate non sono supportate per l'archiviazione BLOB.
  • Le funzioni JavaScript definite dall'utente non sono supportate.

  • Le seguenti istruzioni SQL non sono supportate:

  • Le seguenti limitazioni si applicano all'esecuzione di query e alla lettura temporanea della destinazione (anteprima):

    • L'esecuzione di query sulle tabelle temporanee di destinazione con l'istruzione SELECT non è supportati.
    • Utilizzare l'API BigQuery Storage Read per leggere i dati delle tabelle temporanee di destinazione non sono supportati.
    • Quando utilizzi il driver ODBC, letture a velocità effettiva elevata (opzione EnableHTAPI) non supportate.

  • Query pianificate sono supportati solo tramite il metodo API o interfaccia a riga di comando. La tabella di destinazione è disabilitata per le query. Sono consentite solo EXPORT DATA query.

  • L'API BigQuery Storage non è disponibile nelle regioni di BigQuery Omni.

  • Se la query utilizza la clausola ORDER BY e ha una dimensione dei risultati superiore a 256 MB, la query avrà esito negativo. Per risolvere il problema, riduci il risultato o rimuovi la clausola ORDER BY dalla query. Per ulteriori informazioni sulle quote di BigQuery Omni, consulta Quote e limiti.

  • Utilizzo delle chiavi di crittografia gestite dal cliente (CMEK) con set di dati e servizi non è supportato.

Prezzi

Per informazioni su prezzi e offerte a tempo limitato in Consulta Prezzi di BigQuery Omni.

Quote e limiti

Per informazioni sulle quote di BigQuery Omni, consulta Quote e limiti.

Se il risultato della query è superiore di 20 GiB, valuta la possibilità di esportare i risultati su Amazon S3 o Blob Storage. Per saperne di più sulle quote per l'API BigQuery Connection, consulta API BigQuery Connection.

Località

Processi BigQuery Omni nella stessa posizione del set di dati che contiene le tabelle che stai l'esecuzione di query. Dopo aver creato il set di dati, la località non può essere modificata. Il tuo i dati risiedono all'interno del tuo account AWS o Azure. Regioni di BigQuery Omni supportare le prenotazioni della versione Enterprise e il computing on demand (analisi) pricing. Per ulteriori informazioni sulle versioni, vedi Introduzione alle versioni di BigQuery.
Descrizione regione Nome regione Regione BigQuery assegnata
AWS
AWS - Stati Uniti orientali (Virginia del Nord) aws-us-east-1 us-east4
AWS - Stati Uniti occidentali (Oregon) aws-us-west-2 us-west1
AWS - Asia Pacifico (Seul) aws-ap-northeast-2 asia-northeast3
AWS - Asia Pacifico (Sydney) aws-ap-southeast-2 australia-southeast1
AWS - Europa (Irlanda) aws-eu-west-1 europe-west1
AWS - Europa (Francoforte) aws-eu-central-1 europe-west3
Azure
Azure - Stati Uniti orientali 2 azure-eastus2 us-east4

Passaggi successivi