Votre schéma Fivetran vous oblige-t-il à reconstruire le modèle après chaque chargement ?

Un schéma standardisé par connecteur est ce qui rend un pipeline managé rapide à mettre en place. C’est aussi ce qui rend le deuxième mois plus difficile que le premier. La structure des données est décidée par le connecteur, et tout ce dont votre métier a réellement besoin (clés conformes, champs personnalisés, règles qui couvrent trois sources) doit être construit par-dessus, dans dbt ou à la main.

Pourquoi le schéma figé vous résiste

• Le schéma est celui du fournisseur, pas le vôtre. Il reflète l’API du système source, pas la façon dont le métier parle de clients, de commandes ou de comptes.
• Le SQL post-chargement est le vrai modèle, et il n’est géré par personne. L’harmonisation des clés, le dédoublonnage, la gestion de l’historique et les règles finissent dans des scripts que personne n’a conçus comme un ensemble, chacun dans le style de celui qui l’a écrit.
• Les changements de source arrivent sous forme d’incidents de production. Une colonne renommée en amont casse une transformation en aval, et on ne le découvre que lorsqu’un rapport de direction échoue ou affiche de mauvais chiffres.
• La même entité se retrouve dans plusieurs silos. Le client du CRM, le client de l’ERP et le client de la boutique en ligne sont trois tables avec trois clés jusqu’à ce que quelqu’un écrive la jointure.

Rien de tout cela n’est la faute du connecteur. C’est ce qui arrive quand l’outil qui dépose les données est aussi censé leur donner une structure utilisable par le métier.

Où la structure doit être définie

• La structure relève de la modélisation, pas de l’écriture de scripts. Les clés métier, les relations et les attributs devraient être déclarés une seule fois, dans un modèle, dont le code de chargement est ensuite dérivé.
• La couche brute devrait absorber le changement. Le Data Vault 2.0 sépare les clés, les relations et le contexte précisément pour qu’un nouvel attribut source donne lieu à un nouveau satellite, et non à une réécriture.
• Les règles ont leur place au-dessus de la couche brute. Les dimensions conformes et la logique métier se situent dans le Business Vault et les marts, là où un changement de schéma source ne peut pas les atteindre.

Ce qui change avec Datavault Builder

Datavault Builder remplace le schéma cible figé par une couche Data Vault 2.0 pilotée par le modèle, et génère le code de chargement à partir du modèle.

• Les tables de staging restent telles que le connecteur les livre. Rien n’est remodelé à la main. Le mapping de la table de staging vers hub, link et satellite se fait visuellement.
• Les clés métier sont harmonisées dans le modèle. Le client issu de trois systèmes devient un seul hub, avec le contexte de chaque source dans son propre satellite. La jointure est déclarée une seule fois.
• Un changement de source est un changement de mapping. Mettez à jour le mapping, régénérez, et le Business Vault comme les marts au-dessus restent intacts.
• Les petits changements sont absorbés automatiquement. Une colonne qui disparaît est chargée à null avec un avertissement, sans faire échouer l’exécution. Un varchar qui s’allonge est élargi, pas tronqué.
• Tous les pipelines ont la même structure. Les chargements sont générés, donc il n’y a pas de style propre à chaque développeur à relire, ni de script que seul son auteur comprend.
• La documentation et le lineage sont générés eux aussi. Chaque règle se situe dans le Business Vault ou dans la couche des marts, est visible dans le modèle, et peut être tracée du rapport jusqu’à la source sans que personne ait à la documenter.
• Le résultat reste un schéma en étoile. Des marts dimensionnels sont générés par-dessus, donc la couche BI voit des dimensions conformes, pas les détails internes du vault.

Ce qu’il faut décider

Auditez les scripts post-chargement qui n’existent que pour remodeler la sortie du connecteur : harmonisation des clés, dédoublonnage, historique, jointures inter-sources. Cette liste est le modèle que vous maintenez à la main. C’est la première chose à déplacer.