Migration Dataform vers dbt

La migration entre Dataform et dbt est possible dans les deux sens, mais l’effort évolue de manière non linéaire avec la complexité du projet. La conversion simple des modèles est largement automatisable. La conversion des macros et de la logique JavaScript est là où les projets s’enlisent.

Outils de migration disponibles

dbt vers Dataform : ra_dbt_to_dataform convertit les projets dbt au format Dataform. Il utilise GPT-4 pour la traduction des macros complexes — un aveu que la conversion Jinja-vers-JavaScript est trop irrégulière pour un outillage déterministe. Le LLM gère les cas limites où les patterns Jinja n’ont pas d’équivalent JavaScript direct.

Dataform vers dbt : dataform-to-dbt fournit le chemin inverse. Les blocs config SQLX correspondent aux configurations YAML dbt. Les appels JavaScript ${ref()} deviennent du Jinja {{ ref() }}. La conversion structurelle est simple pour les modèles standard.

Les deux outils gèrent les 80 % faciles — définitions de modèles, configurations basiques, déclarations de dépendances. Aucun n’automatise pleinement les 20 % difficiles — logique personnalisée, templating complexe, et patterns spécifiques au projet.

Délais réalistes

La durée de migration varie considérablement selon ce que contient le projet, pas seulement le nombre de modèles :

Le saut de “moyen” à “grand” n’est pas proportionnel au nombre de modèles. Il reflète la complexité de la logique personnalisée qui s’accumule dans les projets matures. Un projet de 200 modèles avec des SELECT simples migre plus vite qu’un projet de 50 modèles avec un code JavaScript étendu de génération ou des macros Jinja profondément imbriquées.

Où les migrations deviennent douloureuses

Conversion des macros et du templating

C’est le coût dominant dans toute migration non triviale. Chaque bloc Jinja {% macro %} personnalisé doit être réécrit manuellement en JavaScript (ou vice versa). Les deux systèmes de templating sont conceptuellement similaires — tous deux génèrent du SQL à la compilation — mais syntaxiquement et structurellement différents d’une manière qui résiste à la traduction automatisée.

Les macros Jinja opèrent par concaténation de chaînes dans les fichiers SQL. Elles ressemblent à du SQL avec de la logique injectée :

{% macro cents_to_dollars(column_name, scale=2) %}
    ROUND({{ column_name }} / 100.0, {{ scale }})
{% endmacro %}

Le JavaScript dans Dataform opère par construction programmatique. La même logique a une apparence fondamentalement différente :

function centsToDollars(columnName, scale = 2) {
  return `ROUND(${columnName} / 100.0, ${scale})`;
}
module.exports = { centsToDollars };

Les macros utilitaires simples se traduisent proprement. La douleur commence avec :

• Les macros qui interrogent la base de données — run_query() de dbt a des sémantiques d’exécution différentes du modèle de compilation de Dataform
• Les macros utilisant des objets de contexte dbt — this, target, model, graph n’ont pas d’équivalents directs dans Dataform
• Les patterns dispatch — les macros cross-database utilisant adapter.dispatch() sont sans objet dans le monde mono-plateforme de Dataform, mais la logique qu’elles encodent doit tout de même exister
• Les macros de packages — toute macro de dbt-utils, dbt-expectations, ou d’autres packages doit être réimplémentée ou remplacée par des assertions personnalisées

Pour les projets qui s’appuient fortement sur des macros partagées (un pattern courant dans les projets dbt matures avec 20 à 30 macros personnalisées), budgétisez 40 à 60 % du temps total de migration uniquement pour la conversion des macros.

Exécution parallèle

Les migrations enterprise requièrent une exécution parallèle : les deux outils exécutant les mêmes transformations contre des données de production, avec des résultats comparés pour équivalence. Cette période de validation dure typiquement 2 à 8 semaines selon la cadence de rafraîchissement des données et la tolérance au risque des parties prenantes.

L’exécution parallèle détecte :

• Les différences logiques introduites lors de la conversion (comportement d’arrondi, gestion des nulls, sémantiques de jointure)
• Les différences d’ordre qui se manifestent dans les rapports en aval (changements d’ordre des lignes cassant des outils BI avec des hypothèses codées en dur)
• Les différences temporelles quand les modèles incrémentaux traitent des fenêtres de données différentes pendant la transition

Le package dbt-audit-helper simplifie les requêtes de comparaison pendant l’exécution parallèle. Dataform n’a pas d’utilitaire équivalent, donc la logique de comparaison doit être écrite manuellement.

État des modèles incrémentaux

Les modèles incrémentaux méritent une attention particulière pendant la migration. Les deux outils supportent la matérialisation incrémentale, mais les mécanismes de suivi d’état diffèrent. Un modèle construit incrémentalement dans un outil ne peut pas reprendre incrémentalement dans l’autre — le premier run dans le nouvel outil doit être un full refresh.

Pour les grandes tables, cela signifie un pic de coût ponctuel pendant la migration. Un modèle qui traite normalement 20 Go incrémentalement traitera 2 To lors de son premier run dans le nouvel outil. Planifier la capacité BigQuery et le budget en conséquence.

La règle des deux ans

Une heuristique pratique pour les décisions de migration : si le coût total de migration (temps d’ingénierie, exécution parallèle, perte de productivité pendant la transition) dépasse deux années d’économies de licence, la migration n’a pas de sens financier.

Pour une équipe de 10 ingénieurs sur dbt Cloud (12 000 $/an de licence), le seuil des deux ans est de 24 000 $ en coût total de migration. Si le projet comporte 50+ macros personnalisées, des pipelines CI/CD complexes, et des exigences de validation enterprise, le coût de migration dépassera probablement ce seuil. Les économies de licence sont réelles mais insuffisantes pour justifier la perturbation.

Le calcul s’inverse dans l’autre sens. Passer de Dataform à dbt n’implique aucune économie de licence pour financer la migration — cela coûte à la fois en effort de migration et en nouvelle licence. Les équipes font généralement ce choix pour l’accès à l’écosystème (packages, CI/CD, outillage IDE) ou la portabilité entre plateformes plutôt que pour l’optimisation des coûts.