Vos exécutions dbt font-elles discrètement grimper les coûts de calcul de l'entrepôt ?

dbt, désormais une seule entreprise avec Fivetran, exécute chaque modèle dans l’entrepôt. C’est la bonne architecture. Cela signifie aussi que l’inefficacité n’a pas d’état d’erreur : un modèle qui reconstruit un an d’historique chaque nuit réussit, et le coût apparaît ailleurs.

Pourquoi les coûts de calcul dérivent

• Les reconstructions complètes sont le comportement par défaut. Une matérialisation table supprime et recrée la table à chaque exécution. La rendre incrémentale est un travail supplémentaire par modèle, et ce travail est facile à repousser.
• La logique incrémentale est sur mesure. Les clés uniques, les fenêtres de rattrapage et les stratégies de merge sont décidées modèle par modèle, par celui qui l’a écrit, et elles divergent d’un développeur à l’autre.
• Le DAG s’exécute sur un périmètre plus large que le changement. Une seule entrée modifiée peut déclencher une exécution sur de nombreux modèles en aval, dont la plupart produisent le même résultat qu’hier.
• Personne ne profile ce qui fonctionne. Tant qu’une exécution se termine en vert, personne ne regarde plus loin. Le coût de calcul par modèle est visible dans la console de l’entrepôt, pas dans le pipeline.

Rien de tout cela n’est la faute de dbt. Une logique de transformation écrite à la main est aussi efficace que le temps dont son auteur disposait pour l’optimiser.

Où l’efficacité devrait se situer

• Le delta devrait être le seul mode de chargement. Si le pattern de chargement est généré, l’incrémental n’est pas un choix qu’un développeur fait sous pression. C’est la façon dont chaque chargement est écrit.
• L’historique devrait être isolé en un seul endroit. Les satellites conservent les changements au fil du temps, donc la couche des marts n’a jamais à recalculer l’historique pour répondre à une question sur le présent.
• Du SQL ensembliste pour le moteur que vous exploitez. Le code généré peut être optimisé par plateforme une seule fois, plutôt que modèle par modèle, par celui qui l’a écrit.

Ce qui change avec Datavault Builder

Datavault Builder génère des chargements delta ensemblistes pour les hubs, links et satellites, optimisés pour le moteur cible, donc la partie chère du pipeline ne touche jamais que ce qui a changé.

• Chaque chargement est un delta par construction. Les lignes nouvelles et modifiées sont détectées par rapport à ce qui est déjà historisé. Rien n’est supprimé et recréé.
• L’historique est conservé dans les satellites. Les questions sur l’état passé trouvent leur réponse dans les changements déjà stockés, et non en reconstruisant le passé à chaque exécution. Les chargements bi-temporels et les tables point-in-time sont des patterns que la plateforme propose nativement, pas quelque chose à construire à partir de macros.
• Le périmètre d’exécution suit le modèle. Les dépendances sont dérivées, donc un changement charge ce qu’il touche et rien au-delà.
• dbt State et Fusion aident toujours si dbt reste. Datavault Builder peut générer les modèles dbt pour les équipes qui y gardent l’exploitation, et celles-ci profitent du fait que les modèles inchangés sont sautés. Les couches générées en dessous n’ont jamais eu besoin d’être sautées, parce qu’elles ne faisaient jamais le travail complet.
• Les coûts de calcul deviennent prévisibles. Le coût de chargement suit l’ampleur des changements dans les sources, pas la taille totale de l’entrepôt, et c’est un chiffre que vous pouvez surveiller.

Ce qu’il faut décider

Prenez les dix modèles les plus chers dans l’historique des requêtes de l’entrepôt du dernier mois. Si la plupart sont des modèles de staging ou d’historique reconstruits en entier, c’est exactement la couche qui devrait être générée.