La plupart des fonctionnalités dbt se mappent à des équivalents Dataform : {{ ref() }} devient ${ref()}, les macros Jinja deviennent des includes JavaScript, les tests de schéma YAML deviennent des assertions inline. Certaines capacités dbt n’ont aucun équivalent dans Dataform — pas une version dégradée, pas un contournement manuel, mais rien. Ces lacunes sont les principaux blocages dans les migrations de dbt vers Dataform.
Snapshots (SCD Type 2)
La commande snapshot de dbt implémente automatiquement les dimensions à évolution lente de Type 2. Vous définissez les colonnes à suivre, choisissez une stratégie par timestamp ou par vérification, et dbt s’occupe du reste — en écrivant les colonnes dbt_valid_from, dbt_valid_to et dbt_scd_id, en fusionnant les nouveaux enregistrements dans la table snapshot existante, et en maintenant l’historique complet.
-- Définition d'un snapshot dbt{% snapshot customer_snapshot %}{{ config( target_schema='snapshots', unique_key='customer_id', strategy='timestamp', updated_at='updated_at') }}SELECT * FROM {{ source('app_db', 'customers') }}{% endsnapshot %}Dataform n’a pas d’équivalent. Zéro. Si vous avez besoin de suivre comment les enregistrements changent dans le temps, vous devez l’implémenter manuellement en utilisant des tables incrémentielles avec une logique de fusion personnalisée. Vous écrivez votre propre logique valid_from/valid_to, votre propre gestion de l’historique, votre propre gestion des mises à jour tardives qui devraient modifier un enregistrement historique existant plutôt qu’en ajouter un nouveau.
Ce n’est pas un projet de week-end. Un SCD2 implémenté correctement nécessite de gérer les cas particuliers liés aux données tardives, aux mises à jour hors séquence et au comportement lors du chargement initial. Les snapshots dbt gèrent tout cela. Dataform vous laisse le faire vous-même.
Chaque table snapshot nécessite une réimplémentation personnalisée dans Dataform avant que la migration ne soit terminée.
L’écosystème de packages
Le hub de packages dbt compte plus de 200 packages communautaires. Ces packages couvrent les transformations spécifiques aux sources (GA4, Shopify, Stripe, Salesforce), les utilitaires transversaux (dbt_utils, dbt_date, dbt_audit_helper), les tests de qualité des données (dbt_expectations, Elementary) et les domaines spécialisés (modèles d’attribution, sessionisation, reconnaissance des revenus).
Les packages les plus importants pour la planification de la migration :
dbt_utils — Fonctions couramment utilisées comme surrogate_key, star, pivot, unpivot et date_spine. Si vous les utilisez, vous aurez besoin d’équivalents JavaScript dans le répertoire includes/ de Dataform. Certains sont simples à porter ; surrogate_key est une conversion bien connue. D’autres nécessitent un portage minutieux.
dbt_expectations — Plus de 50 tests de qualité des données portés depuis la bibliothèque Great Expectations. Vérifications de plages, validation par regex, détection de décalage de distribution, comparaisons inter-tables. Les assertions intégrées de Dataform couvrent trois cas : l’unicité, les nulls et les conditions sur les lignes. Tout le reste de dbt_expectations nécessite des fichiers d’assertions personnalisés écrits de zéro.
Packages spécifiques aux sources — Si vous utilisez dbt_ga4, dbt_shopify, fivetran_utils ou similaires, la logique de transformation contenue dans ces packages doit être réimplémentée. Certains de ces packages représentent des mois d’effort communautaire et gèrent des cas particuliers auxquels vous n’avez pas encore pensé.
Dataform n’a pas de hub de packages centralisé. Quelques dépôts communautaires existent, mais la découverte est fragmentée, la maintenance est incohérente, et la couverture est une fraction de l’écosystème dbt.
Chaque package activement utilisé devient une implémentation personnalisée à construire et à maintenir dans Dataform.
La stratégie incrémentale microbatch
La stratégie microbatch de dbt, introduite en 2024, traite les données par lots discrets bornés dans le temps. Au lieu d’une exécution incrémentale unique qui traite « tout depuis la dernière exécution », microbatch exécute des requêtes séparées pour chaque période de temps — une requête par heure, ou par jour, selon la configuration.
Cela est important pour :
- Les données tardives — Microbatch peut retraiter des fenêtres temporelles spécifiques pour capturer les enregistrements arrivés après l’exécution initiale, sans rechargement complet.
- Le contrôle des coûts — Le traitement des données en petits lots prévisibles rend les coûts BigQuery plus prévisibles qu’une seule grande fusion incrémentale.
- L’isolation des backfills — Le retraitement d’une période historique ne nécessite pas de toucher toute la table.
Dataform n’a pas de stratégie équivalente. Les tables incrémentielles dans Dataform supportent les fusions basées sur uniqueKey et updatePartitionFilter, mais il n’existe aucun mécanisme pour le traitement automatique par lots bornés dans le temps avec gestion des données tardives. Si votre projet dbt utilise microbatch pour ces patterns, vous devrez faire du travail d’implémentation personnalisé dans Dataform — et la version personnalisée sera probablement moins robuste que la gestion intégrée de dbt.
Cette lacune affecte principalement les équipes traitant des données d’événements à volume élevé ou gérant des pipelines avec des SLA stricts sur les données tardives. Si vous exécutez une logique incrémentale simple updated_at > last_run, elle ne s’applique pas. Mais si vous avez adopté microbatch spécifiquement pour gérer les cas particuliers pour lesquels il a été conçu, le perdre a des conséquences.
Slim CI
La fonctionnalité Slim CI de dbt Cloud identifie automatiquement quels modèles ont changé dans une pull request et construit uniquement ces modèles ainsi que leurs dépendants en aval. Elle crée des schémas spécifiques à la PR pour que la construction ne touche pas la production. Elle reporte les résultats dans la PR. L’ensemble fonctionne avec quelques clics de configuration — pas de pipelines YAML, pas de scripts personnalisés, pas d’appels API.
La valeur n’est pas que de la commodité. Slim CI signifie que chaque PR est validée avant la fusion, avec un coût proportionnel à ce qui a changé plutôt qu’une reconstruction complète du projet. Un changement sur un modèle de base déclenche une construction de ce modèle et de sa chaîne aval, et non une reconstruction complète du projet.
Les workflows Dataform ne se déclenchent pas nativement sur des événements git. La réplication de Slim CI dans Dataform requiert :
- GitHub Actions (ou Cloud Build) à l’écoute des événements de PR
- Un script appelant l’API REST Dataform pour créer un résultat de compilation
- Une logique personnalisée pour identifier les modèles modifiés et leurs dépendants
- La création et la suppression de schémas pour l’environnement de PR
- Le reporting des résultats dans la PR
Comme la note sur les lacunes des outils le détaille, c’est 2 à 4 semaines de travail d’ingénierie pour construire la première fois, plus la maintenance continue. Les équipes qui considèrent le CI comme non négociable — et elles ont raison — finissent souvent soit par construire cette infrastructure, soit par ignorer entièrement le CI. Aucun de ces résultats n’est aussi bon que le comportement out-of-the-box de dbt Cloud.
Pour les équipes qui utilisent dbt Core plutôt que dbt Cloud, cette lacune est moins prononcée : dbt Core nécessite également une construction de CI manuelle. Mais dbt build --select state:modified+ vous donne la logique de sélection des modèles ; Dataform n’a pas de concept comparable.
Applicabilité par projet
Chaque lacune s’applique de façon conditionnelle :
- Projets sans snapshots : la lacune SCD2 est sans importance
- Usage minimal des packages au-delà des bases de dbt_utils : gérable à porter
- Logique incrémentale standard
updated_at > last_run: la lacune microbatch ne s’applique pas - Équipes prêtes à investir dans une infrastructure CI personnalisée : Slim CI peut être répliqué (2 à 4 semaines de travail d’ingénierie)
Le cadre de décision aborde le nombre de lacunes qui s’appliquent simultanément — une lacune est une tâche de conversion ; trois ou quatre représentent un risque de migration.