ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Garde-fous de gouvernance des coûts BigQuery

Limites au niveau des requêtes, quotas par projet, vues autorisées et patterns d'accès qui empêchent les erreurs BigQuery coûteuses avant qu'elles ne surviennent.

Planté
bigquerygcpcost optimizationdata engineering

Pour les organisations avec des utilisateurs analytiques ad-hoc, les contrôles de gouvernance peuvent générer plus d’économies que les optimisations techniques. Un seul analyste exécutant des requêtes SELECT * non filtrées peut générer des factures qui dépassent l’effort d’ingénierie consacré au partitionnement et au clustering. Les patterns ci-dessous opèrent aux niveaux requête, table et projet, et sont conçus pour intercepter différents modes d’échec.

Contrôles au Niveau des Requêtes

max_bytes_billed fixe une limite stricte par requête. Les requêtes qui dépasseraient cette limite échouent avant de scanner les données — vous ne payez pas le scan, vous recevez simplement un message d’erreur :

-- La requête échoue si elle scanne plus de 10 Go
SELECT * FROM large_table
OPTIONS (max_bytes_billed = 10737418240);  -- 10 Go en octets

C’est le contrôle de coût le plus important pour les utilisateurs ad-hoc. Configurez-le dans chaque outil et chaque connexion :

Dans dbt, configurez dans votre profil pour empêcher tout modèle individuel de scanner plus que la limite spécifiée :

profiles.yml
my_project:
  target: prod
  outputs:
    prod:
      type: bigquery
      method: oauth
      project: my-project
      dataset: production
      maximum_bytes_billed: 107374182400  # 100 Go

Cela intercepte les modèles incrémentaux mal configurés qui exécutent accidentellement des rafraîchissements complets. Un modèle incrémental qui devrait scanner 5 Go mais essaie subitement d’en scanner 500 (parce que quelqu’un a exécuté --full-refresh sur le mauvais modèle, ou que la logique incrémentale a un bug) échouera de façon sûre au lieu de générer une facture surprise.

Dans Looker/outils BI, configurez max_bytes_billed dans la configuration de connexion. Cela empêche les requêtes de dashboards de scanner plus que prévu, protégeant contre quelqu’un qui construirait une exploration non filtrée sur une table de plusieurs To.

Pour les analystes individuels, encouragez la configuration de cette limite dans les paramètres de leur console BigQuery ou leurs configurations client. Même une limite généreuse (1 To) prévient les scénarios catastrophiques.

Exigences de Filtres de Partition

L’option require_partition_filter sur les tables partitionnées oblige chaque requête à inclure un filtre sur la colonne de partition. Les requêtes sans en échouent avec une erreur au lieu de scanner toute la table :

ALTER TABLE `project.dataset.events`
SET OPTIONS (require_partition_filter = true);

C’est le deuxième contrôle de gouvernance le plus important. Appliquez-le à chaque table partitionnée accessible aux analystes ou aux outils BI. La note sur l’élagage de partitions couvre cela en détail, mais l’angle gouvernance est distinct : ce n’est pas une question d’optimisation, c’est une question de prévention des accidents.

Dans dbt, incluez cela dans la configuration de votre modèle :

{{ config(
    partition_by={"field": "event_date", "data_type": "date"},
    require_partition_filter=true
) }}

Quotas au Niveau du Projet

Depuis septembre 2025, les nouveaux projets BigQuery sont soumis par défaut à un quota quotidien de 200 Tio. Pour les projets existants, configurez des quotas personnalisés via l’Admin SDK ou Cloud Console.

Envisagez d’implémenter des quotas à plusieurs niveaux :

Limites quotidiennes par utilisateur : empêchez les analystes individuels de monopoliser le budget. Une limite quotidienne de 10 Tio par utilisateur est généreuse pour les travaux ad-hoc mais empêche les requêtes incontrôlées.

Limites par projet : plafonnez les dépenses sur les projets de développement vs production. Les projets de développement devraient avoir des limites bien inférieures à ceux de production parce qu’ils ne devraient pas scanner des tables de taille production (et si c’est le cas, c’est un problème de conception).

Seuils d’alerte : notifiez avant d’atteindre les limites strictes. Une alerte de budget à 80 % de votre cible mensuelle vous donne le temps d’investiguer avant l’arrivée de la facture.

La hiérarchie des contrôles de coûts, du plus au moins granulaire :

  1. max_bytes_billed par requête/connexion — intercepte les requêtes individuelles incontrôlées
  2. require_partition_filter par table — intercepte les scans non filtrés
  3. Quotas quotidiens par utilisateur — intercepte les dépassements individuels soutenus
  4. Quotas quotidiens par projet — intercepte les dépassements systémiques
  5. Alertes de budget — intercepte tout le reste, mais seulement après que l’argent est dépensé

Cumulez les cinq. Chacun intercepte des échecs que les autres manquent.

Vues Autorisées pour la Protection contre SELECT *

Plutôt que d’accorder aux analystes un accès direct aux tables (ce qui permet SELECT * sur des tables larges), créez des vues qui n’exposent que les colonnes dont ils ont besoin :

CREATE VIEW `project.views.user_summary` AS
SELECT user_id, signup_date, user_type
FROM `project.raw.users`;


-- Accorder l'accès à la vue, pas à la table
GRANT roles/bigquery.dataViewer
ON `project.views.user_summary`
TO 'user:analyst@company.com';

Ce pattern remplit un double rôle :

  1. Contrôle des coûts : les utilisateurs ne peuvent scanner que les colonnes de la vue, pas toute la table sous-jacente
  2. Gouvernance des données : les colonnes sensibles (e-mail, PII, données financières) sont exclues sans sécurité complexe au niveau des lignes/colonnes

Le compromis est la maintenance. Chaque nouvelle colonne dont un analyste a besoin nécessite une mise à jour de la vue. Mais pour les tables larges (50+ colonnes) où les analystes n’ont régulièrement besoin que de 5 à 10 colonnes, les économies de coûts issues de la prévention des scans intégraux sont substantielles.

Pour les organisations avec des besoins plus sophistiqués, les fonctionnalités de sécurité au niveau des colonnes et de masquage des données de BigQuery (disponibles dans les éditions Enterprise et Enterprise Plus) offrent un contrôle plus fin sans la charge de maintenance des vues autorisées.

Comptes de Service pour l’Attribution des Coûts

Créez des comptes de service séparés pour chaque intégration : dbt, Looker, Fivetran, Census, scripts personnalisés. Cela permet une attribution précise des coûts par système.

Quand chaque intégration utilise le même compte de service (ou pire, un compte personnel partagé), INFORMATION_SCHEMA.JOBS_BY_PROJECT montre un énorme bloc de coûts que vous ne pouvez pas décomposer. Avec des comptes de service séparés, vous pouvez répondre à des questions comme :

  • « Quel est le coût quotidien de notre pipeline dbt ? »
  • « Quel pourcentage du calcul est drivé par les dashboards Looker ? »
  • « Les coûts de synchronisation Fivetran ont-ils changé depuis l’ajout d’une nouvelle source ? »

La configuration prend 30 minutes et permet une attribution précise des coûts par système indéfiniment.

Affectations de Réservations pour l’Isolation de Capacité

Si vous êtes sur la tarification Editions, les affectations de réservations isolent les équipes les unes des autres. Sans isolation, un workload lourd d’une équipe consomme des slots dont une autre équipe a besoin, faisant attendre leurs requêtes.

Affectez différentes équipes ou workloads à des réservations séparées :

-- Réservation pipeline de production
CREATE RESERVATION `project.region-us.prod_pipeline`
OPTIONS (
  slot_capacity = 0,
  edition = 'ENTERPRISE',
  autoscale = (max_slots = 300)
);


-- Réservation analytics ad-hoc
CREATE RESERVATION `project.region-us.adhoc_analytics`
OPTIONS (
  slot_capacity = 0,
  edition = 'STANDARD',
  autoscale = (max_slots = 100)
);

Ce pattern garantit qu’une exécution dbt lourde n’affame pas les requêtes de dashboards, et qu’une analyse ad-hoc non contrôlée ne ralentit pas les pipelines de production. Chaque réservation scale indépendamment dans ses propres limites.

Priorité d’Implémentation

Commencez par max_bytes_billed et require_partition_filter — les contrôles à impact le plus élevé avec le moins de friction. Ajoutez les quotas par utilisateur et par projet, les vues autorisées et les affectations de réservations à mesure que les volumes de données et la taille de l’équipe augmentent.