Introduzione alle tabelle esterne 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 su di esse 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 ti consentono di eseguire query sui dati strutturati in data store esterni con delega dell'accesso. La delega dell'accesso consente di disaccoppiare l'accesso alla tabella BigLake dall'accesso all'datastore sottostante. Per connettersi allo datastore viene utilizzata una connessione esterna associata a un account di servizio. Poiché l'account di servizio gestisce il recupero dei dati dallo datastore, devi solo concedere agli utenti 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 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 in base a più origini dati esterne, a condizione 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 le operazioni JOIN di GoogleSQL per analizzare i dati in molte diverse soluzioni di archiviazione, come AWS, Azure, set di dati pubblici e altri servizi Google Cloud. Le unioni tra cloud eliminano la necessità di copiare i dati tra le origini prima di eseguire query.

Puoi fare riferimento alle tabelle BigLake ovunque in un'istruzione SELECT come se fossero tabelle BigQuery standard, ad esempio nelle 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) 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 ottenere queste autorizzazioni con ruoli personalizzati o altri ruoli predefiniti.

Le unioni tra 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 dalle unioni tra cloud, utilizza la condizione resource.name.startsWith per i tipi di risorse 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 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 a cui si fa riferimento nella regione BigQuery Omni, che crea una tabella temporanea nella regione BigQuery. BigQuery utilizza quindi questa tabella temporanea per eseguire la join tra cloud e la elimina automaticamente dopo otto ore.

Sosterrai costi di trasferimento dei dati per i dati nelle tabelle BigLake a cui fai riferimento. Tuttavia, BigQuery contribuisce a ridurre questi costi trasferendo solo le colonne e le righe della tabella BigLake a cui viene fatto riferimento nella query, anziché l'intera tabella. Ti consigliamo di specificare un filtro delle colonne il più limitato 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 di query principale non va a buon fine. Per ulteriori informazioni, consulta la pagina relativa ai prezzi di BigQuery Omni.

Prendi ad esempio la seguente query:

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 contiene due trasferimenti: uno da una tabella dipendenti (con un filtro di livello) e uno da una tabella dipendenti attivi. L'unione viene eseguita nella 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 dei join tra cloud

  • Le unioni tra cloud non sono supportate nel livello gratuito di BigQuery e nella sandbox di BigQuery.
  • Le aggregazioni potrebbero non essere spostate nelle regioni BigQuery Omni 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. Nello specifico, 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ù alto. 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 la quota interna in modo da supportare un tasso più elevato di query.
  • Le unioni tra cloud sono supportate solo nelle regioni BigQuery colocate con le regioni BigQuery Omni corrispondenti e nelle regioni multiregionali US e EU. Le unioni tra cloud eseguite nelle regioni multiregionali US o EU possono accedere ai dati solo nelle regioni Omni BigQuery degli Stati Uniti o dell'UE.
  • 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. Tieni conto 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 query sulla pseudocolonna _FILE_NAME con i join tra cloud.
  • Quando fai riferimento alle colonne di una tabella BigLake in una clausola WHERE, non puoi utilizzare i valori letterali INTERVAL o RANGE.
  • I job di join tra cloud non registrano il numero di byte elaborati e trasferiti da altri cloud. Queste informazioni sono disponibili nei job CTAS figli creati nell'ambito dell'esecuzione di query cross-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 tra cloud fa riferimento a colonne STRUCT o JSON, non vengono applicati pushdown alle 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 dalle unioni 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 alla regione BigQuery Omni per essere 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 ed 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, la clausola LIMIT non viene passata alla regione BigQuery Omni. Tutti i clienti del segmento di mercato FURNITURE vengono prima trasferiti nella regione BigQuery, quindi viene applicato il limite di 10.

Connettori

Puoi accedere ai dati nelle tabelle BigLake basate su Cloud Storage da altri strumenti di elaborazione dei 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 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 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 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 utilizzarle per creare e gestire le connessioni agli oggetti esterni.

Puoi utilizzare le tabelle esterne nei casi in cui la governance non è un requisito o per la scoperta e la manipolazione di dati ad hoc.

Limitazioni

  • Tutti i limiti per le tabelle esterne si applicano alle tabelle BigLake.
  • Le tabelle BigLake negli archivi oggetti sono soggette alle stesse limitazioni delle tabelle BigQuery. Per ulteriori informazioni, consulta 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 tue credenziali utilizzando un limite di accesso alle credenziali vuoto con il flag --access-boundary=<(echo -n "{}"). Ad esempio, il seguente comando attiva una sessione di propagazione delle credenziali in un progetto chiamato myproject per il cluster 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 tabelle esterne BigLake per 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 memorizzati 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, 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 uno nuovo, i risultati della query possono escludere sia il file precedente sia quello nuovo, a seconda dell'ultima volta che i metadati memorizzati nella cache sono stati aggiornati.
    • 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 e nell'utilizzo delle tabelle BigLake:

  • Amministratori del data lake. In genere, questi amministratori gestiscono i criteri IAM (Identity and Access Management) per gli oggetti e i bucket di Cloud Storage.
  • Amministratori del data warehouse. In genere, questi amministratori creano, eliminano e aggiornano le tabelle.
  • Analisti di dati. In genere, gli analisti leggono i dati ed eseguono query.

Gli amministratori del data lake sono responsabili della creazione delle connessioni e della loro condivisione con gli amministratori del data warehouse. A loro volta, gli amministratori del data warehouse creano tabelle, impostano controlli di accesso appropriati e condividono le tabelle con i data analyst.

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 tabella BigLake. La memorizzazione nella cache dei metadati è particolarmente utile se si lavora con un numero elevato di file o se i dati sono suddivisi in parti. 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 di file, informazioni sulla partizione e metadati fisici di file come i conteggi delle righe. Puoi scegliere se attivare o meno la memorizzazione nella cache dei metadati in una tabella. Le query con un numero elevato di file e con filtri di partizione Hive 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à:

  • Anticipo massimo 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 attivarlo 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 sottodirectory della directory dei dati della tabella. In questo modo, puoi evitare un'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 esegui più aggiornamenti manuali simultanei, ne verrà completato solo uno.

La cache dei metadati scade dopo 7 giorni se non viene aggiornata.

Gli aggiornamenti manuali e automatici della cache vengono eseguiti con priorità query INTERACTIVE.

Se scegli di utilizzare gli aggiornamenti automatici, ti consigliamo di creare una prenotazione e poi 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 non rischiano di 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 gli esempi seguenti:

  • Se aggiorni manualmente la cache dei metadati di una tabella e imposti l'intervallo di inattività su 2 giorni, devi eseguire la procedura di sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE 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 di una tabella e imposti l'intervallo di inattività su 30 minuti, è possibile che alcune delle operazioni sulla tabella vengano lette dal datastore se l'aggiornamento della cache dei metadati richiede più tempo del solito intervallo di 30-60 minuti.

Per trovare informazioni sui job di aggiornamento dei metadati, esegui una query sulla visualizzazione 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 con cache abilitata con viste materializzate

Puoi utilizzare le visualizzazioni materializzate sulle tabelle BigLake abilitate per la memorizzazione nella cache dei metadati per migliorare le prestazioni e l'efficienza quando esegui query sui dati strutturati archiviati in Cloud Storage o Amazon Simple Storage Service (Amazon S3). Queste visualizzazioni materializzate funzionano come le visualizzazioni materializzate sulle tabelle di archiviazione gestite da BigQuery, inclusi i vantaggi dell'aggiornamento automatico e della 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 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. Gli abbonati possono eseguire query su tutte le tabelle del set di dati collegato, incluse tutte le tabelle BigLake. Per ulteriori informazioni, consulta la sezione Visualizzare e iscriversi alle schede.

BigQuery ML

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

Sensitive Data Protection

Sensitive Data Protection analizza le 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 su tabelle esterne. Vengono invece utilizzati slot per queste query.

La tabella seguente mostra in che modo il modello di prezzi influisce sull'applicazione di questi costi:


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 viene addebitato il costo dei byte elaborate 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 aggiornare la cache dei metadati, BigQuery utilizza automaticamente gli slot nelle prenotazioni QUERY se utilizzi la versione Enterprise o Enterprise Plus.

Ti vengono addebitati anche i costi di archiviazione e accesso ai dati di Cloud Storage, Amazon S3, e Azure Blob Storage, in base alle linee guida sui prezzi di ciascun prodotto.

Passaggi successivi