Introduzione alle tabelle BigLake

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

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

Le tabelle BigLake consentono di eseguire query su dati strutturati in datastore esterni con delega dell'accesso. Delega accesso disaccoppia l'accesso alla tabella BigLake dall'accesso al datastore sottostante. Una connessione esterna associata a un account di servizio viene utilizzata per connettersi al datastore. Poiché l'account di servizio gestisce il recupero dei dati dal datastore, devi concedere agli utenti solo l'accesso alla tabella BigLake. In questo modo puoi applicare una sicurezza granulare a livello di tabella, inclusa la sicurezza a livello di riga e di colonna. Per le tabelle BigLake basate su Cloud Storage, puoi anche utilizzare il mascheramento dinamico dei dati. Per scoprire di più sulle soluzioni di analisi multi-cloud che utilizzano le tabelle BigLake con dati di Amazon S3 o Blob Storage, consulta BigQuery Omni.

Datastore supportati

Puoi utilizzare le tabelle BigLake con i seguenti datastore:

Supporto temporaneo delle tabelle

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ù origini dati esterne, a condizione che queste abbiano lo stesso schema.

Join cross-cloud

I join cross-cloud consentono di eseguire query su regioni di Google Cloud e BigQuery Omni. Puoi utilizzare le operazioni JOIN di GoogleSQL per analizzare i dati in molte soluzioni di archiviazione diverse, come AWS, Azure, set di dati pubblici e altri servizi Google Cloud. L'unione tra cloud elimina la necessità di copiare i dati tra le origini prima di eseguire le query.

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

Autorizzazioni richieste per join tra cloud

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

Questo ruolo predefinito contiene le autorizzazioni necessarie per eseguire un join cross-cloud. Per visualizzare esattamente le autorizzazioni necessarie, espandi la sezione Autorizzazioni obbligatorie:

Autorizzazioni obbligatorie

Per eseguire un join cross-cloud sono necessarie le seguenti autorizzazioni:

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

Potresti anche riuscire a ottenere queste autorizzazioni con i ruoli personalizzati o 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. Di conseguenza, per concedere l'accesso solo alle risorse create da join tra cloud, utilizza la condizione resource.name.startsWith per i tipi di risorsa Table e Dataset.

Per ulteriori informazioni su ruoli e autorizzazioni IAM in BigQuery, consulta Introduzione a IAM.

Costi di join tra cloud

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

Ti vengono addebitati dei costi per il trasferimento di dati nelle tabelle BigLake di riferimento. Tuttavia, BigQuery aiuta a ridurre questi costi trasferendo solo le colonne e le righe della tabella BigLake a cui si fa riferimento nella query, anziché l'intera tabella. Ti consigliamo di specificare un filtro di colonna il più limitato possibile per ridurre ulteriormente i costi di trasferimento. Il job CTAS viene visualizzato nella cronologia del job e mostra informazioni come il numero di byte trasferiti. I trasferimenti riusciti comportano costi anche se il job di query principale non va a buon fine. Per ulteriori informazioni, consulta la pagina relativa ai 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 prevede due trasferimenti: uno da una tabella dei dipendenti (con un filtro dei livelli) e uno da una tabella dei dipendenti attivi. Il join viene eseguito nella regione BigQuery dopo il trasferimento. Se un trasferimento non va a buon fine e l'altro va a buon fine, i costi del trasferimento di dati vengono comunque applicati per il trasferimento riuscito.

Limitazioni join tra cloud

  • I join cross-cloud non sono supportati nel livello gratuito di BigQuery e nella sandbox di BigQuery.
  • È possibile che non venga eseguito il push delle aggregazioni nelle regioni BigQuery Omni se la query contiene istruzioni JOIN.
  • Ogni tabella temporanea viene utilizzata solo per una singola query cross-cloud e non viene riutilizzata anche se la stessa query viene ripetuta più volte.
  • Il limite della dimensione di trasferimento per ogni trasferimento è 60 GB. In particolare, se applichi un filtro a una tabella BigLake e carichi il risultato, questo deve essere inferiore a 60 GB. Se necessario, puoi richiedere un limite di quota più elevato. Non è previsto alcun limite ai byte analizzati.
  • Le query di join cross-cloud utilizzano una quota interna per la percentuale di 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, un nuovo tentativo di query dovrebbe funzionare. Contatta l'assistenza per aumentare la quota interna in modo da supportare una frequenza di query più elevata.
  • I join cross-cloud sono supportati solo nelle regioni BigQuery condivise con le regioni BigQuery Omni corrispondenti e nelle regioni multiregionali US e EU. I join cross-cloud eseguiti nelle regioni multiple US o EU possono accedere ai dati solo nelle regioni BigQuery Omni degli Stati Uniti o dell'UE.
  • Se una query di join cross-cloud fa riferimento a 10 o più set di dati delle regioni di BigQuery Omni, potrebbe generare un errore Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. Per evitare questo problema, ti consigliamo di specificare esplicitamente una località quando esegui un join cross-cloud che fa riferimento a più di 10 set di dati. Tieni presente che se specifichi esplicitamente una regione BigQuery e la query contiene solo tabelle BigLake, viene eseguita come query cross-cloud e comporta costi di trasferimento dei dati.
  • Non puoi eseguire query sulla pseudo-colonna _FILE_NAME con join cross-cloud.
  • Quando fai riferimento alle colonne di una tabella BigLake in una clausola WHERE, non puoi utilizzare i valori letterali NUMERIC, BIGNUMERIC, BYTES, TIME o INTERVAL.
  • I job di join tra cloud non segnalano il numero di byte elaborati e trasferiti da altri cloud. Queste informazioni sono disponibili nei job CTAS figlio creati come parte dell'esecuzione delle query cross-cloud.
  • Le viste autorizzate e le routine autorizzate che fanno riferimento alle tabelle o alle viste di BigQuery Omni sono supportate solo nelle regioni di BigQuery Omni.
  • Se la query cross-cloud fa riferimento a STRUCT o JSON colonne, non viene applicato alcun push-down alle sottoquery remote. Per ottimizzare le prestazioni, valuta la possibilità di creare una vista nella regione di BigQuery Omni che filtri le colonne STRUCT e JSON e restituisca solo i campi necessari come colonne singole.
  • Le query di spostamento cronologico non sono supportate dai join cross-cloud.

Esempi di join tra cloud

La seguente query unisce una tabella orders in una regione BigQuery a 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 alla regione BigQuery Omni affinché venga eseguita per prima. Il risultato è una tabella temporanea nella regione BigQuery. Puoi visualizzare questo job CTAS secondario e i 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 aver creato la tabella temporanea, l'operazione JOIN viene completata e 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 il seguente cross-cloud join:

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, la clausola LIMIT non viene inviata alla regione BigQuery Omni. Tutti i clienti nel segmento di mercato FURNITURE vengono trasferiti prima alla regione BigQuery e poi viene applicato il limite di 10.

Connettori

Puoi accedere ai dati nelle tabelle BigLake basate su Cloud Storage da altri strumenti di elaborazione dati utilizzando i connettori BigQuery. Ad esempio, potresti accedere ai dati delle tabelle BigLake da Apache Spark, Apache Hive, TensorFlow, Trino o Presto. L'API BigQuery Storage applica criteri di governance a livello di riga e colonna su tutti gli accessi ai dati alle tabelle BigLake, inclusi i connettori.

Ad esempio, il seguente diagramma mostra in che modo l'API BigQuery Storage consente agli utenti di accedere ai dati autorizzati utilizzando motori di query open source come ApacheSpark:

Architettura di BigLake.

Per ulteriori informazioni sui connettori supportati da BigQuery, consulta Connettori BigQuery.

Tavoli BigLake su negozi di oggetti

Per gli amministratori di data lake, BigLake consente di impostare i controlli dell'accesso sulle tabelle anziché sui file, in modo da offrire opzioni più granulari quando si imposta l'accesso utente ai dati nel data lake.

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

Puoi utilizzare tabelle esterne nei casi in cui la governance non è obbligatoria o per rilevare e manipolare i dati ad hoc.

Limitazioni

  • Tutte le limitazioni per le tabelle esterne si applicano alle tabelle BigLake.
  • Le tabelle BigLake negli archivi di oggetti sono soggette alle stesse limitazioni delle tabelle BigQuery. Per ulteriori informazioni, consulta Quote.

  • BigLake non supporta le credenziali con ambito ridotto dell'autenticazione cluster personale di Dataproc. Come soluzione alternativa, per utilizzare i cluster con l'autenticazione cluster personale, devi inserire le credenziali utilizzando un confine di accesso alle credenziali vuoto con il flag --access-boundary=<(echo -n "{}"). Ad esempio, il seguente comando 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 le tabelle BigLake utilizzando istruzioni DML o altri metodi.

  • Le tabelle BigLake supportano i seguenti formati:

  • Non puoi utilizzare metadati memorizzati nella cache con le 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, si applicano le seguenti limitazioni:

    • Puoi utilizzare i metadati memorizzati nella cache solo con tabelle BigLake che utilizzano i formati Avro, ORC, Parquet, JSON e CSV.
    • Se crei, aggiorni o elimini file in Amazon S3, l'esecuzione di 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 scrivi un nuovo file, i risultati della query potrebbero escludere sia il vecchio che i nuovi file, a seconda dell'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 a dati di Amazon S3 o Blob Storage.

Modello di sicurezza

I seguenti ruoli organizzativi sono in genere coinvolti nella gestione e nell'utilizzo delle tabelle BigLake:

  • Amministratori dei data lake. Questi amministratori in genere gestiscono i criteri di Identity and Access Management (IAM) su bucket e oggetti Cloud Storage.
  • Amministratori di data warehouse. Questi amministratori in genere creano, eliminano e aggiornano 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 loro condivisione con gli amministratori del data warehouse. A loro volta, gli amministratori dei data warehouse creano le tabelle, impostano i controlli di accesso appropriati e condividono le tabelle con gli analisti di dati.

Memorizzazione nella cache dei metadati per migliorare le prestazioni

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

  • Tavoli Amazon S3 BigLake
  • Tabelle BigLake di Cloud Storage
I metadati includono nomi dei file, informazioni di partizionamento e metadati fisici dei 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 sulla tabella devono leggere l'origine dati esterna per ottenere i metadati degli oggetti. 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 abiliti la memorizzazione nella cache dei metadati, le query possono evitare di elencare i file dall'origine dati esterna e possono partizionare ed eliminare i file più rapidamente.

Esistono due proprietà che controllano questa funzionalità:

  • Massima inattività: 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 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 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, solitamente compreso 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 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. Per le tabelle BigLake, puoi aggiornare i metadati in modo selettivo fornendo le sottodirectory della directory dei dati della tabella. Ciò consente di evitare l'elaborazione non necessaria dei metadati. L'aggiornamento manuale della cache è un buon approccio se i file nel datastore 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.

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

Se scegli di utilizzare gli aggiornamenti automatici, ti consigliamo di creare una prenotazione, quindi creare 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 potrebbero non riuscire se non sono disponibili risorse sufficienti.

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 dal datastore 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 le tabelle BigLake di Cloud Storage basate su file Parquet, le statistiche delle tabelle vengono 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 Creare tabelle BigLake di Cloud Storage.

Tabelle abilitate per la cache con viste materializzate

Puoi utilizzare le viste materializzate su tabelle abilitate per la cache di metadati BigLake per migliorare le prestazioni e l'efficienza quando esegui query su dati strutturati archiviati in Cloud Storage o Amazon Simple Storage Service (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.

Integrazioni

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

Analytics Hub

Le tabelle BigLake sono compatibili con Analytics Hub. I set di dati contenenti tabelle BigLake possono essere pubblicati come schede Analytics Hub. Gli abbonati ad Analytics Hub possono iscriversi a queste schede, che eseguono il provisioning di un set di dati di sola lettura, chiamato set di dati collegato, nel loro progetto. I sottoscrittori possono eseguire query su tutte le tabelle nel set di dati collegato, comprese tutte le tabelle BigLake. Per ulteriori informazioni, vedi Abbonarsi a una scheda.

BigQuery ML

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

Sensitive Data Protection

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 questi dati.

Costi

I costi sono associati ai seguenti aspetti delle tabelle BigLake:

Se hai prenotazioni di slot, non ti viene addebitato alcun costo per l'esecuzione di query sulle tabelle esterne. Per queste query vengono invece consumati gli slot.

La seguente tabella mostra in che modo il modello di determinazione del prezzo influisce sulla modalità di applicazione di questi costi:


Prezzi on demand
Versioni Standard, Enterprise ed Enterprise Plus

Query
Ti vengono fatturati i byte elaborati dalle query degli utenti.
Gli slot nelle assegnazioni di prenotazione con un tipo di job QUERY vengono consumati durante la query.

Aggiorna manualmente la cache dei metadati.
Per aggiornare la cache ti vengono fatturati i byte elaborati.
Gli slot nelle assegnazioni di prenotazione con un tipo di job QUERY vengono consumati durante l'aggiornamento della cache.

Aggiornamento automatico della cache dei metadati.
Per aggiornare la cache ti vengono fatturati i byte elaborati.
Gli slot nelle assegnazioni di prenotazione con un tipo di job BACKGROUND vengono consumati durante l'aggiornamento della cache.

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

Passaggi successivi