Hat Ihr dbt-Projekt mehr Modelle, als irgendjemand erklären kann?

dbt, inzwischen gemeinsam mit Fivetran unter einem Dach, hat das Anlegen eines Modells trivial gemacht. select * from ref('...'), und ein neuer Knoten existiert. Das ist das Feature, und über zwei oder drei Jahre ist es auch der Weg, auf dem ein Projekt in Hunderte Modelle wächst, mit einer Lineage, die niemand mehr im Kopf behalten kann. Wenn neuer Code keinen Aufwand bedeutet, wächst der Bestand ganz von allein.

Warum Projekte wuchern

• Kopieren ist einfacher, als bestehenden Code anzupassen. dbt hat Makros und Packages für die Standard-Patterns, aber jeder Entwickler kann sie bearbeiten, und ein gemeinsames sauber zu ändern bedeutet Regressionstests und Migrationsskripte. Also bekommt ein Pattern, das nicht ganz passt, eine zweite Version.
• Struktur und Logik leben in denselben Dateien. Ein Modell, das eine Quelle staged, eines, das Historie behandelt, und eines, das Marge berechnet, sehen im DAG alle gleich aus.
• Abhängigkeiten werden deklariert, nicht entworfen. ref() hält fest, dass ein Modell ein anderes liest; es sagt nicht, warum, oder was bricht, wenn sich der Schlüssel weiter oben ändert.
• Governance kommt im Nachhinein. Namenskonventionen, Ordner und Tests werden auf ein Projekt angewendet, das bereits groß war, als jemand sie aufschrieb.

Das Tooling trägt keine Schuld. Ein Framework, das SQL modular macht, wird benutzt werden, um viel modulares SQL zu schreiben.

Wo die Struktur hingehört

• Die meisten Modelle sind strukturell. Staging, Deduplizierung, Schlüsselerzeugung, Historienverfolgung: dasselbe Pattern pro Quelle, nur mit anderen Spaltennamen.
• Struktureller Code sollte generiert werden, nicht angehäuft. Business-Key, Beziehungen und Attribute einmal deklarieren und den Ladecode aus einem Pattern ableiten, das kein Projekt bearbeitet.
• Logik ist der Teil, den es sich lohnt von Hand zu schreiben. Geschäftsregeln, Kennzahlen und Mart-Strukturen sind ein kleiner Anteil des Projekts und der Teil, der ein Code-Review verdient.

Was sich mit Datavault Builder ändert

Datavault Builder hält die Struktur in einem visuellen Modell und generiert daraus Hubs, Links, Satelliten und ihre Loads, sodass der wiederholte Teil des Projekts aufhört, aus Dateien zu bestehen.

• Eine Definition pro Konzept. Ein Kunden-Hub mit fünf Quellen ist ein Hub und fünf Mappings im Modell, nicht fünfzehn Modelle in einem Ordner.
• Abhängigkeiten werden abgeleitet. Ladereihenfolge und Lineage folgen aus dem Modell, eine Schlüsseländerung weiter oben ist also sichtbar, bevor sie deployt wird, nicht danach.
• Metadaten wandern durch die Schichten. Typen, Schlüssel und Beschreibungen werden einmal deklariert und vom Staging bis zu den Marts mitgeführt, statt in jeder Modelldatei wiederholt zu werden.
• Refactoring ist eine Modelländerung. Mapping ändern, neu generieren, und jede abhängige Struktur wird konsistent neu gebaut.
• Das Modell ist die Dokumentation. Lineage, Definitionen und Historienregeln sind an einem Ort lesbar, ganz ohne manuellen dbt-Docs-Build.
• Geschäftsregeln werden im Modell verwaltet, mit Versionen. Die Auslieferungsschicht wird per Drag-and-Drop auf der semantischen Schicht gebaut, Regeln und Datenprodukte haben also ein Zuhause und eine Historie.
• dbt kann bleiben, generiert. Wenn der Betrieb in dbt bleibt, werden die dbt-Modelle aus demselben Modell generiert und bei Änderungen neu generiert, was ein viel einfacherer Weg ist, sie zu aktualisieren, als Hunderte Dateien zu bearbeiten.

Was zu entscheiden ist

Prüfen Sie das Projekt und sortieren Sie jedes Modell danach, was es tut: staged, gekeyt, historisiert oder berechnet. Wenn die ersten drei den Großteil der Liste ausmachen, ist das der strukturelle Anteil, und genau den sollte ein Generator übernehmen.