Introduzione alle tabelle BigLake

Questo documento fornisce una panoramica di BigLake e presuppone familiarità con le tabelle di database e Identity and Access Management (IAM). Per eseguire query sui dati archiviati nei datastore supportati, devi prima creare tabelle BigLake ed eseguire query utilizzando la sintassi GoogleSQL:

Puoi anche eseguire l'upgrade di una tabella esterna a BigLake. Per ulteriori informazioni, consulta Eseguire l'upgrade di una tabella esterna a BigLake.

Le tabelle BigLake consentono di eseguire query su dati strutturati datastore esterni con delega di accesso. La delega dell'accesso consente di disaccoppiare l'accesso alla tabella BigLake dall'accesso all'archivio dati sottostante. Per connettersi allo spazio dati viene utilizzata una connessione esterna associata a un account di servizio. Poiché l'account di servizio gestisce il recupero dei dati dallo spazio di archiviazione dei dati, devi solo concedere agli utenti l'accesso alla tabella BigLake. In questo modo puoi applicare una sicurezza granulare a livello di tabella, a livello di riga e sicurezza a livello di colonna. Per le tabelle BigLake basate su Cloud Storage, puoi anche utilizzare il mascheramento dei dati dinamico. Per scoprire di più sulle soluzioni di analisi multi-cloud che utilizzano le tabelle BigLake con i dati di Amazon S3 o Archiviazione BLOB, consulta BigQuery Omni.

Datastore supportati

Puoi utilizzare le tabelle BigLake con i seguenti datastore:

Supporto delle tabelle temporanee

Le tabelle BigLake basate su Cloud Storage possono essere temporanee o permanenti. Le tabelle BigLake basate su Amazon S3 o Archiviazione blob devono essere permanenti.

Più file di origine

Puoi creare una tabella BigLake basata su più dati esterni a patto che abbiano lo stesso schema.

Unioni tra cloud

Le unioni tra cloud ti consentono di eseguire query che interessano sia le regioni Google Cloud sia quelle BigQuery Omni. Puoi utilizzare la modalità Operazioni di GoogleSQL JOIN per analizzare i dati in molte soluzioni di archiviazione diverse, come AWS, Azure set di dati pubblici e altri servizi Google Cloud. Join cross-cloud elimina la necessità di copiare i dati da più origini prima di eseguire query.

Puoi fare riferimento alle tabelle BigLake in qualsiasi punto di un'istruzione SELECT come se fossero tabelle BigQuery standard, incluse DML (Data Manipulation Language) e Data Definition Language (DDL) dichiarazioni che e usare sottoquery per recuperare i dati. Puoi utilizzare più tabelle BigLake da cloud diversi e tabelle BigQuery nella stessa query. Tutte le tabelle BigQuery devono essere della stessa regione.

Autorizzazioni richieste per join tra cloud

Per ottenere le autorizzazioni necessarie per eseguire un join tra cloud, chiedi all'amministratore di concederti Ruolo IAM Editor dati BigQuery (roles/bigquery.dataEditor) nel progetto in cui viene eseguito il join. Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Questo ruolo predefinito contiene le autorizzazioni necessarie per eseguire un'unione tra cloud. Per visualizzare le autorizzazioni esatte richieste, espandi la sezione Autorizzazioni richieste:

Autorizzazioni obbligatorie

Per eseguire un join tra cloud sono necessarie le seguenti autorizzazioni:

  • bigquery.datasets.create
  • bigquery.tables.create

Potresti anche riuscire a ottenere queste autorizzazioni con ruoli personalizzati altri ruoli predefiniti.

I join tra cloud creano set di dati con il prefisso __bigquery_xregion_sink_ e tabelle temporanee all'interno di questi set di dati, in modo da concedere solo l'accesso alle risorse creati dai join tra cloud, utilizza Condizione resource.name.startsWith per i tipi di risorsa Table e Dataset.

Per saperne di più sui ruoli e sulle autorizzazioni IAM in BigQuery, consulta Introduzione a IAM.

Costi delle unioni tra cloud

Quando esegui un'operazione di join tra cloud, BigQuery analizza query in parti locali e remote. La parte locale viene trattata come una query standard nella regione BigQuery. La parte remota viene convertita in CREATE TABLE AS SELECT (CTAS) sulla risorsa a cui viene fatto riferimento tabella BigLake nella regione BigQuery Omni, crea una tabella temporanea nella tua regione BigQuery. BigQuery utilizza quindi questa tabella temporanea per eseguire il join tra cloud e la elimina automaticamente dopo otto ore.

Sosterrai i costi di trasferimento dei dati per i dati nelle tabelle BigLake a cui fai riferimento. Tuttavia, BigQuery aiuta a ridurre questi costi trasferendo colonne e righe nella tabella BigLake che a cui viene fatto riferimento nella query, anziché nell'intera tabella. Ti consigliamo di specificare un filtro delle colonne il più limitato possibile per ridurre ulteriormente i costi di trasferimento. Il job di invito all'azione viene visualizzato nella cronologia dei job e mostra informazioni quali di byte trasferiti. I trasferimenti riusciti comportano costi anche se il job di query principale non va a buon fine. Per ulteriori informazioni, vedi Prezzi di BigQuery Omni.

Considera la seguente query come esempio:

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

Questo esempio ha due trasferimenti: uno da una tabella dei dipendenti (con un livello dei dipendenti) e uno da una tabella dei dipendenti attivi. Il join viene eseguito Regione BigQuery dopo il trasferimento. Se un trasferimento non va a buon fine e l'altro riesce, gli addebiti per il trasferimento riuscito vengono comunque applicati.

Limitazioni join tra cloud

  • I join cross-cloud non sono supportati in BigQuery livello gratuito e nel Sandbox di BigQuery.
  • Non è possibile eseguire il push delle aggregazioni in BigQuery Omni regioni se la query contiene istruzioni JOIN.
  • Ogni tabella temporanea viene utilizzata solo per una singola query tra cloud e non viene riutilizzata anche se la stessa query viene ripetuta più volte.
  • Il limite di dimensione del trasferimento per ogni trasferimento è di 60 GB. In particolare, se fai domanda un filtro su una tabella BigLake e caricare il risultato, deve essere inferiore a 60 GB. Se necessario, puoi richiedere un limite di quota più elevato. Non è previsto alcun limite per i byte sottoposti a scansione.
  • Le query di unione tra cloud utilizzano una quota interna per la frequenza delle query. Se la frequenza delle query supera la quota, potresti ricevere un errore All our servers are busy processing data transferred between regions. Nella maggior parte dei casi, la ripetizione della query dovrebbe funzionare. Contatta l'assistenza per aumentare il quota interna per supportare una maggiore frequenza di query.
  • I join cross-cloud sono supportati solo in regioni BigQuery condivise con le regioni BigQuery Omni corrispondenti e in US e EU di più regioni. I join cross-cloud eseguiti in US o EU le regioni multiple possono accedere ai dati solo negli Stati Uniti o nell'UE di BigQuery Omni regioni corrispondenti.
  • Se una query di join tra cloud fa riferimento a 10 o più set di dati delle regioni BigQuery Omni, potrebbe non riuscire con un erroreNot found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. Per evitare questo problema, consigliamo di specificare esplicitamente una posizione quando esegui un join tra cloud che fa riferimento a più di 10 set di dati. Essere tieni presente che se specifichi esplicitamente una regione BigQuery contiene solo tabelle BigLake, la query viene eseguita come una query cross-cloud e comporta dei costi per il trasferimento di dati.
  • Non puoi eseguire query sulla pseudocolonna _FILE_NAME con i join tra cloud.
  • Quando fai riferimento alle colonne di una tabella BigLake in un WHERE non puoi utilizzare NUMERIC, BIGNUMERIC, BYTES, TIME o INTERVAL valori letterali.
  • I job di join tra cloud non segnalano il numero di byte elaborati trasferiti da altri cloud. Queste informazioni sono disponibili negli CTA secondari e i job creati come parte dell'esecuzione di query tra cloud.
  • Le viste autorizzate e le routine autorizzate che fanno riferimento alle tabelle o alle viste BigQuery Omni sono supportate solo nelle regioni BigQuery Omni.
  • Se la query cross-cloud fa riferimento a STRUCT o JSON colonne, nessun push-down applicate a tutte le sottoquery remote. Per ottimizzare il rendimento, ti consigliamo di creare una vista nella regione BigQuery Omni che filtri le colonne STRUCT e JSON e restituisca solo i campi necessari come colonne singole.
  • Le query di viaggio nel tempo non sono supportate per join tra cloud.

Esempi di join tra cloud

La seguente query unisce una tabella orders in una regione BigQuery con una tabella lineitem in una regione BigQuery Omni:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Questa query è suddivisa in parti locali e remote. La seguente query viene inviata eseguire prima la regione BigQuery Omni. Il risultato è una tabella temporanea nella regione BigQuery. Puoi visualizzare questo account bambino/a Job CTAS e relativi metadati nella cronologia dei job.

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

Dopo la creazione della tabella temporanea, l'operazione JOIN viene completata e che viene eseguita la seguente query:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Come altro esempio, considera la seguente unione tra cloud:

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
  SELECT c_mktsegment, c_name
  FROM aws_dataset.customer
  WHERE c_mktsegment = 'FURNITURE'
  LIMIT 10;

In questa query, il push della clausola LIMIT non viene eseguito nella regione BigQuery Omni. Tutti i clienti nel mercato FURNITURE vengono trasferiti prima nella regione BigQuery e poi viene applicato il limite di 10.

Connettori

Puoi accedere ai dati nelle tabelle BigLake in base a da altri strumenti di elaborazione dati utilizzando Connettori BigQuery. Ad esempio, potresti accedere ai dati delle tabelle BigLake da Apache Spark, Apache Hive, TensorFlow Trino oppure Presto L'API BigQuery Storage applica i criteri di governance a livello di riga e colonna a tutto l'accesso ai dati alle tabelle BigLake, anche tramite i connettori.

Ad esempio, il seguente diagramma mostra come L'API BigQuery Storage consente agli utenti di accedere ai dati autorizzati utilizzando motori di query open source come Apache Spark:

Architettura di BigLake.

Per saperne di più sui connettori supportati da BigQuery, consulta Connettori BigQuery.

Tavoli BigLake su negozi di oggetti

Per gli amministratori del data lake, BigLake consente di impostare i controlli di accesso sulle tabelle anziché sui file, il che offre opzioni più granulari per l'impostazione dell'accesso degli utenti ai dati nel data lake.

Poiché le tabelle BigLake semplificano il controllo dell'accesso in questo modo, consigliamo di utilizzare le tabelle BigLake per creare e mantenere e connessioni agli archivi di oggetti esterni.

Puoi utilizzare tabelle esterne nei casi in cui la governance non è un requisito, né per il rilevamento e la manipolazione dei dati ad hoc.

Limitazioni

  • Tutti i limiti per le tabelle esterne si applicano alle tabelle BigLake.
  • Le tabelle BigLake nei negozi di oggetti sono soggette allo stesso come le tabelle BigQuery. Per ulteriori informazioni, vedi Quote.

  • BigLake non supporta le credenziali con ambito ridotto provenienti dall'autenticazione dei cluster personali Dataproc. Come soluzione alternativa, per utilizzare i cluster con l'autenticazione cluster personale, devi inserire le credenziali utilizzando Confine dell'accesso alle credenziali con il flag --access-boundary=<(echo -n "{}"). Ad esempio, abilita una sessione di propagazione delle credenziali in un progetto denominato myproject per il cluster denominato mycluster: 

    gcloud dataproc clusters enable-personal-auth-session \
    --region=us \
    --project=myproject \
    --access-boundary=<(echo -n "{}") \
    mycluster

  • Le tabelle BigLake sono di sola lettura. Non puoi modificare Tabelle BigLake utilizzando istruzioni DML o altri metodi.

  • Le tabelle BigLake supportano i seguenti formati:

  • Non puoi utilizzare metadati memorizzati nella cache con tabelle BigLake di Apache Iceberg; BigQuery utilizza già i metadati acquisiti da Iceberg nei file manifest.

  • L'API BigQuery Storage non è disponibile in altri ambienti cloud, come AWS e Azure.

  • Se utilizzi metadati memorizzati nella cache, allora si applicano le seguenti limitazioni:

    • Puoi utilizzare solo metadati memorizzati nella cache con tabelle BigLake che usano Avro, ORC, Formati Parquet, JSON e CSV.
    • Se crei, aggiorni o elimini file in Amazon S3, la query sui file non restituisce i dati aggiornati fino al successivo aggiornamento della cache dei metadati. Ciò può portare a risultati imprevisti. Ad esempio, se elimini un file e ne scrivi un nuovo, la query risultati possono escludere sia il vecchio che il nuovo file, a seconda di quando l'ultimo aggiornamento dei metadati memorizzati nella cache.
    • L'utilizzo delle chiavi di crittografia gestite dal cliente (CMEK) con i metadati memorizzati nella cache non è supportato per le tabelle BigLake che fanno riferimento ai dati di Amazon S3 o Blob Storage.

Modello di sicurezza

I seguenti ruoli organizzativi sono generalmente coinvolti nella gestione utilizzando le tabelle BigLake:

  • Amministratori del data lake. Questi amministratori in genere gestiscono Criteri IAM (Identity and Access Management) sui bucket Cloud Storage e di oggetti strutturati.
  • Amministratori di data warehouse. Questi amministratori di solito creare, eliminare e aggiornare le tabelle.
  • Analisti di dati. In genere, gli analisti leggono i dati ed eseguono query.

Gli amministratori dei data lake sono responsabili della creazione delle connessioni e della condivisione con gli amministratori del data warehouse. A sua volta, il data warehouse creano tabelle, impostano controlli di accesso appropriati e condividono con analisti di dati.

Memorizzazione nella cache dei metadati per le prestazioni

Puoi utilizzare i metadati memorizzati nella cache per migliorare le prestazioni delle query su alcuni tipi di Tavoli BigLake. La memorizzazione nella cache dei metadati è particolarmente utile in cui si lavora con grandi quantità di file o se i dati si trovano in partizionate. I seguenti tipi di tabelle BigLake per supportare la memorizzazione nella cache dei metadati:

  • Tabelle BigLake di Amazon S3
  • Tabelle BigLake di Cloud Storage
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 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à:

  • Massima obsolescenza: 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'ultima ora. Se i metadati memorizzati nella cache sono precedenti a questa data, l'operazione passa al recupero dei metadati dal datastore (Amazon S3 o Cloud Storage). 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 nel datastore vengono aggiunti, eliminati o modificati a intervalli casuali. 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. Per le tabelle BigLake, puoi aggiornare i metadati in modo selettivo fornendo sottodirectory della directory dei dati della tabella. In questo modo, puoi evitare un'elaborazione non necessaria dei metadati. Aggiornare manualmente la cache è un buon approccio se i file il datastore vengono aggiunti, eliminati o modificati a intervalli noti come output di una pipeline.

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

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.

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 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 il datastore 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 le tabelle BigLake di Cloud Storage basate su Parquet file, le statistiche delle tabelle sono raccolte durante l'aggiornamento della cache dei metadati e utilizzate per migliorare i piani di query.

Per scoprire di più, consulta Memorizzazione nella cache dei metadati.

Per ulteriori informazioni sull'impostazione delle opzioni di memorizzazione nella cache dei metadati, consulta Creare tabelle Amazon S3 BigLake o Crea tabelle BigLake di Cloud Storage.

Tabelle abilitate per la cache con viste materializzate

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

Integrazioni

Le tabelle BigLake sono accessibili da una serie di altre funzionalità di BigQuery e servizi gcloud CLI, inclusi i seguenti servizi in evidenza.

Analytics Hub

Le tabelle BigLake sono compatibili con Analytics Hub. I set di dati contenenti tabelle BigLake possono essere pubblicati come schede di Analytics Hub. Gli iscritti ad Analytics Hub possono iscriversi a questi di schede, che eseguono il provisioning di un set di dati di sola lettura, chiamato , in del progetto. I sottoscrittori possono eseguire query su tutte le tabelle nel set di dati collegato, inclusi tutti Tavoli BigLake. Per ulteriori informazioni, consulta la sezione Iscriversi a una scheda.

BigQuery ML

Puoi utilizzare BigQuery ML per addestrare di eseguire modelli su BigLake in Cloud Storage.

Protezione dei dati sensibili

Sensitive Data Protection analizza le tue tabelle BigLake per identificare e classificare i dati sensibili. Se vengono rilevati dati sensibili, Le trasformazioni di anonimizzazione di Sensitive Data Protection possono mascherare, eliminare o oscurare in altro modo quei dati.

Costi

I costi sono associati ai seguenti aspetti delle tabelle BigLake:

Se disponi di slot prenotazioni, non sei addebitato per l'esecuzione di query su tabelle esterne. Vengono invece utilizzati slot per queste query.

La tabella seguente mostra in che modo il modello di determinazione del prezzo influisce su questi costi applicati:


Prezzi on demand
Versioni Standard, Enterprise ed Enterprise Plus

Query
Ti vengono addebitati i byte elaborati dalle query degli utenti.		 Gli
slot nelle assegnazioni delle prenotazioni con un QUERY tipo di job vengono consumati durante il tempo di query.

Aggiornare manualmente la cache dei metadati.
Ti viene addebitato il costo dei byte elaborate per aggiornare la cache.
Slot nelle assegnazioni delle prenotazioni con un QUERY tipo di job vengono utilizzati durante l'aggiornamento della cache.

Aggiorna automaticamente la cache dei metadati.
Ti vengono addebitati i byte elaborati per aggiornare la cache.
Slot nelle assegnazioni delle prenotazioni con un BACKGROUND tipo di job vengono utilizzati durante l'aggiornamento della cache.

Se non sono disponibili prenotazioni BACKGROUND per l'aggiornamento cache dei metadati, BigQuery utilizza automaticamente gli slot QUERY prenotazioni invece se utilizzi la versione Enterprise o Enterprise Plus.

Ti vengono inoltre addebitati i costi per lo spazio di archiviazione e l'accesso ai dati Cloud Storage Amazon S3, e Azure Blob Storage, sono soggette alle linee guida sui prezzi di ciascun prodotto.

Passaggi successivi