Le schéma en étoile et la table large unique (OBT — One Big Table) ne s’excluent pas mutuellement dans un projet dbt — les deux patterns sont utilisés à différentes couches de l’architecture en trois niveaux.
Schéma en étoile
Un schéma en étoile sépare vos données en tables de faits (événements, transactions) et tables de dimensions (entités, attributs). Une table de faits d’opportunités référence les tables de dimensions pour le compte, le propriétaire, l’étape, et le produit via des clés étrangères. Les requêtes joignent les faits aux dimensions selon les besoins.
Points forts :
- La séparation claire des entités rend les modèles testables et maintenables indépendamment
- Des tables individuelles plus petites sont plus rapides à construire lors des exécutions dbt
- Les mises à jour des dimensions ne nécessitent pas de reconstruire la table de faits
- Efficace en stockage — pas de duplication des attributs de dimension sur chaque ligne de fait
- S’aligne naturellement avec les modèles intermédiaires organisés par entité
Points faibles :
- Nécessite des jointures au moment de la requête, ce qui ajoute de la latence pour les outils BI
- SQL plus complexe pour les utilisateurs finaux et les dashboards
- La performance des jointures dépend de la façon dont le warehouse les gère
Table large unique (OBT)
Le pattern OBT pré-joint tout dans une seule table large et dénormalisée. Une ligne par enregistrement de fait, avec tous les attributs de dimension déjà inclus. Pas de jointures nécessaires au moment de la requête.
Points forts :
- Performance des requêtes plus rapide — pas de jointures, scan d’une seule table
- SQL plus simple pour les outils BI et les dashboards
- Meilleure compatibilité avec les outils BI — certains outils ont du mal avec les jointures multi-tables
- Le stockage en colonnes signifie que la largeur ne pénalise pas les requêtes qui sélectionnent peu de colonnes
Points faibles :
- Empreinte de stockage plus importante due à la duplication des attributs
- Temps de construction plus longs lors des exécutions dbt (doit reconstruire quand une dimension change)
- Plus difficile à maintenir — les changements dans une dimension affectent l’ensemble de la reconstruction OBT
- Peut devenir ingérable avec des centaines de colonnes
BigQuery favorise spécifiquement l’OBT
L’architecture de BigQuery donne à l’OBT un avantage mesurable. La combinaison du stockage en colonnes, de l’exécution massivement parallèle, et de l’optimisation automatique des requêtes signifie que les tables larges performent bien.
Les benchmarks de Fivetran montrent que l’OBT surpasse le schéma en étoile de 25 à 50 % sur les cloud warehouses, BigQuery affichant le plus grand écart avec des temps de requête 49 % plus rapides pour l’OBT par rapport aux requêtes en schéma en étoile équivalentes. Le moteur d’exécution parallèle de BigQuery gère particulièrement bien les tables larges car il ne lit que les colonnes référencées dans votre requête — un OBT de 200 colonnes interrogé pour 5 colonnes ne scanne que ces 5 colonnes.
Cela ne signifie pas que le schéma en étoile est mauvais sur BigQuery. Cela signifie que la surcharge des jointures que le schéma en étoile impose est plus notable sur BigQuery que sur les warehouses optimisés pour les jointures pré-calculées.
Utiliser les deux patterns
Un projet dbt bien structuré utilise les deux patterns à différentes couches :
Couche intermédiaire : séparation des entités. Construisez vos modèles intermédiaires avec des limites d’entité claires. int__opportunity_enriched, int__account_enriched, int__contact_enriched. Chaque modèle d’entité est testable, déboguable, et réutilisable indépendamment. C’est votre schéma en étoile — propre, normalisé, servant de source de vérité unique pour chaque entité.
Couche mart : tables larges dénormalisées. Construisez vos modèles mart comme des tables larges pré-jointées pour des cas d’usage BI spécifiques. Ce sont vos OBTs — tout ce dont un dashboard a besoin dans une seule table, pas de jointures nécessaires. Chaque mart sert un consommateur spécifique à un grain spécifique.
C’est exactement ce que font les packages Fivetran. Le modèle salesforce__opportunity_enhanced pré-joint les données d’opportunité avec les informations de compte, propriétaire, et étape dans une seule table large prête pour la consommation BI. En dessous, les modèles source et staging maintiennent une séparation d’entité propre.
[modèles de base : 1-pour-1 avec les tables sources] ↓[intermédiaire : entités séparées, normalisé] ↓[marts : large, dénormalisé, spécifique au consommateur]La couche intermédiaire fournit la maintenabilité et la réutilisation. La couche mart fournit les performances des requêtes et un SQL plus simple pour les consommateurs.
Quand utiliser un schéma en étoile pur
Il y a des cas légitimes pour exposer un schéma en étoile directement aux consommateurs :
- Les outils de couche sémantique (Cube, MetricFlow, Looker LookML) qui gèrent les jointures de manière optimale et préfèrent les entrées normalisées. Ces outils construisent leurs propres OBTs virtuels depuis votre schéma en étoile, donc pré-joindre dans dbt est redondant.
- Les environnements d’exploration intensive où les analystes écrivent leur propre SQL et ont besoin de flexibilité pour joindre les entités de façons que vous n’avez pas anticipées. Un schéma en étoile avec des dimensions propres est plus composable qu’un OBT rigide.
- Les tables de faits très larges où pré-joindre chaque dimension créerait des tables avec 500+ colonnes. À un moment donné, l’OBT devient ingérable même pour le stockage en colonnes.
Quand utiliser l’OBT pur
L’OBT pur brille quand :
- La performance du dashboard est la priorité et votre outil BI ne gère pas bien les jointures (beaucoup d’outils BI en libre-service tombent dans cette catégorie)
- Le consommateur est non technique et ne peut pas écrire ou déboguer des jointures
- Les destinations reverse ETL s’attendent à des entrées plates et dénormalisées
- Le nombre d’entités est petit — si vous joignez 3 à 4 dimensions, l’OBT est gérable et le gain de performance est significatif
Nombre de colonnes et limites pratiques
Les tables larges sur BigQuery peuvent techniquement avoir jusqu’à 10 000 colonnes. En pratique, les OBTs au-delà de 200 à 300 colonnes commencent à avoir des problèmes ergonomiques — ils sont difficiles à naviguer dans les éditeurs de requêtes, les noms de colonnes deviennent ambigus, et la documentation devient essentielle plutôt qu’optionnelle.
Si votre OBT approche 300+ colonnes, envisagez de le diviser en OBTs spécifiques à des domaines : mrt__sales__opportunity_wide, mrt__support__case_wide. Chacun sert un groupe de consommateurs spécifique avec seulement les colonnes dont il a besoin. Cela préserve l’avantage de performance de l’OBT sans les inconvénients ergonomiques d’une table monolithique.
Considérations de stockage
L’OBT augmente effectivement le stockage en raison de la duplication des attributs de dimension. Un OBT d’opportunités qui inclut le nom du compte, le secteur, et le nom du propriétaire sur chaque ligne duplique ces chaînes sur chaque opportunité. Sur BigQuery, le stockage en colonnes avec compression automatique atténue cela significativement — les valeurs de chaînes répétées se compressent extrêmement bien.
Pour la plupart des équipes, l’augmentation du coût de stockage due à l’OBT est négligeable par rapport aux économies de coûts de calcul grâce à l’élimination des jointures à l’exécution. Faites le calcul pour votre cas spécifique, mais le stockage est rarement la contrainte.