Query globali

Le query globali ti consentono di eseguire query SQL che fanno riferimento a dati archiviati in più di una regione. Ad esempio, puoi eseguire una query globale che esegue un join di una tabella che si trova in us-central1 con una tabella che si trova in europe-central2. Questo documento spiega come abilitare ed eseguire query globali nel tuo progetto.

Prima di iniziare

Verifica che le query globali siano abilitate per il tuo progetto e di disporre delle autorizzazioni necessarie per eseguirle.

Abilitare le query globali

Per abilitare le query globali per il tuo progetto o la tua organizzazione, utilizza l' istruzione o l'istruzione per modificare la configurazione predefinita.ALTER PROJECT SET OPTIONSALTER ORGANIZATION SET OPTIONS

Per eseguire query globali in una regione, imposta l'argomento enable_global_queries_execution su true in quella regione per il progetto che esegue la query.
Per consentire alle query globali di copiare i dati da una regione, imposta l'argomento enable_global_queries_data_access su true in quella regione per il progetto che contiene i dati.
Queste opzioni vengono controllate ogni volta che la query accede a tabelle remote.
Le query globali possono essere eseguite in un progetto ed estrarre dati da altre regioni di un altro progetto.

Esempio: configurazione tra progetti

L'esempio seguente mostra come eseguire una query in un progetto che accede a una tabella in un altro progetto.

Supponiamo che tu abbia un progetto query_project che esegue job nella regione us-central1 e che tu voglia eseguire una query che accede a una tabella data_project.dataset.my_table che si trova nella regione europe-west1:

SET @@location='us-central1';
SELECT
  *
FROM
  `query_project.dataset.my_table`
  JOIN `data_project.dataset.my_other_table` USING id;

Per consentire l'esecuzione corretta di questa query globale, è necessaria la seguente configurazione:

Devi abilitare l'esecuzione di query globali nel progetto (query_project) nella regione che esegue una query globale (us-central1):
```
ALTER PROJECT `query_project`
SET OPTIONS (
`region-us-central1.enable_global_queries_execution` = TRUE
);
```
Devi abilitare la copia dei dati da parte delle query globali dal progetto che contiene i dati (data_project) per la sua regione (europe-west1):
```
ALTER PROJECT `data_project`
SET OPTIONS (
`region-europe-west1.enable_global_queries_data_access` = TRUE
);
```

Per creare e utilizzare viste che contengono tabelle remote, si applicano gli stessi principi: il progetto che esegue le query deve avere enable_global_queries_execution abilitato.

Queste operazioni ALTER PROJECT devono essere eseguite separatamente perché fanno riferimento a progetti e regioni diversi. L'applicazione della modifica può richiedere alcuni minuti.

Autorizzazione obbligatoria

Per eseguire una query globale, devi disporre dell'autorizzazione bigquery.jobs.createGlobalQuery. Il ruolo Amministratore BigQuery è l'unico ruolo predefinito che contiene questa autorizzazione. Per concedere l'autorizzazione a eseguire query globali senza concedere il ruolo Amministratore BigQuery, segui questi passaggi:

Crea un ruolo personalizzato, ad esempio "Esecutore di query globali BigQuery".
Aggiungi bigquery.jobs.createGlobalQuery a questo ruolo.
Assegna questo ruolo agli utenti o ai service account selezionati.

Esegui query sui dati

Per eseguire una query globale, scrivi una query SQL come se i dati si trovassero in un'unica località. Se i dati a cui fa riferimento la query sono archiviati in più di una località, BigQuery tenta di eseguire una query globale. In alcuni casi, BigQuery seleziona automaticamente la località della query. In caso contrario, devi specificare la località in cui eseguire la query. I dati a cui fa riferimento la query che non si trovano nella località selezionata vengono copiati in quella località.

L'esempio seguente viene eseguito come query globale che esegue l'unione di tabelle di due set di dati diversi archiviati in due località diverse:

SELECT id, tr_date, product_id, price FROM us_dataset.transactions
UNION ALL
SELECT id, tr_date, product_id, price FROM europe_dataset.transactions

Selezione automatica della località

Nei seguenti casi, la località in cui deve essere eseguita una query viene determinata automaticamente e non può essere modificata:

Le query del linguaggio di modifica dei dati (istruzioni INSERT, UPDATE, DELETE) vengono sempre eseguite in una località della tabella di destinazione.
Le query del linguaggio di definizione dei dati, come l'istruzione CREATE TABLE AS SELECT, vengono sempre eseguite nella località in cui viene creata o modificata una risorsa.
Le query con una tabella di destinazione specificata vengono sempre eseguite nella località in cui si trova la tabella di destinazione.

Scegli una località

In generale, decidi tu dove vengono eseguite le query globali. Per prendere questa decisione, tieni presente quanto segue:

Le query globali copiano temporaneamente i dati da una località all'altra. Se la tua organizzazione ha requisiti di residenza dei dati e non vuoi che i dati della località A lascino la località A, imposta la località della query su A.
Per ridurre al minimo la quantità di dati trasferiti tra le località e il costo della query, esegui la query nella regione in cui sono archiviati la maggior parte dei dati sottoposti a query.

Supponiamo che tu abbia un negozio online e che tu mantenga un elenco dei tuoi prodotti nella località us-central1, ma le transazioni nella us-south1 regione. Se nel tuo catalogo sono presenti più transazioni che prodotti, devi eseguire la query nella regione us-south1.

Informazioni sulle query globali

Per eseguire query globali in modo efficiente ed economico, è importante comprendere il meccanismo alla base della loro esecuzione.

Per utilizzare i dati che si trovano in località diverse, è necessario replicarli in una località. Di seguito è riportata un'astrazione del flusso di lavoro delle query globali eseguito da BigQuery:

Determina dove deve essere eseguita la query, in base alla dichiarazione dell'utente o automaticamente. Questa località è chiamata località primaria e tutte le altre località a cui fa riferimento la query sono remote.
Esegui una sottoquery in ogni regione remota per raccogliere i dati necessari per completare la query nella regione primaria.
Copia questi dati dalle località remote alla località primaria.
Salva i dati nelle tabelle temporanee nella località primaria per 8 ore.
Esegui una query finale con tutti i dati raccolti nella località primaria.
Restituisci i risultati della query.

BigQuery tenta di ridurre al minimo la quantità di dati trasferiti tra le regioni. Considera il seguente esempio:

SET @@location = 'EU';
SELECT
  t1.col1, t2.col2
FROM
  eu_dataset.table1 t1
  JOIN us_dataset.table2 t2 using col3
WHERE
  t2.col4 = 'ABC'

BigQuery non deve replicare l'intera tabella t2 dagli Stati Uniti all'UE. È sufficiente trasferire solo le colonne richieste (col2 e col3) e solo le righe che corrispondono alla condizione WHERE (t2.col4 = 'ABC'). Tuttavia, questi meccanismi, noti come pushdown, dipendono dalla struttura della query e a volte la quantità di dati trasferiti potrebbe essere elevata. Ti consigliamo di testare le query globali su un piccolo sottoinsieme di dati e di verificare che i dati vengano trasferiti solo quando necessario.

Osservabilità

Per visualizzare il testo della query inviato alla regione remota, controlla la cronologia dei job. Il job remoto ha lo stesso ID job della query originale con un suffisso _xregion aggiuntivo.

Disattivare le query globali

Per disabilitare le query globali per il tuo progetto o la tua organizzazione, utilizza ALTER PROJECT SET OPTIONS statement o ALTER ORGANIZATION SET OPTIONS statement per modificare la configurazione predefinita.

Per disattivare le query globali in una regione, imposta l'argomento enable_global_queries_execution su false o NULL in quella regione.
Per impedire alle query globali di copiare i dati da una regione, imposta l'argomento enable_global_queries_data_access su false o NULL in quella regione.

L'esempio seguente mostra come disabilitare le query globali a livello di progetto:

ALTER PROJECT PROJECT_ID
SET OPTIONS (
  `region-REGION.enable_global_queries_execution` = false,
  `region-REGION.enable_global_queries_data_access` = false
);

Sostituisci quanto segue:

PROJECT_ID: il nome del progetto da modificare
REGION: il nome della regione in cui disabilitare le query globali

L'applicazione della modifica può richiedere alcuni minuti.

Prezzi

Il costo di una query globale è composto dai seguenti componenti:

Il costo di calcolo di ogni sottoquery nelle località remote, in base al tuo modello di prezzi in queste località
Il costo di calcolo della query finale nella regione in cui viene eseguita, in base al tuo modello di prezzi in quella regione
Il costo della copia dei dati tra località diverse, in base ai prezzi della replica dei dati
Il costo di archiviazione dei dati copiati dalle regioni remote alla regione primaria (per 8 ore), in base ai prezzi di archiviazione

Quote

Per informazioni sulle quote relative alle query globali, consulta Job di query.

Limitazioni

I dettagli di esecuzione e il grafico di esecuzione di una query non mostrano il numero di byte elaborati e trasferiti dalle località remote. Queste informazioni vengono visualizzate nei job di copia che puoi trovare nella cronologia dei job. L'ID job di un job di copia creato da una query globale ha l'ID job del job di query come prefisso.
Le query globali non sono supportate in modalità sandbox.
Le query globali comportano una latenza maggiore rispetto alle query a singola regione a causa del tempo necessario per trasferire i dati tra le regioni.
Le query globali non utilizzano alcuna cache per evitare il trasferimento di dati tra le regioni.
Non puoi eseguire query sulle pseudocolonne, ad esempio _PARTITIONTIME, con le query globali.
Non puoi eseguire query sulle colonne utilizzando nomi di colonne flessibili con le query globali.
Non puoi eseguire query sulle viste INFORMATION_SCHEMA da una regione remota in una query globale.
Non puoi eseguire query sulle tabelle Apache Iceberg del metastore BigLake da una regione remota in una query globale.
Quando fai riferimento alle colonne di una tabella BigLake in una clausola WHERE, non puoi utilizzare i valori letterali RANGE o INTERVAL.
Le viste autorizzate globali e le routine autorizzate non sono supportate (quando una vista o una routine in una località è autorizzata ad accedere al set di dati in un'altra località).
Le viste materializzate sulle query globali non sono supportate.
Se la query globale fa riferimento a colonne STRUCT, non vengono applicati pushdown alle sottoquery remote. Per ottimizzare il rendimento, valuta la possibilità di creare una vista nella regione remota che filtri le colonne STRUCT e restituisca solo i campi necessari come singole colonne.
Le query globali non vengono eseguite in modo atomico. Nei casi in cui la replica dei dati ha esito positivo, ma la query complessiva non riesce, ti viene comunque addebitata la replica dei dati.
Le tabelle temporanee create nelle regioni remote nell'ambito dell'esecuzione delle query globali vengono criptate utilizzando le chiavi di crittografia gestite dal cliente (CMEK) solo se una chiave CMEK configurata per criptare i risultati delle query globali (a livello di tabella, set di dati o progetto) è globale. Per assicurarti che le tabelle temporanee remote siano sempre protette utilizzando CMEK, imposta una chiave KMS predefinita per il progetto che esegue query globali nella regione remota.
Le query globali non sono supportate in Assured Workloads.
Una singola query globale può accedere a un massimo di 10 tabelle remote per regione.