Coûts et schémas Fivetran qui vous échappent ? Comment la modélisation automatisée supprime les points de friction de l'ingestion

Le premier mois avec Fivetran est un bon mois. Les connecteurs sont en service en un après-midi, l’entrepôt se remplit, et l’équipe peut se mettre à construire. La conversation change avec la facture qui tombe après la première migration ERP, et celle sur le schéma s’ouvre généralement le même trimestre.

Le compromis de l’ELT plug and play

L’ingestion managée sacrifie deux choses au profit de la commodité, et ni l’une ni l’autre ne se voit le premier jour.

• La prévisibilité du coût. Les Monthly Active Rows mesurent ce qui change, et ce qui change est décidé par les équipes des systèmes sources qui lancent des migrations et des mises à jour en masse. La facture suit leur calendrier de projets, pas votre budget. Le détail est dans l’article sur la tarification MAR.
• Le contrôle du schéma. Chaque connecteur dépose son propre schéma standardisé. Les clés conformes, les champs personnalisés et les règles inter-sources doivent être ajoutés par-dessus, et cassent quand la source change. Le détail est dans l’article sur les schémas figés.

Les deux relèvent du même problème sous-jacent. L’outil qui déplace les lignes a aussi été rendu responsable de ce qu’elles coûtent et de la structure qu’elles prennent, alors qu’il n’a jamais été conçu que pour la première tâche.

Deux solutions, et vous pouvez adopter les deux

Internalisez l’ingestion des tables les plus lourdes. Datavault Builder inclut des chargements batch, delta et CDC depuis des bases de données, des fichiers, des API REST, des sources NoSQL et Python, avec des flux comme Kafka qui arrivent en micro-batches. Les quelques tables qui concentrent l’essentiel des MAR arrivent via la plateforme, sur des ressources de calcul que vous possédez déjà. La longue traîne des sources SaaS reste sur le connecteur, là où il est bon marché.

Placez derrière tout cela un modèle que vous possédez. Tout ce qui arrive dans le staging, par connecteur ou par chargement direct, est mappé visuellement dans un modèle Data Vault 2.0 : des hubs pour les clés métier, des links pour les relations, des satellites pour le contexte et l’historique. Le code de chargement est généré à partir de ce modèle. Un changement de source est un changement de mapping, et le Business Vault et les marts au-dessus ne bougent pas.

Ce que cela change en pratique

• Les rechargements restent dans le staging. Seul le delta se charge dans le vault, donc un rechargement complet en amont n’est pas un rechargement complet de chaque couche.
• Le client est un seul hub, pas trois tables. Les clés inter-sources sont harmonisées dans le modèle, une seule fois, avec le lineage.
• Les règles ont un emplacement précis. La logique métier réside dans le Business Vault ou dans la couche des marts, visible dans le modèle, et non éparpillée entre des scripts et des notebooks.
• La couche BI voit un schéma en étoile. Des marts dimensionnels sont générés par-dessus, donc les concepteurs de rapports ne voient rien du vault.
• Le coût devient une décision de dimensionnement. La puissance de calcul de l’entrepôt se mesure et se réserve. L’activité des lignes dans le système de quelqu’un d’autre, non.

Par où commencer

Deux listes suffisent, et un après-midi de travail. Le rapport MAR trié par table vous dit quelles sources déplacer vers l’ingestion directe. L’inventaire des scripts post-chargement qui n’existent que pour remodeler la sortie du connecteur vous dit ce que le modèle doit contenir. Les deux listes sont généralement plus courtes que prévu, et à elles deux elles constituent tout le projet.