Hiérarchie des ressources BigQuery

La hiérarchie des ressources BigQuery suit la structure Google Cloud avec des ajouts spécifiques à BigQuery. Chaque niveau contrôle des préoccupations distinctes : facturation, quotas, accès et emplacement des données.

Organisation
    └── Dossiers
        └── Projets
            └── Datasets
                └── Tables / Vues / Vues matérialisées / Modèles

Chaque niveau sert un objectif distinct, et les frontières entre eux ont de réelles conséquences sur les coûts, les performances et la sécurité.

Les projets comme frontière principale

Les projets constituent l’unité organisationnelle fondamentale dans Google Cloud. Chaque projet possède son propre compte de facturation, ses propres quotas et son propre ensemble d’API activées. Pour BigQuery spécifiquement, les projets déterminent où les coûts de requêtes sont facturés.

Les coûts sont facturés au projet qui exécute la requête, non à celui qui stocke les données. Si les données se trouvent dans project-warehouse mais que les requêtes s’exécutent depuis project-analytics, les coûts de calcul apparaissent sur la facture de project-analytics. Les coûts de stockage restent avec le projet contenant les données.

Cette séparation permet des patterns puissants. Une équipe data centrale peut gérer l’ingestion et le stockage des données brutes dans un projet. Les équipes départementales peuvent interroger ces données depuis leurs propres projets, les coûts étant imputés à leurs budgets. Les agences peuvent interroger les datasets clients en facturant le calcul sur leurs propres comptes. Consultez BigQuery Multi-Environment Patterns pour voir comment cela se concrétise en pratique.

Les projets délimitent également les quotas. La tarification on-demand donne à chaque projet jusqu’à 2 000 slots concurrents, avec 20 000 slots partagés entre une organisation. Partager un projet entre les environnements dev et prod signifie qu’une requête de développement hors de contrôle peut affecter les performances des tableaux de bord de production.

Les datasets comme frontières de contrôle d’accès

Les datasets sont les conteneurs logiques de BigQuery pour les tables et les vues. Ils sont extérieurs à la hiérarchie standard des ressources GCP (vous ne les trouverez pas dans Cloud Resource Manager) mais constituent l’unité principale de contrôle d’accès et d’organisation des données dans BigQuery.

Chaque table hérite des permissions de son dataset parent. Accordez bigquery.dataViewer sur un dataset, et ce principal peut lire toutes les tables actuelles et futures qu’il contient. Cet héritage fait des datasets la frontière naturelle pour le contrôle d’accès : regroupez les tables par qui devrait y accéder, pas seulement par ce qu’elles contiennent. La note BigQuery IAM Patterns couvre les rôles spécifiques et les stratégies d’attribution.

Plusieurs propriétés des datasets méritent une attention particulière car elles sont difficiles ou impossibles à modifier ultérieurement :

L’emplacement est défini à la création et ne peut pas être modifié par la suite. C’est la décision la plus conséquente et la moins réversible que vous prendrez concernant un dataset. Un dataset créé dans US restera dans US pour toujours. Le déplacer nécessite d’exporter vers Cloud Storage, de créer un nouveau dataset dans la bonne région, de recharger toutes les données et de mettre à jour chaque référence en aval. Consultez BigQuery Regional Architecture pour réfléchir aux choix d’emplacement.

L’expiration par défaut des tables supprime automatiquement les tables après une période spécifiée. C’est véritablement utile pour les datasets de développement où des expériences abandonnées s’accumuleraient autrement indéfiniment. Définissez une expiration de 7 jours sur les datasets dev et vous n’aurez plus jamais à nettoyer manuellement test_orders_v3_final_FINAL.

Les labels permettent le suivi des coûts et l’organisation des ressources. Appliquez les labels de manière cohérente sur tous les datasets pour permettre une analyse de coûts pertinente par équipe, projet ou environnement. Les labels se propagent vers les exports de facturation et les requêtes INFORMATION_SCHEMA, les rendant essentiels pour répondre à “combien dépense l’équipe X ?”

Le modèle de facturation du stockage vous permet de choisir entre les octets logiques (ce que représentent vos données) et les octets physiques (ce qui est réellement stocké après compression). La facturation physique réduit souvent les coûts de 60 à 80 % pour les données très compressibles, mais nécessite une activation par dataset. Interrogez INFORMATION_SCHEMA.TABLE_STORAGE pour vérifier vos taux de compression avant de changer. Le BigQuery Cost Model couvre ce compromis en détail.

Tables, vues et vues matérialisées

Les tables standard stockent des données. Les vues stockent des requêtes qui s’exécutent à la lecture. Les vues matérialisées stockent des résultats de requêtes précalculés que BigQuery maintient automatiquement.

La distinction entre vues standard et vues matérialisées compte plus qu’il n’y paraît. Une vue standard exécute sa requête de définition à chaque fois qu’elle est lue. Si cette vue agrège un milliard de lignes, chaque actualisation de tableau de bord paie cette agrégation. Une vue matérialisée précalcule les résultats et se rafraîchit de manière incrémentale, réduisant souvent à la fois la latence et les coûts par ordres de grandeur.

La fonctionnalité smart tuning de BigQuery redirige automatiquement les requêtes sur les tables de base vers les vues matérialisées lorsque c’est bénéfique. Si vous créez une vue matérialisée qui agrège les ventes quotidiennes, les requêtes demandant des agrégations compatibles utiliseront la vue matérialisée même si elles référencent directement la table de base. Aucune configuration requise.

Conventions de nommage qui passent à l’échelle

Les conventions de nommage deviennent importantes lors de la gestion de nombreux modèles sur de nombreux datasets.

Utilisez le snake_case universellement. BigQuery est sensible à la casse, et mélanger les conventions crée confusion et bugs. Utilisez des préfixes sémantiques qui communiquent le rôle d’une table dans le pipeline de transformation (ceux-ci s’alignent avec les couches base, intermédiaire et mart dans dbt) :

La convention double-underscore (base__shopify__orders) clarifie l’identification du système source et passe élégamment à l’échelle. Lorsque vous avez 30 systèmes sources, savoir d’un coup d’œil que base__shopify__orders et base__netsuite__orders proviennent de sources différentes fait gagner un temps réel.

Anti-pattern : la prolifération des datasets

La prolifération des datasets s’installe progressivement : test_data pour une expérience, backup_orders_v2 pour un usage ponctuel, etc. Le résultat est de nombreux datasets sans indication claire de quelles tables font autorité.

Les symptômes incluent :

• Des datasets nommés test, temp, backup, old, new, v2, final, final_v2
• Le même nom de table apparaissant dans plusieurs datasets
• Aucune documentation sur les datasets actifs
• Des autorisations IAM dispersées sur des dizaines de datasets sans pattern clair

Commencez par un audit : interrogez INFORMATION_SCHEMA.SCHEMATA pour lister tous les datasets, vérifiez les logs d’accès pour voir lesquels sont utilisés, et archivez les datasets inutilisés dans un projet séparé. Établissez des conventions de nommage et faites-les respecter via la revue de code.

Pour les équipes utilisant dbt, le nommage des datasets doit refléter votre configuration de schéma dbt : base, intermediate, marts en production, et dbt_<username>_base, dbt_<username>_intermediate en développement. La macro generate_schema_name contrôle ce mapping.