Hiérarchie des réservations BigQuery

Le modèle de capacité BigQuery comporte trois couches : les engagements, les réservations et les affectations. Chaque couche répond à une question différente : quelle capacité est achetée, comment elle est organisée, et quels projets l’utilisent.

Engagements : acheter de la capacité

Un engagement est un achat de capacité de calcul pour une durée minimale. Vous dites en substance : “Je vais payer pour X slots pendant au moins Y temps.”

Les engagements sont optionnels avec BigQuery Editions. Sans engagement, vous payez le tarif pay-as-you-go standard pour votre édition. Les engagements offrent des remises significatives :

• Engagement 1 an : remise de 20 %
• Engagement 3 ans : remise de 40 %

Les engagements sont rentables pour les workloads stables et prévisibles où l’utilisation des slots est constante d’un mois à l’autre. Les workloads par pics ou imprévisibles sont mieux servis par le pay-as-you-go.

Contraintes principales :

• Les engagements sont régionaux — les slots dans us ne peuvent pas exécuter de jobs dans eu. Cela est directement lié à vos décisions d’architecture régionale.
• Les engagements ne peuvent pas être déplacés entre projets après leur création.
• Disponibles uniquement pour les éditions Enterprise et Enterprise Plus. L’édition Standard ne prend pas en charge les engagements.

Réservations : créer des pools de slots

Une réservation est un pool de slots réservé pour des workloads spécifiques. Pensez-y comme un “seau” qui contient une portion de votre capacité engagée.

Plusieurs réservations offrent de l’isolation. Exemple de configuration :

• Une réservation prod avec 500 slots pour les pipelines de production
• Une réservation bi avec 300 slots pour les requêtes de tableaux de bord
• Une réservation dev avec 100 slots pour le développement

Chaque réservation fonctionne indépendamment. Les jobs dans dev ne peuvent pas utiliser les slots de prod, garantissant que les pipelines de production disposent toujours de leur capacité allouée.

Chaque réservation possède sa propre configuration baseline et autoscaling. Vous pouvez garantir 500 slots baseline pour la production tout en laissant dev autoscaler de 0 à 200. La réservation est l’endroit où vous exprimez vos priorités en termes concrets.

Les réservations participent également au partage des slots inactifs (Enterprise et Enterprise Plus uniquement). Lorsque prod n’utilise pas tous ses slots, dev peut emprunter la capacité inactive. Lorsque prod en a besoin, elle les récupère instantanément.

Affectations : connecter les projets aux réservations

Une affectation lie un projet Google Cloud (ou un dossier, ou une organisation) à une réservation. Une fois affecté, tous les jobs BigQuery de ce projet utilisent les slots de cette réservation au lieu de la tarification on-demand.

La hiérarchie compte pour la résolution :

• L’affectation de projet prend le dessus sur l’affectation de dossier
• L’affectation de dossier prend le dessus sur l’affectation d’organisation
• Sans affectation, le projet utilise la tarification on-demand

Vous pouvez également affecter par type de job. BigQuery prend en charge plusieurs types d’affectations :

Vous pourriez donc affecter les jobs QUERY d’un projet à une réservation et ses jobs PIPELINE à une autre. En pratique, la plupart des équipes affectent tous les types de jobs à la même réservation, mais la granularité existe pour les workloads qui en ont besoin.

La couche d’affectation est ce qui permet au pattern multi-projets de fonctionner pour la gestion des slots. En affectant différents projets GCP à différentes réservations, vous obtenez une isolation des workloads sans aucun changement au niveau applicatif. Votre projet dbt de production utilise les slots de la réservation prod ; votre projet Looker utilise les slots de la réservation bi. Les projets ne connaissent pas et ne se soucient pas des réservations — l’affectation gère le routage.

Le projet d’administration

Bonne pratique : créez un projet d’administration dédié qui contient tous vos engagements et réservations. Ce projet n’exécute pas de requêtes ni ne stocke de données ; il gère simplement la capacité.

Nommez-le de manière explicite, par exemple bq-votreentreprise-admin. Cette approche :

• Centralise la facturation des ressources de calcul. Tous les coûts de slots apparaissent sur une seule facture.
• Simplifie la gestion de la capacité. Un seul endroit pour voir et ajuster toutes les réservations.
• Maintient vos projets de données propres. Aucune configuration de réservation mélangée avec les données et les requêtes.

Une règle critique : les slots inactifs ne peuvent être partagés qu’entre réservations dans le même projet d’administration. Si vous utilisez plusieurs projets d’administration, leurs slots restent complètement isolés. C’est l’erreur architecturale la plus courante avec les réservations — diviser la capacité entre des projets d’administration par inadvertance, puis se demander pourquoi le partage des slots inactifs ne fonctionne pas.

flowchart LR
      C[/"1000 slots (1 an)"/]

      C -->|"affecté à"| R1["Réservation : prod<br/>500 slots"]
      C -->|"affecté à"| R2["Réservation : analytics<br/>300 slots"]
      C -->|"affecté à"| R3["Réservation : dev<br/>200 slots"]

      R1 -->|"utilisé par"| P1([Projet : dbt-prod])
      R2 -->|"utilisé par"| P2([Projet : looker-prod])
      R3 -->|"utilisé par"| P3([Projet : analytics-dev])

Récapitulatif

Les trois couches s’articulent comme suit :

1. Les engagements déterminent la capacité totale et le coût.
2. Les réservations découpent cette capacité en pools isolés avec des configurations baseline et autoscaling spécifiques.
3. Les affectations orientent les projets vers la réservation appropriée.

Les responsabilités sont clairement séparées : les projets peuvent être réaffectés sans modifier les réservations ; les réservations peuvent être redimensionnées sans changer les affectations ; les engagements peuvent être ajoutés indépendamment.

Pour les équipes exécutant dbt sur BigQuery, cette hiérarchie est ce qui permet le pattern “projets séparés par workload” décrit dans dbt Slot Management on BigQuery. Vos exécutions dbt de production bénéficient d’une capacité garantie via une réservation dédiée, tandis que le travail de développement utilise un pool plus petit ou reste entièrement sur la tarification on-demand.