L’emplacement d’un dataset BigQuery est défini à la création et ne peut pas être modifié par la suite. Un dataset mal placé peut bloquer l’ensemble d’un workflow analytique.
Multi-région vs. région unique
BigQuery propose des multi-régions (US, EU) et plus de 40 régions uniques dans le monde. Elles répondent à des besoins différents.
Les multi-régions stockent les données dans plusieurs centres de données au sein d’une zone géographique. La multi-région US peut placer vos données en Iowa, en Oregon ou en Oklahoma. Vous ne contrôlez pas laquelle, mais Google garantit que les données restent aux États-Unis. Les multi-régions offrent une disponibilité supérieure et de plus larges quotas de slots. Elles constituent le choix par défaut adapté à la plupart des workloads analytiques.
Les régions uniques garantissent la résidence des données dans un emplacement géographique précis. Les données dans europe-west1 restent en Belgique. Point. Cela importe pour la conformité réglementaire mais offre moins de redondance.
Le prix est généralement équivalent entre les régions pour la plupart des workloads. Le choix de région doit être guidé par les exigences, non par le coût.
La contrainte de jointure inter-régions
Tous les datasets joints dans une seule requête doivent être dans le même emplacement.
Les jointures inter-régions échouent immédiatement. Le message d’erreur (“Access Denied: BigQuery BigQuery: Not found: Dataset”) n’identifie pas le décalage régional comme cause, ce qui rend le diagnostic difficile.
Si les tables principales sont dans US et qu’une table de référence est créée dans EU, chaque requête les joignant échoue. La correction implique de recréer le dataset dans la bonne région : exporter vers Cloud Storage, créer de nouvelles ressources dans la région cible, recharger les données, et mettre à jour toutes les références. bq cp est limité à 1 000 tables par jour.
Cette contrainte est absolue — sans contournement, sans opt-in, sans interrogation inter-régions à coût supérieur.
Comment choisir votre région
Prenez cette décision une seule fois, documentez-la et faites-la respecter.
Les exigences réglementaires imposent souvent des régions spécifiques. La conformité RGPD peut nécessiter un stockage exclusivement EU pour les données clients européens. Les réglementations du secteur de la santé peuvent imposer des frontières géographiques précises. Consultez votre équipe juridique en premier — ce n’est pas quelque chose que vous pouvez différer.
La proximité avec les utilisateurs affecte la latence des tableaux de bord. Si vos analystes sont à Paris, les données dans europe-west1 se chargent plus vite que dans us-central1. Cela importe moins pour les traitements batch, mais affecte significativement l’exploration interactive et la réactivité des outils BI.
La co-localisation avec les sources de données améliore les performances de chargement. Les buckets Cloud Storage et les datasets BigQuery dans la même région transfèrent les données plus rapidement et moins cher. Si votre pipeline d’événements atterrit des données dans un bucket GCS dans us-central1, vos datasets bruts devraient y être aussi. La co-localisation est particulièrement importante pour les patterns de chargement batch où de grands volumes transitent régulièrement entre GCS et BigQuery.
Les standards organisationnels comptent le plus. Choisissez une région (ou une multi-région) et utilisez-la partout. Les bénéfices de la flexibilité régionale dépassent rarement le risque d’erreurs inter-régions. Pour la plupart des équipes d’analytics engineering, tout consolider dans une seule région est le bon choix.
Les coûts de transfert de données inter-régions vont de 0,02 $ à 0,14 $ par Gio. La surcharge opérationnelle liée à la gestion d’architectures multi-régions — risque d’erreurs, complexité des mouvements de données — dépasse généralement ces coûts de transfert.
La prévention est plus facile que la correction
Corriger une erreur de région est pénible :
- Exporter les données mal placées vers Cloud Storage
- Créer un nouveau dataset dans la bonne région
- Charger les données depuis Cloud Storage dans le nouveau dataset
- Mettre à jour toutes les références à la table
- Supprimer l’ancien dataset
La prévention est simple :
- Documentez clairement votre choix de région. Dans votre
CLAUDE.md, dans le README de votre projet dbt, dans vos documents d’onboarding. - Définissez
locationexplicitement dans votre dbt profiles.yml pour chaque target. Si vos datasets sont dansEU, définissezlocation: EU. - Validez en CI. Un script simple vérifiant
INFORMATION_SCHEMA.SCHEMATApeut signaler les datasets dans la mauvaise région avant qu’ils ne causent des problèmes. - Limitez les permissions de création de datasets. Si seule l’équipe data platform peut créer des datasets (via Terraform ou similaire), les décalages de région accidentels deviennent beaucoup plus difficiles.
L’erreur générée lors d’une tentative de jointure inter-régions ne distingue pas “vous n’avez pas accès” de “ce dataset est dans une région différente.” Au moment où la cause racine est identifiée, des dépendances sur le dataset mal placé peuvent déjà exister en aval.