ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Compatibilité des packages avec dbt Fusion

Comment le moteur dbt Fusion (v2.0) affecte la compatibilité des packages — bornes de version, changements de format du manifest, le badge Fusion et comment préparer votre projet et vos packages à la migration.

Planté
dbtdata engineering

dbt Fusion est la réécriture en Rust du moteur dbt core, publiée en tant que dbt 2.0.0. Il offre un parsing et une compilation environ 30x plus rapides comparés au moteur Python de dbt Core. Pour la plupart de la logique SQL, Fusion est une mise à niveau transparente. Pour les packages, il introduit un mur de compatibilité — notamment un format de manifest modifié et des conflits de bornes de version.

Le paysage des versions

L’historique des versions de dbt comporte quelques points d’inflexion pertinents pour les packages :

VersionCe qui a changé
dbt Core 1.7Introduction de package-lock.yml
dbt Core 1.8unit_tests: natif ajouté ; tests: renommé en data_tests:
dbt Core 1.9–1.11Dernières versions stables 1.x ; configuration YAML des snapshots, améliorations de la fraîcheur des sources
dbt Fusion 2.0.0Réécriture en Rust ; 30x plus rapide ; format de manifest incompatible (v20 vs v12)

Pour les utilisateurs de packages, la version 1.8 est importante car elle a changé tests: en data_tests:. Les packages qui n’ont pas été mis à jour utilisent peut-être encore l’ancienne clé, ce qui génère des avertissements de dépréciation sur 1.8+ et finira par provoquer des erreurs. Vérifiez le YAML de vos packages installés si vous voyez des avertissements de dépréciation.

Fusion 2.0 est la rupture de compatibilité la plus importante. Ce n’est pas qu’un numéro de version — il utilise un format de manifest fondamentalement différent.

L’incompatibilité du manifest

dbt Core produit le manifest v12. dbt Fusion produit le manifest v20. Ces formats ne sont pas compatibles. Les outils qui consomment les manifests dbt — systèmes de CI, plateformes d’observabilité, intégrations d’IDE, certains orchestrateurs — peuvent dysfonctionner lors du passage à Fusion s’ils n’ont pas été mis à jour pour gérer la v20.

Plus pertinent pour les packages : le changement de format du manifest signifie que Fusion ne peut pas utiliser les artefacts produits par Core, et vice versa. Si vous testez une migration vers Fusion en parallèle d’un environnement de production Core, ils ne peuvent pas partager d’artefacts. Des environnements séparés sont nécessaires.

Le problème require-dbt-version

Le problème de compatibilité Fusion le plus courant concerne les packages avec des bornes de version qui excluent la 2.x :

# dbt_project.yml dans le package
require-dbt-version: [">=1.0.0", "<2.0.0"]

Cette plage exclut explicitement Fusion 2.0.0. Quand vous essayez d’exécuter Fusion sur un projet avec ce package, vous obtenez :

Error: Package requires dbt version >=1.0.0, <2.0.0 but got 2.0.0

La correction pour les mainteneurs de packages consiste à étendre la borne supérieure :

require-dbt-version: [">=1.3.0", "<3.0.0"]

En tant qu’utilisateur de package, vous ne pouvez pas corriger cela vous-même — vous êtes bloqué en attendant que le mainteneur du package mette à jour les bornes et publie une nouvelle version. C’est la principale raison de vérifier le badge de compatibilité Fusion avant de planifier une migration.

Le badge de compatibilité Fusion

Le dbt Hub affiche désormais un badge de compatibilité Fusion sur les packages vérifiés comme fonctionnant avec dbt 2.0+. Le badge apparaît quand un package :

  • A require-dbt-version défini pour inclure la plage 2.x
  • A été testé contre Fusion par le mainteneur ou dbt Labs

Les packages majeurs sont déjà compatibles Fusion : dbt-utils, tous les packages Fivetran, dbt-audit-helper, dbt-expectations, Elementary. Pour les packages communautaires, vérifiez le badge avant de supposer la compatibilité.

Le badge est un signal, pas une garantie. Un package peut avoir des bornes de version correctes mais contenir du SQL que Fusion parse différemment, ou utiliser des patterns Jinja que le moteur Rust gère de façon incohérente. Le badge vous indique que le mainteneur a effectué une validation ; vos propres tests d’intégration vous indiquent si cela fonctionne dans votre projet spécifique.

dbt-autofix

L’outil dbt-autofix aide à migrer automatiquement les configurations dépréciées. Avant de tester Fusion, exécutez-le pour détecter les problèmes les plus courants à résoudre facilement :

Terminal window
pip install dbt-autofix
dbt-autofix --target-version 2.0.0

Il gère des éléments comme :

  • Renommer tests: en data_tests: dans le YAML des modèles
  • Mettre à jour la syntaxe de macro dépréciée
  • Signaler les bornes require-dbt-version qui excluent la 2.x

autofix gère les changements mécaniques. Les problèmes plus profonds — incompatibilité du manifest v20 avec les outils en aval, packages avec des bornes de version non supportées — nécessitent une attention manuelle.

Checklist de migration vers Fusion

Si vous planifiez de migrer un projet avec des packages vers Fusion :

  1. Exécutez dbt-autofix pour détecter la syntaxe dépréciée dans votre projet
  2. Auditez chaque package dans votre packages.yml pour le badge Fusion
  3. Vérifiez require-dbt-version dans les packages installés (regardez dans dbt_packages/{package}/dbt_project.yml)
  4. Auditez les outils en aval — tout ce qui consomme des manifests dbt doit supporter la v20
  5. Exécutez votre suite de tests contre Fusion dans un environnement de staging avant de basculer la production
  6. Épinglez le lock file après la migration pour que les versions connues comme fonctionnelles soient enregistrées

Migrez la production et les packages séparément. Mettez d’abord à jour vers la dernière version de dbt Core 1.x (où les packages sont les plus compatibles), puis testez Fusion dans un environnement parallèle avec les mêmes versions de packages.

Pour les mainteneurs de packages

Si vous maintenez un package et souhaitez revendiquer la compatibilité Fusion :

  1. Mettez à jour require-dbt-version: [">=1.3.0", "<3.0.0"] dans votre dbt_project.yml
  2. Ajoutez Fusion à votre matrice CI — testez contre dbt 1.x et 2.0.0 à chaque release
  3. Mettez à jour les clés tests: en data_tests: dans votre YAML de modèles
  4. Soumettez au Hub pour obtenir le badge de compatibilité

La borne supérieure <3.0.0 couvre les deux runtimes. La matrice CI détecte les patterns Jinja ou SQL que Fusion gère différemment de Core.

Consultez les anti-patterns des packages dbt pour la discussion complète sur require-dbt-version et pourquoi des bornes manquantes ou trop restrictives causent des problèmes aux utilisateurs.