Introduzione alle tabelle esterne BigLake

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

• Crea tabelle BigLake Cloud Storage e poi esegui query.
• Crea tabelle BigLake Amazon S3 e poi esegui query.
• Crea tabelle BigLake di Azure Blob Storage e poi esegui query.

Puoi anche eseguire l'upgrade di una tabella esterna a BigLake. Per saperne di più, consulta Eseguire l'upgrade di una tabella esterna a BigLake.

Le tabelle BigLake consentono di eseguire query sui dati strutturati in datastore esterni con delega dell'accesso. La delega dell'accesso disaccoppia l'accesso alla tabella BigLake dall'accesso all&#3datastoreti sottostante. Per connettersi all'datastore viene utilizzata una connessione esterna associata a un account di servizio. Poiché l'account di servizio gestisce il recupero dei dati dall&#39datastorei, 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 a livello di colonna. Per le tabelle BigLake basate su Cloud Storage, puoi utilizzare anche la mascheratura dinamica dei dati. Per scoprire di più sulle soluzioni di analisi multi-cloud che utilizzano le tabelle BigLake con i dati di Amazon S3 o Blob Storage, consulta BigQuery Omni.

Datastore supportati

Puoi utilizzare le tabelle BigLake con i seguenti datastore:

• Amazon S3 utilizzando BigQuery Omni
• Blob Storage utilizzando BigQuery Omni
• Cloud Storage

Supporto delle tabelle temporanee

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

Più file di origine

Puoi creare una tabella BigLake basata su più origini dati esterne, a condizione che queste origini dati abbiano lo stesso schema.

Join cross-cloud

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

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

Autorizzazioni richieste per il join cross-cloud

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

Questo ruolo predefinito contiene le autorizzazioni necessarie per eseguire un'unione cross-cloud. Per vedere quali sono esattamente le autorizzazioni richieste, espandi la sezione Autorizzazioni obbligatorie:

Potresti anche ottenere queste autorizzazioni con ruoli personalizzati o altri ruoli predefiniti.

I join 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 saperne di più sui ruoli e sulle autorizzazioni IAM in BigQuery, consulta Introduzione a IAM.

Costi di join cross-cloud

Quando esegui un'operazione di unione cross-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 viene fatto riferimento nella regione BigQuery Omni, che crea una tabella temporanea nella tua regione BigQuery. BigQuery utilizza quindi questa tabella temporanea per eseguire il join cross-cloud ed elimina automaticamente la tabella dopo otto ore.

Sostieni costi di trasferimento dei dati per i dati nelle tabelle BigLake a cui viene fatto 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 per colonne 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 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 di livello) e uno da una tabella dei dipendenti attivi. L'unione viene eseguita nella regione BigQuery dopo il trasferimento. Se un trasferimento non va a buon fine e l'altro riesce, vengono comunque applicati addebiti per il trasferimento di dati riuscito.

Limitazioni del join cross-cloud

• I join cross-cloud non sono supportati nel livello gratuito di BigQuery e nella sandbox di BigQuery.
• Gli aggregati potrebbero non essere inviati alle 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 di dimensioni del trasferimento per ogni trasferimento è di 60 GB. Nello specifico, se applichi un filtro a una tabella BigLake e carichi il risultato, quest'ultimo deve essere inferiore a 60 GB. Se necessario, puoi richiedere un aggiustamento della quota. Non esiste un limite per i byte analizzati.
• Le query di unione cross-cloud utilizzano una quota interna sulla 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. Il nuovo tentativo di esecuzione della query dovrebbe funzionare nella maggior parte dei casi. Contatta l'assistenza per aumentare la quota interna per supportare una frequenza di query più elevata.
• I join cross-cloud sono supportati solo nelle regioni BigQuery collocate con le regioni BigQuery Omni corrispondenti e nelle regioni multiregionali US e EU. I join cross-cloud eseguiti nelle multiregioni US o EU possono accedere solo ai dati nelle regioni BigQuery Omni US o EU rispettivamente.
• Se una query di join cross-cloud fa riferimento a 10 o più set di dati provenienti da regioni BigQuery Omni, potrebbe non riuscire e restituire l'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'unione 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, la query viene eseguita come query cross-cloud e comporta costi di trasferimento dei dati.
• Non puoi interrogare la 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 i valori letterali INTERVAL o RANGE.
• I job di join cross-cloud non segnalano il numero di byte elaborati e trasferiti da altri cloud. Queste informazioni sono disponibili nei job CTAS secondari che vengono creati nell'ambito 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 colonne STRUCT o JSON, non vengono applicati pushdown a nessuna sottoquery remota. Per ottimizzare le prestazioni, valuta la possibilità di creare una vista nella regione BigQuery Omni che filtri le colonne STRUCT e JSON e restituisca solo i campi necessari come colonne individuali.
• Collation non è supportato dai join cross-cloud.

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 per prima alla regione BigQuery Omni. Il risultato è una tabella temporanea nella regione BigQuery. Puoi visualizzare questo job CTAS 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 la creazione della 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 altro 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 eseguita nella regione BigQuery Omni. Tutti i clienti nel segmento di mercato FURNITURE vengono trasferiti prima nella regione BigQuery, poi 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 criteri di governance a livello di riga e colonna a tutto l'accesso ai dati alle tabelle BigLake, anche tramite i connettori.

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

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

Tabelle BigLake negli archivi oggetti

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

Poiché le tabelle BigLake semplificano il controllo dell'accesso in questo modo, ti consigliamo di utilizzarle per creare e gestire le connessioni agli object store esterni.

Puoi utilizzare le tabelle esterne nei casi in cui la governance non è un requisito o per la manipolazione e l'individuazione ad hoc dei dati.

Limitazioni

• Tutte le limitazioni 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 la pagina Quote.

• BigLake non supporta le credenziali con ambito ridotto dell'autenticazione cluster personale 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 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:

  • Avro
  • CSV
  • Delta Lake
  • Iceberg
  • JSON
  • ORC
  • Parquet

• Non puoi utilizzare i metadati memorizzati nella cache con le tabelle esterne di sola lettura 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 solo i metadati memorizzati nella cache 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 query sui file non restituisce i dati aggiornati fino al successivo aggiornamento della cache dei metadati. Ciò può portare a risultati inaspettati. Ad esempio, se elimini un file e ne scrivi uno nuovo, i risultati della query potrebbero escludere sia il vecchio che il nuovo file a seconda dell'ultima data di aggiornamento dei metadati memorizzati nella cache.
  • L'utilizzo delle chiavi di crittografia gestite dal cliente (CMEK) con i metadati memorizzati nella cache non è supportato per le tabelle BigLake che fanno riferimento ai dati di Amazon S3 o Blob Storage.

Modello di sicurezza

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

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

Memorizzazione nella cache dei metadati per le prestazioni

Puoi utilizzare i metadati memorizzati nella cache per migliorare le prestazioni delle query su alcuni tipi di 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 in Hive. I seguenti tipi di tabelle BigLake supportano la memorizzazione nella cache dei metadati:

• Tabelle BigLake Amazon S3
• Tabelle BigLake di Cloud Storage

I metadati includono nomi di file, informazioni di partizionamento e metadati fisici di file come i conteggi di 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 filtri di partizione Apache Hive 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 l'origine dati esterna per ottenere 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 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.

La memorizzazione nella cache dei metadati si integra anche con il controllo delle versioni degli oggetti Cloud Storage. Quando la cache viene compilata o aggiornata, acquisisce i metadati in base alla versione live degli oggetti Cloud Storage in quel momento. Di conseguenza, le query con memorizzazione nella cache dei metadati abilitata leggono i dati corrispondenti alla versione specifica dell'oggetto memorizzato nella cache, anche se le versioni più recenti diventano attive in Cloud Storage. L'accesso ai dati di qualsiasi versione dell'oggetto aggiornata successivamente in Cloud Storage richiede un aggiornamento della cache dei metadati.

Esistono due proprietà che controllano questa funzionalità:

• Massima obsolescenza specifica quando le query utilizzano i metadati memorizzati nella cache.
• La modalità di memorizzazione nella cache dei metadati specifica la modalità di raccolta dei metadati.

Quando la memorizzazione nella cache dei metadati è abilitata, specifichi l'intervallo massimo di obsolescenza 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 più vecchi, l'operazione torna al recupero dei metadati da datastore (Amazon S3 o Cloud Storage). Puoi specificare un intervallo di inattività compreso tra 30 minuti e 7 giorni.

Quando abiliti la memorizzazione nella cache dei metadati per BigLake o le tabelle degli oggetti, BigQuery attiva i job di aggiornamento della generazione dei metadati. 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 alla fine 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. Per le tabelle BigLake, puoi aggiornare i metadati in modo selettivo fornendo le sottodirectory della directory dei dati della tabella. In questo modo puoi evitare l'elaborazione non necessaria dei metadati. L'aggiornamento manuale della cache è un buon approccio se i file del datastore vengono aggiunti, eliminati o modificati a intervalli noti, ad esempio come output di una pipeline.

  Se esegui più aggiornamenti manuali simultanei, solo uno andrà a buon fine.

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.

Utilizzare le prenotazioni BACKGROUND

Se scegli di utilizzare gli aggiornamenti automatici, ti consigliamo di creare una prenotazione e poi un assegnazione con un BACKGROUND tipo di job per il progetto che esegue i job di aggiornamento della cache dei metadati. Con le prenotazioni BACKGROUND, i job di aggiornamento utilizzano un pool di risorse dedicato che impedisce ai job di aggiornamento di competere con le query degli utenti e di non riuscire potenzialmente se non sono disponibili risorse sufficienti.

L'utilizzo di un pool di slot condiviso non comporta costi aggiuntivi, mentre l'utilizzo delle prenotazioni BACKGROUND offre prestazioni più coerenti allocando un pool di risorse dedicato e migliora l'affidabilità dei job di aggiornamento e l'efficienza complessiva delle query in BigQuery.

Prima di impostare i valori dell'intervallo di obsolescenza e della modalità di memorizzazione nella cache dei metadati, valuta la loro interazione. Considera i seguenti esempi:

• Se aggiorni manualmente la cache dei metadati per una tabella e imposti l'intervallo di obsolescenza 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 per una tabella e imposti l'intervallo di obsolescenza su 30 minuti, è possibile che alcune delle tue operazioni sulla tabella vengano lette dal datastore se l'aggiornamento della cache dei metadati richiede più tempo rispetto alla finestra 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 della tabella vengono raccolte durante l'aggiornamento della cache dei metadati e utilizzate per migliorare i piani di query.

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

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

Tabelle abilitate alla cache con viste materializzate

Puoi utilizzare le viste materializzate sulle tabelle abilitate alla cache dei metadati BigLake 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à di BigQuery e servizi gcloud CLI, inclusi i seguenti servizi evidenziati.

BigQuery sharing (in precedenza Analytics Hub)

Le tabelle BigLake sono compatibili con la condivisione. I set di dati contenenti tabelle BigLake possono essere pubblicati come schede di condivisione. I sottoscrittori della condivisione possono iscriversi a queste schede, che forniscono un set di dati di sola lettura, chiamato set di dati collegato, nel loro progetto. Gli abbonati possono eseguire query su tutte le tabelle nel set di dati collegato, incluse tutte le tabelle BigLake. Per ulteriori informazioni, consulta la pagina Visualizzare e abbonarsi alle schede.

BigQuery ML

Puoi utilizzare BigQuery ML per addestrare ed 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 nascondere in altro modo i dati.

Costi

I costi sono associati ai seguenti aspetti delle tabelle BigLake:

• Esecuzione di query sulle tabelle.
• Aggiornamento della cache dei metadati.

Se hai riservazioni 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:

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

Passaggi successivi

• Scopri come eseguire l'upgrade delle tabelle esterne a tabelle BigLake.
• Scopri come creare una tabella BigLake Cloud Storage.
• Scopri come creare una tabella BigLake Amazon S3.
• Scopri come creare una tabella BigLake Blob Storage.
• Scopri come creare controlli della qualità dei dati con Dataplex Universal Catalog.