Groupes et modificateurs d'accès dans dbt

Les groupes et les modificateurs d’accès ont été introduits dans dbt Core v1.5 en même temps que les contrats de modèles. Ils répondent à deux questions de gouvernance : qui possède un ensemble de modèles, et qui est autorisé à en dépendre. Leur utilité est la plus évidente dans dbt Mesh (configurations multi-projets), mais ils apportent également de la valeur dans les projets à projet unique.

Ce que sont les groupes

Un groupe est une collection nommée de modèles avec un propriétaire déclaré. Les groupes vivent dans dbt_project.yml :

groups:
  - name: marketing
    owner:
      email: marketing-data@company.com
  - name: finance
    owner:
      email: finance-data@company.com

Vous assignez des modèles aux groupes au niveau du dossier :

models:
  my_project:
    marts:
      marketing:
        +group: marketing
      finance:
        +group: finance

C’est tout ce qu’est un groupe : un moyen d’enregistrer qu’un ensemble de modèles appartient à une équipe et qu’une personne spécifique en est responsable.

Ce que sont les modificateurs d’accès

Les modificateurs d’accès contrôlent quels modèles en dehors d’un groupe peuvent référencer un modèle :

• private : Seuls les modèles appartenant au même groupe peuvent référencer ce modèle. Tout le reste produit une erreur de compilation.
• protected (par défaut) : N’importe quel modèle du même projet peut référencer ce modèle. Les modèles d’autres projets ne le peuvent pas.
• public : N’importe quel modèle — dans ce projet ou dans n’importe quel autre — peut référencer ce modèle.

models:
  my_project:
    marts:
      marketing:
        +group: marketing
        +access: public
    intermediate:
      +access: protected  # Par défaut, mais explicite
    base:
      +access: private

En pratique : les marts publics constituent l’interface que votre organisation voit. Les intermédiaires protégés sont des détails d’implémentation internes que d’autres équipes au sein du projet peuvent utiliser si nécessaire. Les modèles de base privés appartiennent entièrement à la couche responsable du nettoyage de cette source.

Valeur dans les projets à projet unique

Trois raisons d’utiliser les groupes et les modificateurs d’accès dans les projets à projet unique :

Documentation

Les groupes enregistrent la propriété de manière lisible par les machines. La réponse à « qui possède les modèles du mart finance ? » se trouve dans dbt_project.yml, pas dans un wiki. À mesure que les équipes grandissent, la personne qui a construit un modèle il y a des mois peut être partie — les groupes font de la propriété un artefact du projet plutôt qu’une connaissance détenue dans la tête de quelqu’un.

Préparation future pour Mesh

Si votre projet grandit au point où une division par domaine devient pertinente, la structure des groupes est déjà en place. Vous avez déjà identifié les frontières, déclaré les propriétaires et marqué quels modèles sont des contrats publics et lesquels sont des implémentations internes. La migration vers Mesh devient chirurgicale plutôt qu’architecturale.

L’inverse est douloureux : essayer d’introduire Mesh dans un projet construit sans aucun concept de propriété signifie décider rétrospectivement ce qui est public et ce qui ne l’est pas, potentiellement en cassant beaucoup de dépendances implicites.

Frontières architecturales appliquées

Sans modificateurs d’accès, rien n’empêche un ingénieur motivé de référencer base__ga4__event directement dans un mart. Le mart contourne votre couche intermédiaire, duplique la logique et crée une dépendance cachée qui se casse quand le modèle de base change.

Avec +access: private sur votre couche de base, dbt refusera de compiler un mart qui essaie de référencer un modèle de base. L’architecture devient auto-appliquée. Vous n’avez pas besoin de revues de code pour détecter ces violations ; la construction échoue.

C’est la même valeur que les règles de lint ou les tests architecturaux — cela convertit une convention sociale en contrainte technique.

Les modificateurs d’accès en pratique

La configuration typique pour un projet dbt en trois couches :

groups:
  - name: marketing
    owner:
      email: marketing-data@company.com
  - name: finance
    owner:
      email: finance-data@company.com
  - name: data-platform
    owner:
      email: data-platform@company.com

models:
  my_project:
    base:
      +group: data-platform
      +access: private        # Équipe plateforme uniquement, uniquement via intermédiaire
    intermediate:
      +group: data-platform
      +access: protected      # À l'échelle du projet, mais pas inter-projets
    marts:
      +materialized: table
      marketing:
        +group: marketing
        +access: public       # Contrats stables pour les tableaux de bord et les consommateurs
      finance:
        +group: finance
        +access: public

Les modèles de mart marqués public sont le contrat avec les consommateurs en aval. Combinés avec les contrats de modèles, un mart public avec contract: {enforced: true} garantit à la fois que le modèle est accessible et que son schéma est stable.

La connexion avec Mesh

Dans une configuration dbt Mesh, access: public est ce qui rend les références inter-projets possibles. Un autre projet dbt ne peut référencer que des modèles explicitement marqués publics. Combiné avec les versions de modèles, cela crée une API appropriée : le modèle est public, il est versionné, il a un contrat de schéma et un propriétaire déclaré.

Pour les projets uniques, public a toujours du sens — il signale une intention. Un modèle public est celui pour lequel vous vous engagez à la stabilité du schéma. D’autres équipes l’interrogent dans les outils BI. Des pipelines en dépendent. Le changer nécessite une considération de compatibilité ascendante ou une migration versionnée.

Cela vaut la peine d’être explicite même quand il n’y a pas d’application technique. La discipline de décider « ce modèle est-il un contrat public ou une implémentation interne ? » améliore la conception de votre projet, car elle vous force à penser aux frontières.

Point de départ

1. Ajoutez des groupes pour chaque équipe qui possède des modèles (même s’il n’y a qu’une équipe)
2. Marquez les modèles de mart +access: public
3. Laissez tout le reste à la valeur par défaut protected

N’ajoutez pas immédiatement private aux modèles de base — cela peut casser les modèles existants si des dépendances inter-couches existent et n’avaient pas encore été détectées. Ajoutez private de façon incrémentale après avoir confirmé qu’il n’existe pas de références hors couche.