Ensemble des requêtes

Aperçu

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres pré-DG" de la section "Conditions d'utilisation générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Remarque : Pour obtenir de l'aide ou envoyer des commentaires sur cette fonctionnalité en preview, contactez [e-mail].

Les requêtes globales vous permettent d'exécuter des requêtes SQL qui référencent 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 le projet exécutant la requête.
• 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 le projet contenant les données.
• Ces options sont vérifiées chaque fois que votre requête accède à des tables distantes.
• 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.

Exemple : Configuration inter-projets

L'exemple suivant montre comment exécuter une requête dans un projet qui accède à une table dans un autre projet.

Supposons que vous ayez un projet query_project exécutant des tâches dans la région us-central1 et que vous souhaitiez exécuter une requête qui accède à une table data_project.dataset.my_table située dans la région europe-west1 :

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

Pour que cette requête globale s'exécute correctement, la configuration suivante est requise :

1. Vous devez activer l'exécution des requêtes globales dans le projet (query_project) de la région exécutant une requête globale (us-central1) :

   ALTER PROJECT `query_project`
   SET OPTIONS (
   `region-us-central1.enable_global_queries_execution` = TRUE
   );

2. Vous devez activer la copie des données par les requêtes globales à partir du projet contenant les données (data_project) pour sa région (europe-west1) :

   ALTER PROJECT `data_project`
   SET OPTIONS (
   `region-europe-west1.enable_global_queries_data_access` = TRUE
   );

Pour créer et utiliser des vues contenant des tables distantes, les mêmes principes s'appliquent : la fonctionnalité enable_global_queries_execution doit être activée pour le projet exécutant les requêtes.

Ces opérations ALTER PROJECT doivent être exécutées séparément, car elles font référence à des projets et des régions différents. 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 :

1. Créez un rôle personnalisé, par exemple "Exécuteur de requêtes globales BigQuery".
2. Ajoutez bigquery.jobs.createGlobalQuery à ce rôle.
3. 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 se trouvent 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 combine 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 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 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 ont lieu 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 résidant 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 :

1. 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.
2. 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.
3. Copiez ces données des emplacements distants vers l'emplacement principal.
4. Enregistrez les données dans des tables temporaires de l'emplacement principal pendant huit heures.
5. Exécutez une requête finale avec toutes les données collectées dans l'emplacement principal.
6. 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 composants 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 des 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 au transfert des données entre les régions.
• Les requêtes globales n'utilisent aucun cache pour éviter le transfert de 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. 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 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.
• Une seule requête globale peut accéder à un maximum de 10 tables distantes par région.