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, perché è difficile ottenere insight su tutti i dati. Vuoi essere in grado di analizzare i dati con uno strumento per i dati multi-cloud che sia economico, veloce e che non crei un ulteriore overhead per la governance dei dati decentralizzata. Grazie a BigQuery Omni, possiamo ridurre questi problemi grazie a un'interfaccia unificata.

Per eseguire l'analisi di BigQuery sui dati esterni, devi prima connetterti ad Amazon S3 o 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 tra loro utilizzando il trasferimento cross-cloud o eseguire query sui dati tra più cloud utilizzando i join 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 replicare i dati quando necessario. Per ulteriori informazioni, consulta Caricare i dati con trasferimento cross-cloud e join cross-cloud.

Architettura

L'architettura di BigQuery separa il computing dall'archiviazione, consentendo a BigQuery di fare lo scale 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 nell'archiviazione BLOB. In questo caso, non c'è uno spostamento tra cloud dei risultati della query.

BigQuery Omni utilizza i ruoli IAM standard di AWS o le entità di Azure Active Directory per accedere ai dati dell'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 come si spostano i dati tra Google Cloud e AWS o Azure per le seguenti query:

  • 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 tuoi 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 BigQuery invia i job di query per l'elaborazione al piano dati 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 BigQuery legge i dati della tabella dal bucket Amazon S3 o dall'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 mostrarteli in risposta al job di query. Questi dati rimangono archiviati per un massimo di 24 ore.
  8. Il risultato della query ti viene restituito.

Per maggiori informazioni, consulta Eseguire query sui dati di Amazon S3 e sull'archiviazione dei 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 ti riceve i job di esportazione delle query 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 del risultato della query nel bucket Amazon S3 o nell'archiviazione BLOB.
  2. Il piano di controllo BigQuery invia job di 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 piano di controllo tramite la connessione VPN.
  4. Il piano dati BigQuery legge i dati della tabella dal bucket Amazon S3 o dall'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 nel percorso di destinazione specificato nel bucket Amazon S3 o nell'archiviazione BLOB.

Per maggiori informazioni, vedi Esportare i risultati delle query in Amazon S3 e Archiviazione BLOB.

Vantaggi

Rendimento. Puoi ottenere insight più rapidamente perché i dati non vengono copiati tra cloud 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 non vengono spostati. Non sono previsti costi aggiuntivi per l'account AWS o Azure relativi all'analisi di BigQuery Omni, perché le query vengono eseguite sui cluster gestiti da Google. Ti viene addebitato solo il costo per l'esecuzione delle query, utilizzando il modello di prezzi di BigQuery.

Sicurezza e governance dei dati. Puoi gestire i dati nella tua sottoscrizione AWS o Azure. Non è necessario spostare o copiare i dati non elaborati dal cloud pubblico. Il calcolo avviene nel servizio multi-tenant di BigQuery, che viene eseguito all'interno della stessa regione dei dati.

Architettura serverless. Come il resto di BigQuery, BigQuery Omni è un'offerta serverless. Google esegue il deployment e gestisce i cluster che eseguono BigQuery Omni. Non devi eseguire il provisioning di alcuna risorsa o gestire i cluster.

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

Trasferimento cross-cloud. Puoi caricare i dati in tabelle BigQuery standard dai bucket S3 e dall'archiviazione BLOB. Per maggiori informazioni, vedi Trasferire i dati di Amazon S3 e i 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 sulle tabelle BigLake che fanno riferimento ai dati Amazon S3. È particolarmente utile nei casi in cui si lavora con grandi numeri di file o se i dati sono hive partizionati.

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

Se non abiliti la memorizzazione nella cache dei metadati, le query nella tabella devono leggere l'origine dati esterna per ottenere i metadati degli oggetti, il che aumenta la latenza delle query; elencare milioni di file dall'origine dati esterna può richiedere diversi minuti. Se abiliti la memorizzazione nella cache dei metadati, le query possono evitare di elencare i file dall'origine dati esterna e accelerare l'eliminazione delle partizioni e dei file.

Esistono due proprietà che controllano questa funzionalità:

  • Massima inattività, che determina quando le query utilizzano i metadati memorizzati nella cache.
  • Modalità cache dei metadati, che controlla il modo in cui vengono raccolti i metadati.

Se hai abilitato la memorizzazione nella cache dei metadati, specifichi l'intervallo massimo di inattività dei metadati accettabile per le operazioni sulla tabella. Ad esempio, se specifichi un intervallo di 1 ora, le operazioni eseguite sulla tabella utilizzano i metadati memorizzati nella cache se sono stati aggiornati nell'ultima ora. Se i metadati memorizzati nella cache sono più vecchi, l'operazione utilizza il 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, solitamente compreso 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 casuali. Se devi controllare la tempistica dell'aggiornamento, ad esempio per attivare l'aggiornamento al termine 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 emetti più aggiornamenti manuali simultanei, solo uno avrà esito positivo.

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

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

  • Se aggiorni manualmente la cache dei metadati per una tabella e imposti l'intervallo di inattività su due giorni, devi eseguire la procedura di sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE ogni due 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 e imposti 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 dura più a lungo della consueta finestra di 30-60 minuti.

Per trovare informazioni sui job di aggiornamento dei metadati, esegui una query sulla vista 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 maggiori informazioni, consulta Memorizzazione nella cache dei metadati.

Tabelle abilitate per la cache con viste materializzate

Puoi utilizzare le viste materializzate su tabelle di metadati Amazon Simple Storage Service (Amazon S3) abilitate per la cache 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, compresi i vantaggi dell'aggiornamento automatico e dell'ottimizzazione intelligente.

Per rendere disponibili i dati Amazon S3 in una vista materializzata in una regione BigQuery supportata per i join, crea una replica della vista materializzata. Puoi creare repliche delle vista materializzata solo sulle viste dei materiali autorizzate.

Limitazioni

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

  • L'utilizzo dei dati in una delle regioni di BigQuery Omni non è supportato dalle versioni Standard ed Enterprise Plus. Per ulteriori informazioni sulle versioni, consulta Introduzione alle versioni di BigQuery.
  • Le viste 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 sui dati Amazon S3 e Blob Storage.
  • 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 delle tabelle temporanee di destinazione (anteprima):

    • L'esecuzione di query su tabelle temporanee di destinazione con l'istruzione SELECT non è supportata.
    • Non è supportato l'utilizzo dell'API BigQuery Storage Read per leggere i dati dalle tabelle temporanee di destinazione.
    • Quando si utilizza il driver ODBC, le letture a velocità effettiva elevata (opzione EnableHTAPI) non sono supportate.

  • Le query pianificate sono supportate solo tramite il metodo API o interfaccia a riga di comando. L'opzione 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 non va a buon fine. Per risolvere il problema, riduci la dimensione dei risultati o rimuovi la clausola ORDER BY dalla query. Per saperne di più sulle quote di BigQuery Omni, consulta Quote e limiti.

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

Prezzi

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

Quote e limiti

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

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

Località

BigQuery Omni elabora le query nella stessa località del set di dati che contiene le tabelle su cui esegui le query. Dopo aver creato il set di dati, la località non può essere modificata. I dati si trovano all'interno del tuo account AWS o Azure. Le regioni di BigQuery Omni supportano le prenotazioni della versione Enterprise e i prezzi di computing on demand (analisi). Per ulteriori informazioni sulle versioni, consulta 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