Un schéma en étoile sépare un (ou des) fait des dimensions partagées : dates, clients, produits. Une One Big Table (OBT) dénormalise tout sur une ligne large — attributs du client à côté de la transaction — pour qu’un consommateur n’ait plus à joindre. Sur Snowflake comme sur Databricks, les deux sont valides. Le moteur colonnaire ne « tue » pas l’étoile : il change le prix relatif des jointures et des scans.
L’étoile optimise le partage et le changement lent. Une correction d’adresse client, un libellé produit, une SCD type 2 : vous réécrivez une dimension, pas dix copies dans le fait. Les outils BI (Looker, Power BI, Tableau) savent parler faits / dims. Le fait reste mince, donc un SUM(montant) avec filtre date prune les micro-partitions ou les fichiers Delta sans trimballer le commentaire marketing.
L’OBT optimise un chemin de lecture unique. Feature store pour un modèle, export vers un outil qui n’aime pas les jointures, équipe de deux personnes sans sémantique partagée. Moins de joins, moins de surprises de grain, un seul SELECT pour le data scientist. Le coût : une colonne « segment client » qui change oblige à réécrire (ou versionner) des milliards de lignes ; le stockage explose ; deux OBT divergent et personne ne sait laquelle est vraie.
Snowflake et Photon/Spark SQL lisent par colonnes. Une OBT de 200 colonnes dont vous n’en sélectionnez que 8 n’est pas aussi stupide qu’en ligne à ligne — le column pruning existe. L’argument « OBT obligatoire sinon les joins tuent Snowflake » est souvent faux : des dimensions petites broadcastées ou des faits bien clusterisés par date tiennent très bien. À l’inverse, une étoile avec une dimension monstre mal filtrée et un join explosif reste un problème de modèle, pas de vendor.
Sur Databricks, l’OBT apparaît souvent en gold ML (une ligne = un exemple) alors que le gold BI reste en étoile. Ce n’est pas une trahison : ce sont deux contrats. Les médailles servent précisément à ça.
Que vous partez des consommateurs. Combien de dashboards partagent les mêmes dims ? Y a-t-il des SCD ? Quel grain ? Si la réponse est « un modèle par semaine, pas de BI », l’OBT gold est raisonnable. Si la réponse est « vingt équipes, même client », l’étoile (ou un snowflake léger) évite le chaos. La mauvaise réponse : « on est moderne, donc OBT partout » ou « Kimball a toujours raison ».
La relance : « Et le coût d’un join contre le coût d’un MERGE sur 4 To ? » C’est souvent là que l’OBT perd : maintenir la table large à chaque mise à jour de dimension coûte plus cher que joindre une dim de 10 millions de lignes. Vous le montrez au query profile, pas au slide d’architecture.