Zwingt Sie Ihr Fivetran-Schema, Ihr Datenmodell nach jedem Load neu aufzubauen?

Ein standardisiertes Schema pro Connector ist das, was eine Managed Pipeline schnell einrichtbar macht. Es ist auch das, was den zweiten Monat schwerer macht als den ersten. Die Form der Daten entscheidet der Connector, und alles, was Ihr Business tatsächlich braucht, konforme Schlüssel, eigene Felder, Regeln über drei Quellen hinweg, muss obendrauf gebaut werden, in dbt oder von Hand.

Warum das feste Schema gegen Sie arbeitet

• Das Schema gibt der Anbieter vor, nicht Ihr Fachbereich. Es spiegelt die API des Quellsystems, nicht die Art, wie das Business über Kunden, Aufträge oder Konten spricht.
• Die eigentliche Transformationslogik steckt in nachgelagerten SQL-Skripten, und die sind ungesteuert. Harmonisierung der Schlüssel, Deduplizierung, Umgang mit Historie und Regeln landen in Skripten, die niemand als Ganzes entworfen hat, jedes im Stil dessen, der es geschrieben hat.
• Änderungen im Quellsystem schlagen als Produktionsvorfälle auf. Eine im Quellsystem umbenannte Spalte ist eine gebrochene Transformation weiter unten, entdeckt erst, wenn ein Management-Report scheitert oder falsche Zahlen zeigt.
• Dieselbe Entität landet in Silos. Kunde aus dem CRM, Kunde aus dem ERP und Kunde aus dem Webshop sind drei Tabellen mit drei Schlüsseln, bis jemand den Join schreibt.

Nichts davon ist ein Fehler des Connectors. Es ist das, was passiert, wenn das Tool, das die Daten ablegt, ihnen auch noch eine Form geben soll, die das Business nutzen kann.

Wo die Form hingehört

• Die Datenstruktur ist eine Modellierungsaufgabe, keine Skriptaufgabe. Business-Keys, Beziehungen und Attribute sollten einmal deklariert werden, in einem Modell, und der Ladecode daraus abgeleitet werden.
• Die Rohschicht sollte Änderungen aufnehmen. Data Vault 2.0 trennt Schlüssel, Beziehungen und Kontext genau deshalb, damit ein neues Quellattribut ein neuer Satellit ist, kein Umbau.
• Regeln gehören über die Rohschicht. Konforme Dimensionen und Geschäftslogik sitzen im Business Vault und in den Marts, wo eine Änderung des Quellschemas sie nicht erreichen kann.

Was sich mit Datavault Builder ändert

Datavault Builder ersetzt das feste Zielschema durch eine modellgetriebene Data Vault 2.0 Schicht und generiert den Ladecode aus dem Modell.

• Landing-Tabellen bleiben, wie der Connector sie liefert. Nichts wird von Hand umgeformt. Das Mapping von Landing-Tabelle auf Hub, Link und Satellit passiert visuell.
• Business-Keys werden zentral im Modell konsolidiert. Kunde aus drei Systemen wird ein Hub, mit dem Kontext jeder Quelle in ihrem eigenen Satelliten. Der Join wird einmal deklariert.
• Eine Quelländerung ist ein Mapping-Update. Mapping aktualisieren, neu generieren, und Business Vault und Marts darüber bleiben unberührt.
• Kleine Schema-Abweichungen werden automatisch abgefangen. Eine Spalte, die verschwindet, wird als Null mit einer Warnung geladen, nicht als gescheiterter Lauf. Ein Varchar, der wächst, wird verbreitert, nicht abgeschnitten.
• Jede Pipeline hat dieselbe Form. Die Loads sind generiert, es gibt also keinen Stil pro Entwickler zu reviewen und kein Skript, das nur sein Autor versteht.
• Dokumentation und Data Lineage entstehen automatisch mit. Jede Regel sitzt im Business Vault oder in der Mart-Schicht, ist im Modell sichtbar und lässt sich vom Report bis zur Quelle zurückverfolgen, ohne dass jemand sie aufschreibt.
• Das Ergebnis ist weiterhin ein Star-Schema. Dimensionale Marts werden obendrauf generiert, die BI-Schicht sieht also konforme Dimensionen, keine Vault-Interna.

Was zu entscheiden ist

Analysieren Sie die Post-Load-Skripte, die nur existieren, um den Connector-Output aufzubereiten: Harmonisierung der Schlüssel, Dedupe, Historie, Joins über Quellen hinweg. Diese Liste ist das Modell, das Sie bisher von Hand gepflegt haben. Es ist das Erste, was umziehen sollte.