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 in datastore esterni con delega di accesso. La delega di accesso disaccoppia l'accesso alla tabella BigLake dall'accesso al datastore sottostante. Per connettersi al datastore viene utilizzata una connessione esterna associata a un account di servizio. 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 a livello 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 i dati di Amazon S3 o di 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ù origini dati esterne, a condizione che queste abbiano lo stesso schema.

Join-cloud

I join cross-cloud consentono di eseguire query su tutte le regioni 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. Le unioni cross-cloud eliminano la necessità di copiare 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 le istruzioni Data Manipulation Language (DML) e Data Definition Language (DDL) che utilizzano 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 l'unione 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 tra cloud. Per visualizzare le autorizzazioni esatte necessarie, 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 essere in grado di ottenere queste autorizzazioni con i ruoli personalizzati o altri ruoli predefiniti.

Le unioni cross-cloud creano set di dati con il prefisso __bigquery_xregion_sink_ e tabelle temporanee all'interno di questi set di dati, quindi per concedere l'accesso solo alle risorse create dai join cross-cloud, utilizza la condizione resource.name.startsWith per i tipi di risorse Table e Dataset.

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

Costi di join cross-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, in modo da creare una tabella temporanea nella regione BigQuery. BigQuery utilizza quindi questa tabella temporanea per eseguire il join cross-cloud ed elimina la tabella automaticamente dopo otto ore.

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

Limitazioni join cross-cloud

  • I join cross-cloud non sono supportati nel livello gratuito di BigQuery e nella sandbox di BigQuery.
  • I join di più tabelle BigLake della stessa regione non vengono spinti verso il basso nella regione BigQuery Omni.
  • Se la query contiene istruzioni JOIN, le aggregazioni potrebbero non essere inviate alle regioni BigQuery Omni.
  • 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.
  • La dimensione massima di ogni trasferimento è 60 GB. Nello specifico, se applichi un filtro a una tabella BigLake e carichi il risultato, la dimensione deve essere inferiore a 60 GB. Se necessario, puoi richiedere un limite di quota più elevato. Non sono previsti limiti ai byte analizzati.
  • Le query di join cross-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. Riprovare a eseguire la query dovrebbe funzionare nella maggior parte dei casi. Contatta l'assistenza per aumentare la quota interna e supportare una percentuale più elevata di query.
  • I join cross-cloud sono supportati solo nelle regioni BigQuery con colocation con le regioni BigQuery Omni corrispondenti e nelle regioni multiple US e EU. I join cross-cloud eseguiti nelle aree geografiche multiple US o EU possono accedere ai dati solo nelle regioni BigQuery Omni rispettivamente negli Stati Uniti o nell'UE.
  • Se una query di join cross-cloud fa riferimento a 10 o più set di dati delle regioni di BigQuery Omni, potrebbe non riuscire con 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 tra cloud che fa riferimento a più di 10 set di dati. Tieni presente che se specifichi esplicitamente una regione BigQuery e la tua query contiene solo tabelle BigLake, la query viene eseguita come query cross-cloud e comporta costi di trasferimento dei 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 una clausola WHERE, non puoi utilizzare NUMERIC, BIGNUMERIC, BYTES, TIME o INTERVAL.
  • I job di join cross-cloud non registrano il numero di byte elaborati e trasferiti da altri cloud. Queste informazioni sono disponibili nei job CTAS secondari creati come parte dell'esecuzione di query cross-cloud.
  • Le viste autorizzate e le routine autorizzate che fanno riferimento a tabelle o viste BigQuery Omni sono supportate solo nelle regioni BigQuery Omni.
  • Se la query cross-cloud fa riferimento a una colonna STRUCT, non vengono applicate push-down alle sottoquery remote. Per ottimizzare le prestazioni, ti consigliamo di creare una vista nella regione BigQuery Omni che filtri le colonne STRUCT e restituisca solo i campi STRUCT necessari come singole colonne.

Esempi di join cross-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 alla regione BigQuery Omni per essere eseguita prima. Il risultato è una tabella temporanea nella regione BigQuery. Puoi visualizzare questo job di 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 query seguente:

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 ulteriore esempio, considera il seguente join cross-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, 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, puoi accedere ai dati nelle 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, anche attraverso 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 Apache Spark:

Architettura di BigLake.

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

Tabelle BigLake negli archivi di oggetti

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

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

Puoi utilizzare le tabelle esterne nei casi in cui la governance non è un requisito o per il rilevamento e la manipolazione dei 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 maggiori informazioni, consulta Quote.

  • BigLake non supporta le credenziali con ambito ridotto da Autenticazione cluster personale di Dataproc. Come soluzione alternativa, per utilizzare i cluster con autenticazione cluster personale, devi inserire le credenziali utilizzando un limite 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 i 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 i metadati nella cache, si applicano le seguenti limitazioni:

    • Puoi utilizzare metadati memorizzati nella cache solo con le tabelle BigLake che utilizzano i formati Avro, ORC, Parquet, JSON e CSV.
    • Se crei, aggiorni o elimini file in Amazon S3, l'esecuzione di una 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 il nuovo file a seconda della data dell'ultimo aggiornamento dei metadati memorizzati nella cache.
    • L'utilizzo di chiavi di crittografia gestite dal cliente (CMEK) con metadati memorizzati nella cache non è supportato per le tabelle BigLake che fanno riferimento a dati Amazon S3 o Blob Storage.

Modello di sicurezza

Nella gestione e nell'utilizzo delle tabelle BigLake sono generalmente coinvolti i seguenti ruoli organizzativi:

  • Amministratori di data lake. Questi amministratori in genere gestiscono i criteri IAM (Identity and Access Management) sui bucket e sugli oggetti Cloud Storage.
  • Amministratori di data warehouse. Questi amministratori in genere creano, eliminano e aggiornano le tabelle.
  • Analisti di dati. Gli analisti in genere 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 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 lavori con un numero elevato di file o se i dati sono partizionati hive. I seguenti tipi di tabelle BigLake supportano la memorizzazione nella cache dei metadati:

  • Tabelle BigLake di Amazon S3
  • Tabelle BigLake di Cloud Storage
I metadati includono nomi dei file, informazioni sul partizionamento e metadati fisici dei file, come il numero di righe. Puoi scegliere se attivare o meno la memorizzazione nella cache dei metadati su una tabella. Le query con un numero elevato di file e con 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 che aumentano la latenza delle query. La creazione di elenchi 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 dell'origine dati esterna e ottenere un'eliminazione più rapida delle partizioni e dei file.

Esistono due proprietà che controllano questa funzionalità:

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

Se la memorizzazione nella cache dei metadati è abilitata, devi specificare l'intervallo massimo di inattività 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, l'operazione esegue invece 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, di solito 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 hai bisogno di 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, esegui la procedura di sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE per aggiornare la cache dei metadati in base a una pianificazione che soddisfi i tuoi requisiti. Se vuoi aggiornare i metadati in modo selettivo, puoi fornire sottodirectory della directory dei dati della tabella per 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 contemporanei, solo uno avrà esito positivo.

Se non viene aggiornata, la cache dei metadati scade dopo sette 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 di 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 richiede il lato più lungo della solita 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 la sezione Memorizzazione nella cache dei metadati.

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

Tabelle abilitate per la cache con viste materializzate

Puoi utilizzare le viste materializzate sulle tabelle di metadati BigLake abilitate per la cache per migliorare le prestazioni e l'efficienza durante l'esecuzione di query sui 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, inclusi i vantaggi dell'aggiornamento automatico e dell'ottimizzazione intelligente.

Integrazioni

Le tabelle BigLake sono accessibili da una serie di altre funzionalità BigQuery e servizi 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 abbonati ad Analytics Hub possono abbonarsi 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, consulta la sezione 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 esegue la scansione delle 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 utilizzati gli slot.

La tabella seguente mostra in che modo il modello di determinazione del prezzo influisce sull'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 il tempo della query.

Aggiornamento manuale della cache dei metadati.
Ti vengono fatturati i byte elaborati per aggiornare la cache.
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.
Ti vengono fatturati i byte elaborati per aggiornare la cache.
Gli slot nelle assegnazioni di prenotazione con un tipo di job BACKGROUND vengono consumati durante l'aggiornamento della cache.

Se non sono disponibili prenotazioni di 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