Patterns multi-environnements BigQuery

La séparation des environnements BigQuery nécessite généralement au minimum deux environnements (développement et production) et souvent trois (développement, staging, production). Google Cloud recommande des projets GCP séparés pour l’isolation la plus forte : facturation, quotas, périmètres de sécurité et réservations de slots indépendants. Des approches plus simples conviennent aux équipes plus petites.

Pattern A : Projets séparés par environnement

Organisation
└── Dossier Data Platform
    ├── analytics-dev
    ├── analytics-staging
    └── analytics-prod

Chaque environnement obtient son propre projet. Le développement se passe dans analytics-dev. Le staging valide les modifications dans analytics-staging. La production sert les tableaux de bord et rapports depuis analytics-prod.

Cette séparation apporte :

• Facturation indépendante pour voir exactement ce que coûte le développement par rapport à la production.
• Quotas isolés pour qu’une requête dev incontrôlée ne puisse pas impacter la production. Chaque projet a sa propre allocation de slots.
• Périmètres de sécurité clairs. Les comptes de service de production ne touchent jamais les données dev, et vice versa.
• Réservations de slots séparées. Si vous utilisez la tarification par capacité, vous pouvez réserver des slots dédiés pour la production tandis que le dev utilise la tarification à la demande.

L’inconvénient est la complexité : plus de comptes de service, plus de politiques IAM, plus de cibles dans profiles.yml. Pour les équipes de plus de trois ou quatre personnes, c’est généralement le bon choix ; les équipes plus petites peuvent utiliser des patterns plus simples.

Dans le profiles.yml de dbt, cela signifie des cibles séparées pointant vers différents projets :

my_analytics:
  target: dev
  outputs:
    dev:
      type: bigquery
      project: analytics-dev
      dataset: "dbt_{{ env_var('USER', 'developer') }}"
      location: US
    prod:
      type: bigquery
      project: analytics-prod
      dataset: analytics
      location: US

Pattern B : Datasets séparés dans un seul projet

analytics-data
├── dev_base
├── dev_marts
├── prod_base
└── prod_marts

Un seul projet contient tous les environnements, séparés par le nommage des datasets. Les modèles de développement écrivent dans les datasets dev_* ; la production écrit dans les datasets prod_*.

C’est plus simple à gérer. Un seul compte de facturation, un seul ensemble de quotas, moins de comptes de service. Les permissions au niveau des datasets isolent tout de même les accès : vous pouvez accorder aux développeurs un accès en écriture sur les datasets dev_* tout en restreignant les datasets de production aux comptes de service automatisés.

Inconvénients : quotas partagés (une utilisation dev intensive affecte les performances de prod) et moins de séparation claire de la facturation. Approprié pour les petites équipes (1 à 3 personnes), les projets en phase précoce, ou les situations où l’isolation des environnements n’est pas critique.

Pattern C : Data lake central avec marts de données départementaux

data-lake-storage (équipe centrale)
    └── datasets bruts, datasets de base
         ↓ (accès Data Viewer)
├── marketing-analytics (équipe Marketing)
├── finance-analytics (équipe Finance)
└── product-analytics (équipe Produit)

Une équipe data engineering centrale gère l’ingestion, le nettoyage et la modélisation de base dans un projet de stockage dédié. Les équipes départementales exécutent leurs propres transformations et requêtes dans des projets séparés, en construisant des marts spécifiques à leur domaine.

Les coûts de stockage vont au projet central. Les coûts de compute vont aux comptes de facturation des départements. Cela sépare clairement les coûts de plateforme (“combien coûte notre infrastructure data ?”) des coûts de consommation (“combien l’équipe marketing dépense-t-elle en analytics ?”).

L’équipe centrale accorde bigquery.dataViewer sur les datasets curés aux projets départementaux. Chaque département gère ses propres projets dbt, ses propres modèles, ses propres tableaux de bord, en puisant dans le data lake central.

Ce pattern nécessite plus de coordination organisationnelle et passe à l’échelle des grandes entreprises avec des exigences de refacturation interne. La séparation de la facturation au niveau des projets rend l’attribution des coûts simple.

Requêtes inter-projets

Les requêtes entre projets ne nécessitent aucune configuration spéciale. Utilisez simplement des noms de tables complets :

SELECT
  c.customer_id,
  c.customer_name,
  o.order_id,
  o.order_date
FROM `other-project.shared_dataset.mrt__sales__customers` c
JOIN `my-project.local_dataset.mrt__sales__orders` o
  ON c.customer_id = o.customer_id

Les requêtes inter-projets dans la même région n’entraînent aucun coût de transfert réseau. Les données ne bougent pas entre les projets ; BigQuery achemine la requête vers l’endroit où vivent les données. C’est une conséquence directe de la séparation du stockage et du compute — Dremel peut lire depuis Colossus quel que soit le projet qui “possède” les données.

Permissions requises :

• bigquery.dataViewer sur le dataset source (pour lire les données)
• bigquery.jobUser sur le projet exécutant la requête (pour exécuter des requêtes)

Le projet qui interroge paie le compute. Voir Patterns IAM BigQuery pour la répartition complète des rôles.

Quel pattern choisir

La décision dépend de la taille de l’équipe et des besoins organisationnels :

La plupart des équipes commencent avec le Pattern B et passent au Pattern A quand la taille de l’équipe ou les exigences d’isolation le justifient. Le Pattern C n’apporte de la valeur qu’avec de vraies exigences de refacturation multi-équipes.

Quel que soit le pattern, tous les environnements doivent utiliser la même région. Les jointures inter-régions sont impossibles ; dev en US avec prod en EU rend les tests de migration invalides.