Introduzione alle tabelle BigLake

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

Puoi anche eseguire l'upgrade di una tabella esterna a BigLake. Per maggiori informazioni informazioni, vedi 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. Delega di accesso disaccoppia l'accesso alla tabella BigLake dall'accesso nel datastore sottostante. Un connessione esterna associati a un account di servizio vengono utilizzati per la connessione al datastore. Poiché l'account di servizio gestisce il recupero dei dati dal datastore, devi solo per 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 nelle tabelle BigLake basate su Cloud Storage, puoi anche mascheramento dinamico dei dati. Per scoprire di più su di soluzioni analitiche multi-cloud utilizzando le tabelle BigLake con dati di Amazon S3 o Archiviazione BLOB, 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 permanente. Tabelle BigLake basate su Amazon S3 o L'archiviazione BLOB deve essere permanente.

Più file di origine

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

Join cross-cloud

I join cross-cloud consentono di eseguire query su Google Cloud Regioni di 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ù BigLake da cloud diversi e tabelle BigQuery nello stesso 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 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.

Questo ruolo predefinito contiene le autorizzazioni necessarie per eseguire un join tra cloud. Per vedere le autorizzazioni esatte obbligatorie, 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 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 ulteriori informazioni su ruoli e autorizzazioni IAM in per BigQuery, consulta Introduzione a IAM.

Costi di join 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 Operazione 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 poi questa tabella temporanea per eseguire cross-cloud ed elimina la tabella automaticamente dopo otto ore.

Ti vengono addebitati i costi di trasferimento dei dati nel BigLake di riferimento tabelle. 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. Consigliamo di specificare un il più limitato possibile per ridurre ulteriormente i costi di trasferimento. Il job CTAS viene visualizzato nella cronologia dei job e mostra informazioni come di byte trasferiti. I trasferimenti riusciti comportano costi anche se un job di query non riesce. 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'altra va a buon fine, i costi del trasferimento di dati vengono comunque applicati alla trasferimento riuscito.

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 cross-cloud e non è anche se la stessa query viene ripetuta più volte.
  • Il limite della dimensione di trasferimento per ogni trasferimento è 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 ai byte analizzati.
  • Le query di join cross-cloud utilizzano una quota interna per la percentuale di query. Se delle query supera la quota, potresti ricevere All our servers are busy processing data transferred between regions errore. Nella maggior parte dei casi, un nuovo tentativo di 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 cross-cloud fa riferimento a 10 o più set di dati da Regioni di BigQuery Omni, l'operazione potrebbe generare un errore Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. Per evitare questo problema, consiglia specificare esplicitamente una località 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 una query sulla pseudo-colonna _FILE_NAME con i join cross-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.
  • Visualizzazioni autorizzate e alle routine autorizzate con riferimento Le tabelle o le viste BigQuery Omni sono supportate solo in Regioni di 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, considera creando una vista nella regione BigQuery Omni che filtra STRUCT e JSON e restituisce solo i campi necessari come singole colonne.
  • 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 è un 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 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, il push della clausola LIMIT non viene eseguito nella regione BigQuery Omni. Tutti i clienti nel mercato FURNITURE vengono prima trasferiti alla 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 su tutti l'accesso ai dati alle tabelle BigLake, anche tramite 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 di data lake, BigLake consente di impostare l'accesso controlli su tabelle anziché sui file, in modo da offrire opzioni più granulari quando imposti l'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 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 limitazioni per le tabelle esterne si applica 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 da Autenticazione cluster personale di 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 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: a eseguire query sui file non restituisce i dati aggiornati aggiornare la 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 Dati di Amazon S3 o Archiviazione BLOB.

Modello di sicurezza

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

  • Amministratori dei 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 migliorare 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:

  • Tavoli Amazon S3 BigLake
  • 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 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 il 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 criterio definito dal sistema intervallo, solitamente compreso tra 30 e 60 minuti. Aggiornamento di Cache è un buon approccio se i file il datastore 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. Per le tabelle BigLake, puoi aggiornare i metadati in modo selettivo fornendo le sottodirectory della directory dei dati della tabella. Questo consente di evita metadati non necessari e l'elaborazione dei dati. 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 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 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 di 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 gcloud CLI, tra cui 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 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 un dell'annuncio.

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, addebitato per l'esecuzione di query su tabelle esterne. Vengono invece consumati slot per questi 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.
Slot a assegnazioni di prenotazione con un tipo di job QUERY vengono consumate durante la query.

Aggiornamento manuale della cache dei metadati.
Ti vengono addebitati i byte elaborati per aggiornare la cache.
Slot a assegnazioni di prenotazione con un tipo di job QUERY vengono consumate durante l'aggiornamento della cache.

Aggiornamento automatico della cache dei metadati.
Ti vengono addebitati i byte elaborati per aggiornare la cache.
Slot a assegnazioni di prenotazione con un tipo di job BACKGROUND vengono consumate 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