Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Query globali

Le query globali consentono di eseguire query SQL che fanno riferimento a dati archiviati in più di una regione. Ad esempio, puoi eseguire una query globale che unisce 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 assicurati di disporre delle autorizzazioni necessarie per eseguirle.

Abilita le query globali

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

Per eseguire query globali in una regione, imposta l'argomento enable_global_queries_execution su true nella 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 contenente i dati.
Queste opzioni vengono selezionate ogni volta che la query accede a tabelle remote.
Le query globali possono essere eseguite in un progetto ed estrarre dati da altre regioni da 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 acceda 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 tramite query globali dal progetto contenente i dati (data_project) per la relativa regione (europe-west1):
```
ALTER PROJECT `data_project`
SET OPTIONS (
`region-europe-west1.enable_global_queries_data_access` = TRUE
);
```

Per creare e utilizzare visualizzazioni 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. Potrebbero essere necessari diversi minuti prima che la modifica abbia effetto.

Autorizzazione obbligatoria

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

Crea un ruolo personalizzato, ad esempio "Esecutore 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 posizione. Se i dati a cui fa riferimento la query sono archiviati in più di una località, BigQuery tenta di eseguire una query globale. Se non specifichi la località in cui eseguire la query, BigQuery seleziona automaticamente la località in base alle posizioni delle tabelle a cui viene fatto riferimento. Per saperne di più, vedi Scegliere una località. 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 unisce tabelle di due set di dati diversi archiviati in due posizioni 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

Scegli una località

Per configurare la posizione in cui verrà eseguita la query globale, specifica una località. Quando scegli una località di esecuzione per la query globale, considera quanto segue:

Residenza dei dati:le query globali copiano temporaneamente i dati da una posizione all'altra. Se la tua organizzazione ha requisiti per la residenza dei dati e non vuoi che i tuoi dati lascino una determinata località, imposta la località della query su quella località.
Costi e prestazioni del trasferimento:per ridurre al minimo la quantità di dati trasferiti tra le località e ridurre il costo della query, esegui la query nella regione in cui è archiviata la maggior parte dei dati su cui viene eseguita la query.

Ad esempio, hai un negozio online e conservi un elenco dei tuoi prodotti nella località us-central1, ma conservi le transazioni nella regione us-south1. Se nel tuo catalogo sono presenti più transazioni che prodotti, devi eseguire la query nella regione us-south1.
Prenotazioni e capacità di calcolo:specifica la posizione della query per controllare quali prenotazioni o slot regionali elaborano la query.

Se non specifichi manualmente una località, BigQuery determina automaticamente la località di esecuzione in base ai seguenti criteri:

Per le query DML (Data Modification Language) (istruzioni INSERT, UPDATE e DELETE), la posizione della tabella di destinazione viene selezionata come posizione di esecuzione.
Per le query DDL (Data Definition Language), ad esempio le istruzioni CREATE TABLE AS SELECT, la località in cui viene creata o modificata la risorsa viene selezionata come località di esecuzione.
Per le query con una tabella di destinazione specificata, la posizione della tabella di destinazione viene selezionata come posizione di esecuzione.
Per tutte le altre query, la località di esecuzione viene selezionata arbitrariamente come una delle località dei set di dati a cui viene fatto riferimento.

Informazioni sulle query globali

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

Per utilizzare i dati che si trovano in posizioni diverse, è necessario replicarli in una posizione. Di seguito è riportata un'astrazione del flusso di lavoro della query globale eseguita da BigQuery:

Determina dove deve essere eseguita la query, ovvero dalla dichiarazione dell'utente o automaticamente. Questa posizione è chiamata posizione principale e tutte le altre posizioni 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 nella località principale.
Salva i dati nelle tabelle temporanee nella posizione principale per 24 ore.
Esegui una query finale con tutti i dati raccolti nella posizione principale.
Restituisce i risultati della query.

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

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 monitorare le query globali e ispezionare la loro esecuzione nelle varie regioni, puoi utilizzare i seguenti metodi:

Cronologia dei job

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

API REST Jobs

Quando chiami il metodo jobs.get, la risorsa Job restituita contiene i seguenti campi nell'oggetto JobStatistics:

statistics.global_query_remote_regions: un array di stringhe che rappresentano le regioni remote da cui una query globale accede ai dati. Questo campo viene compilato solo per i job di query globale principali nella regione di esecuzione principale. È vuoto per i job di query globali secondari e le query a singola regione.
statistics.parent_global_query_job: un oggetto JobReference (projectId, jobId, location) che identifica il job di query globale principale. Questo campo viene compilato solo per i job di query globale secondari (query secondarie remote e job di copia tra regioni) eseguiti in regioni remote per conto di una query globale. Non è impostato per i job di query globali principali e le query a singola regione.

Audit log

In Cloud Audit Logs, l'oggetto BigQueryAuditMetadata contiene i seguenti campi nell'oggetto JobStats:

jobStats.globalQueryRemoteRegions: un array di stringhe che rappresentano le regioni remote a cui accede la query. Questo campo viene compilato solo per i job di query globale principali nella regione di esecuzione principale.
jobStats.parentGlobalQueryJobId: l'ID job del job di query globale principale. Questo campo viene compilato per i job secondari eseguiti in regioni remote.
jobStats.parentGlobalQueryJobLocation: la posizione del job di query globale principale. Questo campo viene compilato per i job secondari eseguiti in regioni remote.

Trovare job figli remoti per una query globale

Per trovare tutti i job secondari remoti associati a una query globale principale, puoi eseguire query sugli audit log utilizzando Analisi dei log o un set di dati del sink di log esportato:

SELECT
  timestamp,
  proto_payload.audit_log.resource_name AS resource_name,
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobConfig.queryConfig.query) AS query
FROM
  `PROJECT_ID.LOG_DATASET._AllLogs`
WHERE
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobStats.parentGlobalQueryJobId) = 'PARENT_JOB_ID';

Sostituisci quanto segue:

PROJECT_ID: l'ID del tuo progetto Google Cloud.
LOG_DATASET: il set di dati collegato a BigQuery per l'analisi dei log o il set di dati di destinazione sink di log.
PARENT_JOB_ID: l'ID job del job di query globale principale.

Disattivare le query globali

Per disattivare 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 disattivare 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 disattivare le query globali

Potrebbero essere necessari diversi minuti prima che la modifica abbia effetto.

Prezzi

Il costo di una query globale è costituito 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 determinazione del prezzo 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 nella regione principale (per 24 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 non sono supportate quando utilizzi endpoint regionali.
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 regioni.
Non puoi eseguire query sulle pseudocolonne, ad esempio _PARTITIONTIME, con le query globali.
Non puoi eseguire query sulle colonne di tipo RANGE con query globali.
Non puoi eseguire query sulle colonne utilizzando nomi di colonne flessibili con query globali.
Non puoi eseguire query sulle viste INFORMATION_SCHEMA da una regione remota in una query globale.
Le visualizzazioni autorizzate e le routine autorizzate globali non sono supportate (quando una visualizzazione o una routine in una posizione è autorizzata ad accedere al set di dati in un'altra posizione). Crea invece viste autorizzate nella regione in cui si trovano i dati ed esegui query sulle viste autorizzate tramite query globali.
Le viste materializzate sulle query globali non sono supportate.
Se la query globale fa riferimento a colonne STRUCT, non vengono applicati pushdown a nessuna sottoquery remota. Per ottimizzare le prestazioni, 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 va a buon fine, ma la query complessiva non riesce, ti viene comunque addebitato il costo della replica dei dati.
Le tabelle temporanee create in regioni remote nell'ambito dell'esecuzione di query globali vengono criptate solo utilizzando chiavi di crittografia gestite dal cliente (CMEK) se una chiave CMEK configurata per criptare i risultati della query globale (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.
Le query globali sono supportate solo in Data Studio quando sono racchiuse in una vista e configurate per utilizzare le credenziali del visualizzatore.