Requêtes globales

Les requêtes globales vous permettent d'exécuter des requêtes SQL qui font référence à des données stockées dans plusieurs régions. Par exemple, vous pouvez exécuter une requête globale qui joint une table située dans us-central1 à une table située dans europe-central2. Ce document explique comment activer et exécuter des requêtes globales dans votre projet.

Avant de commencer

Vérifiez que les requêtes globales sont activées pour votre projet et que vous disposez des autorisations nécessaires pour les exécuter.

Activer les requêtes globales

Pour activer les requêtes globales pour votre projet ou votre organisation, utilisez l'instruction ALTER PROJECT SET OPTIONS ou l'instruction ALTER ORGANIZATION SET OPTIONS pour modifier la configuration par défaut.

Pour exécuter des requêtes globales dans une région, définissez l'argument enable_global_queries_execution sur true dans cette région pour un projet dans lequel la requête est exécutée.
Pour autoriser les requêtes globales à copier des données depuis une région, définissez l'argument enable_global_queries_data_access sur true dans cette région pour un projet dans lequel les données sont stockées.
Les requêtes globales peuvent s'exécuter dans un projet et extraire des données d'autres régions à partir d'un autre projet.

L'exemple suivant montre comment modifier ces paramètres au niveau du projet. Supposons que vous souhaitiez exécuter des requêtes globales dans la région REGION_1 du projet PROJECT_1_ID et extraire des données de la région REGION_2 du projet PROJECT_2_ID :

ALTER PROJECT `PROJECT_1_ID`
SET OPTIONS (
  `region-REGION_1.enable_global_queries_execution` = true
);
ALTER PROJECT `PROJECT_2_ID`
SET OPTIONS (
  `region-REGION_2.enable_global_queries_data_access` = true
);

Remplacez les éléments suivants :

PROJECT_1_ID : nom du projet dans lequel les requêtes globales seront exécutées
REGION_1 : région dans laquelle les requêtes globales seront exécutées
PROJECT_2_ID : nom du projet à partir duquel les requêtes globales extrairont les données.
REGION_2 : région à partir de laquelle les requêtes globales extrairont les données.

La prise en compte de la modification peut prendre plusieurs minutes.

Autorisation requise

Pour exécuter une requête globale, vous devez disposer de l'autorisation bigquery.jobs.createGlobalQuery. Le rôle Administrateur BigQuery est le seul rôle prédéfini qui contient cette autorisation. Pour accorder l'autorisation d'exécuter des requêtes globales sans accorder le rôle d'administrateur BigQuery, procédez comme suit :

Créez un rôle personnalisé, par exemple "Exécuteur de requêtes globales BigQuery".
Ajoutez bigquery.jobs.createGlobalQuery à ce rôle.
Attribuez ce rôle aux utilisateurs ou comptes de service sélectionnés.

Interroger les données

Pour exécuter une requête globale, vous devez rédiger une requête SQL comme si vos données se trouvaient à un seul emplacement. Si les données référencées par la requête sont stockées dans plusieurs emplacements, BigQuery tente d'exécuter une requête globale. Dans certains cas, BigQuery sélectionne automatiquement l'emplacement de la requête. Sinon, vous devez spécifier l'emplacement où exécuter la requête. Les données référencées par la requête qui ne se trouvent pas dans l'emplacement sélectionné y sont copiées.

L'exemple suivant s'exécute en tant que requête globale qui regroupe des tables provenant de deux ensembles de données différents stockés à deux emplacements différents :

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

Sélection automatique de l'emplacement

Dans les cas suivants, l'emplacement dans lequel une requête doit être exécutée est déterminé automatiquement et ne peut pas être modifié :

Les requêtes du langage de modification de données (instructions INSERT, UPDATE et DELETE) sont toujours exécutées dans un emplacement de la table cible.
Les requêtes LDD (langage de définition de données), telles que l'instruction CREATE TABLE AS SELECT, sont toujours exécutées dans l'emplacement où une ressource est créée ou modifiée.
Les requêtes avec une table de destination spécifiée sont toujours exécutées à l'emplacement de la table de destination.

Sélection adresse

En général, vous décidez où exécuter vos requêtes globales. Pour prendre cette décision, tenez compte des éléments suivants :

Les requêtes globales copient temporairement les données d'un emplacement vers un autre. Si votre organisation a des exigences concernant la résidence des données et que vous ne souhaitez pas que vos données de l'emplacement A quittent cet emplacement, définissez l'emplacement de la requête sur A.
Pour minimiser la quantité de données transférées entre les emplacements et réduire le coût de la requête, exécutez-la dans la région où la plupart des données interrogées sont stockées.

Imaginons que vous ayez une boutique en ligne et que vous conserviez une liste de vos produits à l'emplacement us-central1, mais que les transactions aient lieu dans la région us-south1. S'il y a plus de transactions que de produits dans votre catalogue, vous devez exécuter la requête dans la région us-south1.

Comprendre les requêtes globales

Pour exécuter des requêtes globales de manière efficace et économique, il est important de comprendre le mécanisme qui sous-tend leur exécution.

Pour utiliser des données résidant à différents emplacements, vous devez les répliquer dans un seul emplacement. Voici une abstraction du workflow de requête global effectué par BigQuery :

Déterminez où la requête doit être exécutée (à partir de la déclaration de l'utilisateur ou automatiquement). Cet emplacement est appelé emplacement principal, et tous les autres emplacements référencés par la requête sont distants.
Exécutez une sous-requête dans chaque région distante pour collecter les données nécessaires à l'exécution de la requête dans la région principale.
Copiez ces données depuis des emplacements distants vers l'emplacement principal.
Enregistrez les données dans des tables temporaires de l'emplacement principal pendant huit heures.
Exécutez une requête finale avec toutes les données collectées dans l'emplacement principal.
Renvoyez les résultats de la requête.

BigQuery tente de minimiser la quantité de données transférées entre les régions. Prenons l'exemple suivant :

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 n'a pas besoin de répliquer l'intégralité de la table t2 des États-Unis vers l'UE. Il suffit de transférer uniquement les colonnes demandées (col2 et col3) et uniquement les lignes qui correspondent à la condition WHERE (t2.col4 = 'ABC'). Toutefois, ces mécanismes, appelés pushdowns, dépendent de la structure de la requête. La quantité de données transférées peut parfois être importante. Nous vous recommandons de tester les requêtes globales sur un petit sous-ensemble de données et de vérifier que les données ne sont transférées que lorsque cela est nécessaire.

Observabilité

Pour afficher le texte de la requête envoyée à la région distante, consultez l'historique des tâches. Le job à distance possède le même ID que la requête d'origine, avec un suffixe _xregion.

Désactiver les requêtes globales

Pour désactiver les requêtes globales pour votre projet ou votre organisation, utilisez ALTER PROJECT SET OPTIONS statement ou ALTER ORGANIZATION SET OPTIONS statement pour modifier la configuration par défaut.

Pour désactiver les requêtes globales dans une région, définissez l'argument enable_global_queries_execution sur false ou NULL dans cette région.
Pour interdire aux requêtes globales de copier des données à partir d'une région, définissez l'argument enable_global_queries_data_access sur false ou NULL dans cette région.

L'exemple suivant montre comment désactiver les requêtes globales au niveau du projet :

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

Remplacez les éléments suivants :

PROJECT_ID : nom du projet à modifier
REGION : nom de la région dans laquelle désactiver les requêtes globales

La prise en compte de la modification peut prendre plusieurs minutes.

Tarifs

Le coût d'une requête globale se compose des éléments suivants :

Coût de calcul de chaque sous-requête dans les emplacements distants, en fonction de votre modèle de tarification dans ces emplacements
Coût de calcul de la requête finale dans la région où elle est exécutée, en fonction de votre modèle de tarification dans cette région
Coût de la copie de données entre différents emplacements, selon les tarifs de la réplication des données
Le coût du stockage des données copiées depuis des régions distantes vers la région principale (pendant huit heures), selon les tarifs de stockage

Quotas

Pour en savoir plus sur les quotas concernant les requêtes globales, consultez la page Jobs de requête.

Limites

Les détails d'exécution et le graphique d'exécution d'une requête n'indiquent pas le nombre d'octets traités et transférés depuis des emplacements distants. Ces informations apparaissent dans les jobs de copie que vous trouverez dans votre historique des jobs. L'ID de job d'un job de copie créé par une requête globale a l'ID de job de la requête comme préfixe.
Les requêtes globales ne sont pas acceptées en mode bac à sable
Les requêtes globales entraînent une latence plus élevée que les requêtes monorégionales en raison du temps nécessaire pour transférer les données entre les régions.
Les requêtes globales n'utilisent aucun cache pour éviter le transfert de données entre régions.
Vous ne pouvez pas interroger les pseudo-colonnes, telles que _PARTITIONTIME, avec des requêtes globales.
Vous ne pouvez pas interroger des colonnes à l'aide de noms de colonnes flexibles avec des requêtes globales.
Lorsque vous référencez les colonnes d'une table BigLake dans une clause WHERE, vous ne pouvez pas utiliser les littéraux RANGE ni INTERVAL.
Les vues autorisées et les routines autorisées globales ne sont pas acceptées (lorsqu'une vue ou une routine dans un emplacement est autorisée à accéder à un ensemble de données dans un autre emplacement).
Les vues matérialisées sur les requêtes globales ne sont pas prises en charge.
Si votre requête globale fait référence à des colonnes STRUCT, aucun pushdown n'est appliqué aux sous-requêtes distantes. Pour optimiser les performances, envisagez de créer une vue dans la région distante qui filtre les colonnes STRUCT et ne renvoie que les champs nécessaires sous forme de colonnes individuelles.
Les requêtes globales ne sont pas exécutées de manière atomique. Si la réplication des données réussit, mais que la requête globale échoue, la réplication des données vous sera quand même facturée.
Les tables temporaires créées dans des régions distantes lors de l'exécution de requêtes globales ne sont chiffrées à l'aide de clés de chiffrement gérées par le client (CMEK) que si une clé CMEK configurée pour chiffrer les résultats des requêtes globales (au niveau d'une table, d'un ensemble de données ou d'un projet) est globale. Pour vous assurer que les tables temporaires distantes sont toujours protégées à l'aide de CMEK, définissez une clé KMS par défaut pour le projet exécutant des requêtes globales dans la région distante.
Les requêtes globales ne sont pas acceptées dans Assured Workloads.
Vous pouvez interroger un maximum de 10 tables par région dans une requête globale.