Votre facture Fivetran bondit-elle chaque fois qu'une table source devient très active ?

Les Monthly Active Rows (MAR) sont une façon raisonnable de mesurer l’usage d’un connecteur. Elles deviennent un problème quand c’est quelqu’un d’autre qui décide du nombre de lignes qui changent. Une mise à jour de prix en masse dans l’ERP, une migration de schéma qui réécrit une colonne pour chaque enregistrement, une opération de mise en qualité des données qui touche la moitié de la table clients : dans chaque cas, toutes les lignes concernées sont de nouveau comptées comme actives, et la facture arrive après coup.

Pourquoi la facture échappe à votre contrôle

• Les MAR comptent les lignes touchées, pas les lignes qui comptent. Une migration qui modifie une colonne sur dix millions d’enregistrements, ce sont dix millions de lignes actives, même si rien en aval n’avait besoin de changer.
• Le déclencheur est en amont. Les équipes des systèmes sources ne consultent pas le budget d’ingestion avant une opération en masse, et elles ne devraient pas avoir à le faire.
• La même ligne est payée deux fois. Une fois à l’entrée, et une nouvelle fois en puissance de calcul quand la table de staging est retraitée en entier parce que rien en aval ne sait quelles lignes ont changé.
• Prévoir revient à deviner. Le connecteur mesure l’activité, et l’activité dépend de ce que font les autres équipes.

Fivetran fait exactement ce que sa tarification prévoit. La question est de savoir si la mesure par ligne est le bon modèle économique pour vos tables les plus grandes et les plus actives.

Où le coût devrait réellement se situer

• L’ingestion des tables volumineuses relève de l’entrepôt de données. Une plateforme pilotée par le modèle les charge dans le cadre de la génération de l’entrepôt, sur des ressources de calcul que vous possédez déjà.
• Seul le delta devrait circuler en aval. Une architecture Data Vault automatisée ne charge que ce qui a changé dans les hubs, links et satellites. Un rechargement complet dans le staging ne devient pas un rechargement complet de chaque couche au-dessus.
• La longue traîne peut rester sur le connecteur. Les connecteurs managés sont parfaits pour les sources SaaS à faible volume, où les MAR restent faibles et prévisibles.

Ce qui change avec Datavault Builder

Datavault Builder inclut sa propre ingestion : 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, le tout depuis la même plateforme qui génère le reste de l’entrepôt.

• Les tables les plus sollicitées échappent aux frais par ligne. Elles arrivent dans le staging via la plateforme, et la facture du connecteur cesse de suivre le calendrier de projets de votre équipe ERP.
• Les rechargements restent dans le staging. Les chargements de vault générés comparent les données à ce qui est déjà historisé et ne déplacent que le delta, donc un rechargement en amont n’est pas un rechargement partout.
• Les tables qui restent sur le connecteur sont quand même découplées. Les tables brutes du staging et la couche historisée sont séparées, donc le choix du connecteur par table vous appartient et reste réversible.
• Le coût devient une question de dimensionnement. La puissance de calcul de l’entrepôt se mesure, se réserve et se prévoit. L’activité des lignes dans le système de quelqu’un d’autre, non.

Ce qu’il faut décider

Sortez le rapport MAR des six derniers mois et triez-le par table. Si les cinq à dix premières tables concentrent l’essentiel du coût, c’est la liste à déplacer vers l’ingestion directe. Tout le reste peut rester exactement tel quel.