Explodiert Ihre Fivetran-Rechnung jedes Mal, wenn sich in einer Quelltabelle viel bewegt?

Monthly Active Rows (MAR) sind eine vernünftige Art, einen Connector abzurechnen. Zum Problem werden sie, wenn jemand anderes entscheidet, wie viele Zeilen sich ändern. Eine Preisanpassung per Bulk-Update im ERP, eine Schemamigration, die eine Spalte für jeden Datensatz neu schreibt, eine Datenqualitätsbereinigung, die die halbe Kundentabelle berührt: Jede davon zählt jede betroffene Zeile erneut als aktiv, und die Rechnung kommt im Nachhinein.

Warum Sie die Rechnung nicht in der Hand haben

• MAR zählt berührte Zeilen, nicht relevante Zeilen. Eine Migration, die eine Spalte in zehn Millionen Datensätzen ändert, sind zehn Millionen aktive Zeilen, auch wenn sich weiter unten nichts ändern musste.
• Der Kostenauslöser liegt außerhalb Ihrer Kontrolle. Quellsystem-Teams fragen vor einer Bulk Operation nicht das Ingestion Budget, und das sollten sie auch nicht müssen.
• Dieselbe Zeile wird zweimal bezahlt. Einmal auf dem Weg hinein, und noch einmal als Compute, wenn die Landing-Tabelle komplett neu verarbeitet wird, weil weiter unten niemand weiß, welche Zeilen sich geändert haben.
• Kostenprognosen werden zur Kaffeesatzleserei. Der Connector misst Aktivität, und Aktivität ist eine Funktion dessen, was andere Teams tun.

Fivetran rechnet exakt nach seinem Preismodell ab. Die Frage ist, ob die Abrechnung pro Zeile die richtige Ökonomie für Ihre größten und bewegtesten Tabellen ist.

Wo die Kosten eigentlich hingehören

• Das Laden datenintensiver Tabellen ist eine Kernaufgabe des Data Warehouse. Eine modellgetriebene Plattform lädt sie als Teil der Warehouse Generierung, auf Compute, das Ihnen bereits gehört.
• Nur das Delta sollte weiter nach unten wandern. Eine automatisierte Data Vault Architektur lädt nur das, was sich geändert hat, in Hubs, Links und Satelliten. Ein Full Reload im Staging wird nicht zu einem Full Reload jeder Schicht darüber.
• Der Long-Tail kann auf dem Connector bleiben. Managed-Connectors sind stark bei SaaS Quellen mit geringem Volumen, wo MAR klein und vorhersehbar bleibt.

Was sich mit Datavault Builder ändert

Datavault Builder bringt seine eigene Ingestion mit: Batch, Delta und CDC Loads aus Datenbanken, Dateien, REST-APIs, NoSQL und Python-Quellen, mit Streams wie Kafka, die als Micro-Batches ankommen, alles aus derselben Plattform, die auch den Rest des Warehouse generiert.

• Volumenstarke Tabellen werden von der zeilenbasierten Abrechnung entkoppelt. Sie landen über die Plattform im Staging, und die Connector-Rechnung hört auf, dem Projektkalender Ihres ERP-Teams zu folgen.
• Full Rebuilds bleiben auf das Staging beschränkt. Die generierten Vault-Loads vergleichen gegen das, was bereits historisiert ist, und bewegen nur das Delta. Ein Reload im Quellsystem ist also kein Reload überall.
• Auch Tabellen, die weiterhin über den Connector laufen, bleiben entkoppelt. Rohe Landing-Tabellen und die historisierte Schicht sind getrennt, die Wahl des Connectors pro Tabelle bleibt also Ihre und ist umkehrbar.
• Kosten werden wieder planbar und kalkulierbar. Warehouse Compute können Sie messen, reservieren und prognostizieren. Zeilenaktivität im System von jemand anderem nicht.

Was zu entscheiden ist

Analysieren Sie Ihren MAR-Report der letzten sechs Monate und sortieren Sie ihn nach Tabellen. Wenn die obersten fünf bis zehn Tabellen den Großteil der Kosten tragen, ist das die Liste, die auf direkte Ingestion umziehen sollte. Alles unterhalb der Linie kann genau so bleiben, wie es ist.