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' ALTER PROJECT SET OPTIONS instruction ou ALTER ORGANIZATION SET OPTIONS instruction 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 à partir d'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 REGION_2 dans le projet PROJECT_2_ID.

Vous devez activer l'exécution des requêtes globales dans REGION_1 :

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

Et autoriser la copie de données par des requêtes globales à partir de REGION_2 :

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 des données
REGION_2 : région à partir de laquelle les requêtes globales extrairont des données

Ces opérations doivent être exécutées séparément, car elles font référence à des régions différentes. L'application 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 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 aux comptes de service sélectionnés.

Interroger les données

Pour exécuter une requête globale, vous écrivez une requête SQL comme si vos données se trouvaient dans 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 dans lequel exécuter la requête. Les données référencées par la requête qui ne résident pas dans l'emplacement sélectionné sont copiées dans cet emplacement.

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 dans 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 de langage de modification de données (instructions INSERT, UPDATE, DELETE) sont toujours exécutées dans un emplacement de la table cible.
Les requêtes de langage de définition de données, telles que l'instruction CREATE TABLE AS SELECT, sont toujours exécutées dans l'emplacement dans lequel une ressource est créée ou modifiée.
Les requêtes avec une table de destination spécifiée sont toujours exécutées dans l'emplacement où se trouve la table de destination.

Sélection adresse

En général, vous décidez où vos requêtes globales sont exécutées. Pour prendre cette décision, tenez compte des points suivants :

Les requêtes globales copient temporairement des données d'un emplacement à 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 votre requête dans la région où la plupart des données interrogées sont stockées.

Imaginez que vous possédez une boutique en ligne et que vous conservez une liste de vos produits dans l'emplacement us-central1, mais que les transactions se trouvent dans la région us-south1. Si le nombre de transactions est supérieur au nombre 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 qui résident dans différents emplacements, elles doivent être répliquées dans un seul emplacement. Voici une abstraction du workflow de requête globale effectué par BigQuery :

Déterminez où la requête doit être exécutée, soit à partir de la déclaration de l'utilisateur, soit 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 à la fin de la requête dans la région principale.
Copiez ces données des emplacements distants vers l'emplacement principal.
Enregistrez les données dans des tables temporaires dans l'emplacement principal pendant huit heures.
Exécutez une requête finale avec toutes les données collectées dans l'emplacement principal.
Renvoie 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 et, parfois, la quantité de données transférées peut ê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é à la région distante, consultez l'historique des tâches. La tâche distante a le même ID de tâche que la requête d'origine, avec un suffixe _xregion supplémentaire.

Désactiver les requêtes globales

Pour désactiver les requêtes globales pour votre projet ou votre organisation, utilisez le 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

L'application de la modification peut prendre plusieurs minutes.

Tarifs

Le coût d'une requête globale comprend les éléments suivants :

Le coût de calcul de chaque sous-requête dans les emplacements distants, en fonction de votre modèle de tarification dans ces emplacements
Le coût de calcul de la requête finale dans la région dans laquelle elle est exécutée, en fonction de votre modèle de tarification dans cette région
Le coût de la copie de données entre différents emplacements, conformément aux tarifs de la réplication des données
Le coût du stockage des données copiées des régions distantes vers la région principale (pendant huit heures), conformément aux 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'affichent pas le nombre d'octets traités et transférés à partir d'emplacements distants. Ces informations apparaissent dans les tâches de copie que vous pouvez trouver dans l'historique des tâches. L'ID de tâche d'une tâche de copie créée par une requête globale a l'ID de tâche de la tâche de requête comme préfixe.
Les requêtes globales ne sont pas compatibles avec le mode bac à sable.
Les requêtes globales entraînent une latence plus élevée que les requêtes à une seule région en raison du temps nécessaire pour transférer des données entre les régions.
Les requêtes globales n'utilisent aucun cache pour éviter de transférer des données entre les régions.
Vous ne pouvez pas interroger de pseudo-colonnes, telles que _PARTITIONTIME, avec des requêtes globales.
Vous ne pouvez pas interroger de colonnes à l'aide de noms de colonnes flexibles avec des requêtes globales.
Vous ne pouvez pas interroger INFORMATION_SCHEMA vues à partir d'une région distante dans une requête globale.
Vous ne pouvez pas interroger de tables Apache Iceberg BigLake Metastore à partir d'une région distante dans une requête globale.
Lorsque vous référencez les colonnes d'une table BigLake dans une clause WHERE, vous ne pouvez pas utiliser de littéraux RANGE ni INTERVAL.
Les vues autorisées globales et les routines autorisées ne sont pas compatibles (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 compatibles.
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 en tant que colonnes individuelles.
Les requêtes globales ne sont pas exécutées de manière atomique. Dans les cas où la réplication des données réussit, mais où la requête globale échoue, la réplication des données vous est quand même facturée.
Les tables temporaires créées dans des régions distantes dans le cadre 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 de la requête globale (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 clés 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 compatibles avec Assured Workloads.
Vous pouvez interroger un maximum de 10 tables par région dans une requête globale.