Hub de développement de packages dbt

Ce hub relie les notes sur la construction, le test et la distribution de packages dbt. Un package est un projet dbt structuré pour la réutilisation, utilisant var(), le dispatch et le namespacing pour le rendre installable par n’importe qui.

Les briques de construction

Comprendre la structure

• Anatomie d’un package dbt — Ce qui distingue un package d’un projet, la structure de répertoires standard et la configuration dbt_project.yml pour les packages.

Rendre les modèles réutilisables

• Patterns de modèles packageables dbt — Les trois techniques qui rendent les modèles installables par n’importe qui : sources configurables avec var(), flags d’activation/désactivation et noms de modèles avec namespace.
• Macros dbt — Pattern dispatch pour la compatibilité cross-database, fondamentaux Jinja et bonnes pratiques des macros. Indispensable pour les packages supportant plusieurs warehouses.

Tests

• Tests d’intégration de packages dbt — Le pattern du sous-projet integration_tests/ utilisé par Fivetran et dbt Labs pour vérifier que les packages produisent des résultats corrects.
• CI/CD pour les packages dbt — Tests matriciels sur warehouses et versions dbt avec GitHub Actions.

Distribution

• dbt Hub Publishing — Le processus d’enregistrement, l’automatisation hubcap, la résolution des dépendances transitives et les bonnes pratiques pour les packages Hub.
• Packages dbt privés via Git — Distribution Git pour les packages internes, épinglage de versions et options d’authentification.

Qualité

• Anti-patterns des packages dbt — Six erreurs courantes : schémas codés en dur, dispatch manquant, contraintes trop strictes, noms génériques, matérialisations en table par défaut et version bounds absentes.

Points de décision

Quand packager : Le même ensemble de macros ou de modèles a été copié dans trois projets, ou la duplication SQL entre dépôts crée des problèmes de maintenance.

Package vs Mesh : Si vous partagez de la logique réutilisable (macros, tests, templates de modèles), construisez un package. Si vous partagez des produits de données curatés avec des contrats définis, utilisez Mesh. Voir dbt Packages vs Mesh pour le cadre complet.

Hub vs Git : Commencez avec un package Git pour un usage interne. Passez au Hub une fois que le package est suffisamment stable pour la communauté plus large. Le Hub ajoute la résolution des dépendances transitives et le support des plages de versions.

Du projet au package

La plupart des packages commencent sous forme de code déjà éprouvé :

1. Extraire — Identifier les macros, modèles ou tests réutilisables dans votre projet existant
2. Configurer — Remplacer les références codées en dur par des appels var() (patterns)
3. Nommer — Préfixer les noms de modèles avec le nom du package
4. Porter — Ajouter des implémentations dispatch pour les warehouses cibles
5. Tester — Construire une suite de tests d’intégration
6. Automatiser — Configurer un CI/CD sur warehouses et versions
7. Distribuer — Partager via Git ou le Hub

Ressources associées

• dbt Three-Layer Architecture — Le pattern base/intermédiaire/mart que les packages suivent en interne
• dbt Project Structure and Naming — Conventions de nommage et structure de répertoires (les packages suivent les mêmes principes)
• Taxonomie des tests dbt — Tests génériques, tests unitaires et contrats qui complètent les tests d’intégration