Introduzione a BigQuery Omni

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

Molte organizzazioni archiviano i dati in più cloud pubblici. Spesso questi dati finiscono per essere isolati in silos, perché è difficile ottenere insight trasversali su tutti i dati. Vuoi essere in grado di analizzare i dati con uno strumento di dati multicloud che sia economico, veloce e non crei un overhead aggiuntivo della governance dei dati decentralizzata. Con BigQuery Omni, riduciamo queste difficoltà con un'interfaccia unificata.

Per eseguire analisi BigQuery sui tuoi dati esterni, devi prima connetterti ad Amazon S3 o ad Archiviazione BLOB. Se vuoi eseguire query su dati esterni, devi creare una tabella BigLake che faccia riferimento ai dati di Amazon S3 o Blob Storage.

Puoi anche spostare i dati da un cloud all'altro per combinarli utilizzando il trasferimento cross-cloud o eseguire query sui dati su più cloud utilizzando le unioni cross-cloud. BigQuery Omni offre una soluzione di analisi cross-cloud con la possibilità di analizzare i dati dove si trovano e la flessibilità di replicarli se necessario. Per ulteriori informazioni, consulta Caricare i dati con il trasferimento tra cloud e Unione tra cloud.

Architettura

L'architettura di BigQuery separa il calcolo dall'archiviazione, consentendo a BigQuery di eseguire lo scaling out in base alle esigenze per gestire carichi di lavoro molto grandi. BigQuery Omni estende questa architettura eseguendo il motore di query BigQuery in altri cloud. Di conseguenza, non devi spostare fisicamente i dati nello spazio di archiviazione BigQuery. L'elaborazione avviene dove si trovano già i dati.

Architettura di BigQuery Omni

I risultati delle query possono essere restituiti a Google Cloud tramite una connessione sicura, ad esempio per essere visualizzati nella console Google Cloud. In alternativa, puoi scrivere i risultati direttamente nei bucket Amazon S3 o Blob Storage. In questo caso, i risultati della query non vengono spostati tra i cloud.

BigQuery Omni utilizza i ruoli IAM AWS o i principali di Azure Active Directory standard per accedere ai dati del tuo abbonamento. Puoi delegare l'accesso in lettura o scrittura a BigQuery Omni e revocarlo in qualsiasi momento.

Flusso di dati durante l'esecuzione di query sui dati

L'immagine seguente descrive il flusso dei dati tra Google Cloud e AWS o Azure per le seguenti query:

  • SELECT dichiarazione
  • CREATE EXTERNAL TABLE dichiarazione
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 di BigQuery riceve i job di query tramite la console Google Cloud, lo strumento a riga di comando bq, un metodo API o una libreria client.
  2. Il piano di controllo di BigQuery invia i job di query per l'elaborazione al piano di dati di BigQuery su AWS o Azure.
  3. Il piano dati BigQuery riceve la query dal piano di controllo tramite una connessione VPN.
  4. Il piano dati di BigQuery legge i dati delle tabelle dal tuo bucket Amazon S3 o da Blob Storage.
  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 di dati al piano di controllo tramite la connessione VPN.
  7. Il piano di controllo BigQuery riceve i risultati del job di query da mostrare in risposta al job di query. Questi dati vengono memorizzati per un massimo di 24 ore.
  8. Il risultato della query viene restituito.

Per ulteriori informazioni, consulta Eseguire query sui dati di Amazon S3 e Dati di Blob Storage.

Flusso di dati durante l'esportazione dei dati

L'immagine seguente descrive il flusso dei dati tra Google Cloud e AWS o Azure durante un'istruzione EXPORT DATA.

Spostamento dei 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 di BigQuery riceve i 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 query contiene il percorso di destinazione per il risultato della query nel bucket Amazon S3 o in Blob Storage.
  2. Il piano di controllo di BigQuery invia i job di query di esportazione per l'elaborazione al piano di dati di BigQuery (su AWS o Azure).
  3. Il piano dati BigQuery riceve la query di esportazione dal piano di controllo tramite la connessione VPN.
  4. Il piano dati di BigQuery legge i dati delle tabelle dal tuo bucket Amazon S3 o da Blob Storage.
  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 nel percorso di destinazione specificato nel bucket Amazon S3 o in Blob Storage.

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

Vantaggi

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

Cost. Risparmi sui costi di trasferimento di dati in uscita perché i dati non si muovono. Non sono previsti costi aggiuntivi per il tuo account AWS o Azure relativi all'analisi di BigQuery Omni, perché le query vengono eseguite su cluster gestiti da Google. Ti viene addebitato solo l'utilizzo delle query, in base al modello di prezzo di BigQuery.

Sicurezza e governance dei dati. Gestisci i dati nel tuo abbonamento AWS o Azure. Non è necessario spostare o copiare i dati non elaborati dal cloud pubblico. Tutti i calcoli vengono eseguiti nel servizio multi-tenant BigQuery, che viene eseguito nella stessa regione dei dati.

Architettura serverless. Come il resto di BigQuery, BigQuery Omni è un'offerta serverless. Google esegue il deployment e la gestione dei cluster che eseguono BigQuery Omni. Non è necessario eseguire il provisioning di risorse o gestire cluster.

Facilità di gestione. BigQuery Omni fornisce un'interfaccia di gestione unificata tramite Google Cloud. BigQuery Omni può utilizzare il tuo account Google Cloud esistente e i tuoi progetti BigQuery. Puoi scrivere una query GoogleSQL nella console Google Cloud per eseguire query sui dati in AWS o Azure e visualizzare i risultati nella console Google Cloud.

Trasferimento cross-cloud. Puoi caricare i dati nelle tabelle BigQuery standard da bucket S3 e Archiviazione blob. Per ulteriori informazioni, consulta Trasferire i dati di Amazon S3 e Trasferire i dati di Archiviazione BLOB in BigQuery.

Memorizzazione nella cache dei metadati per le prestazioni

Puoi utilizzare i metadati memorizzati nella cache per migliorare le prestazioni delle query sulle tabelle BigLake che fanno riferimento ai dati di Amazon S3. È particolarmente utile nei casi in cui si lavora con un numero elevato di file o se i dati sono partizionati in Hive.

I metadati includono nomi di file, informazioni sulla partizione e metadati fisici di file come i conteggi delle righe. Puoi scegliere se attivare o meno la memorizzazione nella cache dei metadati in una tabella. Le query con un numero elevato di file e con filtri di partizione Hive traggono il massimo vantaggio dalla memorizzazione nella cache dei metadati.

Se non attivi la memorizzazione nella cache dei metadati, le query sulla tabella devono leggere l'origine dati esterna per recuperare i metadati dell'oggetto. La lettura di questi dati aumenta la 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 possono partizionare e potare i file più rapidamente.

Esistono due proprietà che controllano questa funzionalità:

  • Anticipo massimo specifica quando le query utilizzano i metadati memorizzati nella cache.
  • La modalità della cache dei metadati specifica la modalità di raccolta dei metadati.

Quando la memorizzazione nella cache dei metadati è attivata, specifica l'intervallo massimo di vetustà dei metadati accettabile per le operazioni sulla tabella. Ad esempio, se specifichi un intervallo di 1 ora, le operazioni sulla tabella utilizzano i metadati memorizzati nella cache se sono stati aggiornati nell'ora precedente. Se i metadati memorizzati nella cache sono precedenti a questa data, l'operazione passa al recupero dei metadati da 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 intervallo definito dal sistema, in genere tra 30 e 60 minuti. L'aggiornamento automatico della cache è un buon approccio se i file in Amazon S3 vengono aggiunti, eliminati o modificati a intervalli random. Se devi controllare la tempistica dell'aggiornamento, ad esempio per attivarlo alla fine di un job di estrazione, trasformazione e caricamento, utilizza l'aggiornamento manuale.

  • Per gli aggiornamenti manuali, devi eseguire la procedura di sistema di BQ.REFRESH_EXTERNAL_METADATA_CACHE per aggiornare la cache dei metadati in base a una pianificazione che soddisfi i tuoi requisiti. L'aggiornamento manuale della cache è un buon approccio se i file in Amazon S3 vengono aggiunti, eliminati o modificati a intervalli noti, ad esempio come output di una pipeline.

    Se esegui più aggiornamenti manuali simultanei, ne verrà completato solo uno.

La cache dei metadati scade dopo 7 giorni se non viene aggiornata.

Gli aggiornamenti manuali e automatici della cache vengono eseguiti con priorità query INTERACTIVE.

Se scegli di utilizzare gli aggiornamenti automatici, ti consigliamo di creare una prenotazione e poi un assegnazione con un tipo di job BACKGROUND per il progetto che esegue i job di aggiornamento della cache dei metadati. In questo modo, i job di aggiornamento non competono con le query degli utenti per le risorse e non rischiano di non riuscire se non sono disponibili risorse sufficienti.

Prima di impostarli, devi considerare in che modo interagiranno i valori dell'intervallo di inattività e della modalità di memorizzazione nella cache dei metadati. Considera gli esempi seguenti:

  • Se aggiorni manualmente la cache dei metadati di una tabella e imposti l'intervallo di inattività su 2 giorni, devi eseguire la procedura di sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE 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 di una tabella e impostato l'intervallo di inattività su 30 minuti, è possibile che alcune operazioni sulla tabella vengano lette da Amazon S3 se l'aggiornamento della cache dei metadati richiede più tempo rispetto al consueto intervallo di 30-60 minuti.

Per trovare informazioni sui job di aggiornamento dei metadati, esegui una query sulla visualizzazione INFORMATION_SCHEMA.JOBS, 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 ulteriori informazioni, consulta la sezione Memorizzazione nella cache dei metadati.

Tabelle con cache abilitata con viste materializzate

Puoi utilizzare le visualizzazioni tabelle materializzate su tabelle con cache dei metadati di Amazon Simple Storage Service (Amazon S3) per migliorare le prestazioni e l'efficienza quando esegui query sui dati strutturati archiviati in Amazon S3. Queste viste materializzate funzionano come le viste materializzate sulle tabelle di archiviazione gestite da BigQuery, inclusi i vantaggi dell'aggiornamento automatico e dell'ottimizzazione intelligente.

Per rendere disponibili i dati di Amazon S3 in una vista materializzata in una regione BigQuery supportata per le unioni, crea una replica della vista materializzata. Puoi creare repliche di vista materializzata solo su viste di materiali autorizzate.

Limitazioni

Oltre ai limiti per le tabelle BigLake, si applicano i seguenti limiti a BigQuery Omni, che include le tabelle BigLake basate su dati di Amazon S3 e Archiviazione BLOB:

  • Il lavoro con i dati in una delle regioni BigQuery Omni non è supportato dalle versioni Standard ed Enterprise Plus. Per ulteriori informazioni sulle versioni, consulta Introduzione alle versioni di BigQuery.
  • Le visualizzazioni OBJECT_PRIVILEGES, STREAMING_TIMELINE_BY_*, TABLE_SNAPSHOTS, TABLE_STORAGE, TABLE_CONSTRAINTS, KEY_COLUMN_USAGE, CONSTRAINT_COLUMN_USAGE e PARTITIONS INFORMATION_SCHEMA non sono disponibili per le tabelle BigLake basate su dati di Amazon S3 e Archiviazione BLOB.
  • Le viste materializzate non sono supportate per Blob Storage.
  • Le funzioni UDF JavaScript non sono supportate.

  • Le seguenti istruzioni SQL non sono supportate:

  • Alle query e alla lettura delle tabelle temporanee di destinazione (anteprima) si applicano le seguenti limitazioni:

    • Le query sulle tabelle temporanee di destinazione con l'istruzione SELECT non sono supportate.
    • L'utilizzo dell'API BigQuery Storage Read per leggere i dati dalle tabelle temporanee di destinazione non è supportato.
    • Quando utilizzi il driver ODBC, le letture ad alto rendimento (opzione EnableHTAPI) non sono supportate.

  • Le query pianificate sono supportate solo tramite il metodo API o CLI. L'opzione tabella di destinazione è disattivata per le query. Sono consentite solo query EXPORT DATA.

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

  • Se la query utilizza la clausola ORDER BY e ha dimensioni dei risultati superiori a 256 MB, la query non va a buon fine. Per risolvere il problema, riduci le dimensioni del risultato o rimuovi la clausola ORDER BY dalla query. Per ulteriori informazioni sulle quote di BigQuery Omni, consulta Quote e limiti.

  • L'utilizzo delle chiavi di crittografia gestite dal cliente (CMEK) con set di dati e tavole esterne non è supportato.

Prezzi

Per informazioni sui prezzi e sulle offerte a tempo limitato in BigQuery Omni, consulta la pagina Prezzi di BigQuery Omni.

Quote e limiti

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

Se il risultato della query è più grande di 20 GiB, ti consigliamo di esportarlo in Amazon S3 o Blob Storage. Per informazioni sulle quote per l'API BigQuery Connection, consulta API BigQuery Connection.

Località

BigQuery Omni elabora le query nella stessa posizione del set di dati contenente le tabelle su cui stai eseguendo query. Dopo aver creato il set di dati, la posizione non può essere modificata. I tuoi dati si trovano nel tuo account AWS o Azure. Le regioni BigQuery Omni supportano le prenotazioni della versione Enterprise e i prezzi del calcolo (analisi) on demand. Per ulteriori informazioni sulle versioni, consulta Introduzione alle versioni di BigQuery.
Descrizione della regione Nome regione Regione BigQuery in co-locazione
AWS
AWS - Stati Uniti, costa orientale (Virginia del Nord) aws-us-east-1 us-east4
AWS - US West (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