Der dbt Kompromiss: Code-Wildwuchs, versteckte TCO und das Argument für automatisierte Modellierung

dbt, inzwischen gemeinsam mit Fivetran unter einem Dach, hat sich seinen Platz verdient. Git, Tests, modulares SQL und ein gemeinsames Vokabular für Transformation fehlten im Analytics Engineering, und dbt hat sie geliefert. Der Preis, den es dafür verlangt, zeigt sich später, an vier Stellen, die in dieser Reihe jeweils ihren eigenen Artikel haben.

Das doppelte Kostenmodell

Teams, die dbt nutzen, stehen vor einer Weggabelung. dbt Core ist kostenlos im Betrieb und überlässt Ausführung, Scheduling, CI und Infrastruktur dem Team, die Kosten sind also Platform-Engineering Zeit. dbt Cloud liefert Scheduler, IDE, Orchestrierung und semantische Schicht, bepreist pro Entwicklerlizenz plus Nutzung, die Kosten sind also ein Abonnement, das mit dem Team und der Laufhäufigkeit wächst. Beide Wege kosten. Der eine in Abonnements, der andere in Gehältern. Die Details stehen in dem Artikel über Core gegen Cloud.

Das architektonische Hindernis

• Wildwuchs. ref() macht ein neues Modell zu einer Entscheidung von einer Zeile, und Projekte wachsen auf Hunderte von Dateien ohne echte Governance an. Wird ein Business-Key weiter oben geändert, muss jede abhängige Struktur gefunden und angepasst werden. Siehe den Artikel über Modell-Wildwuchs.
• Compute. Alles läuft im Warehouse, und ein Full Rebuild, wo ein Delta reichen würde, läuft stillschweigend erfolgreich durch und schlägt sich erst in den Compute-Credits nieder. Inkrementelle Logik ist optional und pro Modell. dbt-State überspringt jetzt unveränderte Modelle; es ändert nicht, was ein Modell tut, wenn es läuft. Siehe den Artikel über Warehouse Compute.
• Die Ingestions-Lücke. dbt ist nur Transformation. Die Daten zu landen ist ein zweites Produkt mit einer zweiten Rechnung und einem zweiten Schema, auch jetzt, wo es derselbe Anbieter ist. Siehe den Artikel über die Ingestions-Lücke.

Freiheit gegen Standardisierung

Es gibt einen fünften Unterschied, der kein Schmerzpunkt ist, sondern eine Designentscheidung. dbt ist offen, und das ist ein echter Vorteil: jedes Pattern, jedes Package, jede Konvention, die das Team bevorzugt. Es ist auch der Ursprung der Kosten, denn jede dieser Entscheidungen müssen Sie bauen, testen und aktuell halten. Offenheit ohne Standard bedeutet, dass keine zwei dbt-Projekte gleich aussehen: Jedes ist ein Unikat, das nur seine Autoren pflegen können, und jeder neue Mitarbeiter lernt es von Grund auf. Und ein codegetriebenes Projekt wird von technischen Details geformt, Tabelle für Tabelle und Makro für Makro, nicht von dem, was das Business sehen muss. Datavault Builder ist standardisiert und modellgetrieben: weniger Entscheidungen, geringere Entwicklungs- und Wartungskosten, und ein Modell, das Fachanwender lesen und mitgestalten können, weil es ihre Konzepte beschreibt und nicht den Code.

Alle vier haben eine Ursache. Der Großteil eines dbt-Projekts ist strukturell: Staging, Schlüssel, Deduplizierung, Historie. Fairerweise: dbt hat Patterns dafür, Makros und Packages, die den Standard kodieren. Aber jeder Entwickler kann sie bearbeiten oder abzweigen, und ein gemeinsames Pattern sauber zu ändern bedeutet Regressionstests und Migrationsskripte für alles, was darauf gebaut ist. Wenn ein Pattern also nicht ganz passt, taucht eine zweite Version davon auf, und das Projekt endet mit mehreren Versionen derselben Struktur. Die eigene Geschäftslogik ist der kleinere Teil, und sie kann im Modell leben oder, wenn Sie das bevorzugen, in dbt.

Was automatisierte Modellierung ändert

Datavault Builder hält die Struktur in einem visuellen Modell und generiert daraus die Schichten Staging, Raw Vault und Business Vault, zusammen mit Ingestion, Orchestrierung, Deployment und Lineage, in einer Plattform.

• Der strukturelle Anteil verlässt die Codebasis. Hubs, Links, Satelliten und ihre Delta Loads werden generiert, auf die Zielengine abgestimmt und neu generiert, wenn sich das Modell ändert.
• Ingestion ist im selben Tool. Batch, Delta und CDC aus Datenbanken, Dateien, REST-APIs, NoSQL und Python-Quellen, mit Streams wie Kafka, die als Micro-Batches ankommen. Keine Übergabe.
• Compute folgt der Änderung. Jeder generierte Load ist konzeptionell bedingt ein Delta, die nächtlichen Kosten folgen also dem, wie viel sich die Quellen bewegt haben.
• Die Patterns halten mit der Datenbank Schritt, ohne Ihr Zutun. Wenn Snowflake, Databricks oder BigQuery eine neue Funktion ausliefern, sind die aktualisierten Lademusters und die Migrationsskripte für bestehende Strukturen Teil des Produkts. In dbt ist das ein Makro Update, ein Testlauf, ein Migrationsskript pro Struktur und ein weiterer Testlauf, alles bei Ihnen. Über Jahre ist das die Stelle, an der der Großteil der Wartungskosten sitzt.
• Die Kosten sind vorhersehbar. Eine Serverlizenz in einer von drei Größen plus Entwickler, und nichts, was pro Lauf oder pro Load gemessen wird. Kein Orchestrierungs-Stack, der für die generierten Schichten zu betreiben wäre.
• Die Auslieferungsschicht ist ebenfalls modellgetrieben. Marts und Datenprodukte werden per Drag-and-Drop auf der semantischen Schicht zusammengestellt, und Geschäftsregeln werden in der Plattform verwaltet und versioniert, sodass fachlich orientierte Personen entscheiden, welche Daten sie brauchen.
• Die Migration eines AutomateDV Projekts ist metadatengetrieben. Der Migration Vault ist ein Datenmodell aus Hubs, Links, Satelliten, Quellen, Business-Keys und Attributen. Mappen Sie, was das dbt-Projekt bereits deklariert, hinein, und das Deployment Paket wird aus diesem Mapping generiert. Derselbe Weg funktioniert für fast alles, das Struktur zu beschreiben hat, einschließlich eines 3NF Warehouse.
• dbt bleibt weiterhin optional nutzbar. Wenn der Betrieb in dbt bleibt, generiert Datavault Builder die dbt-Modelle aus demselben Modell. Der Prozess bleibt modellgetrieben, und die Modelle werden per Neugenerierung aktualisiert, was ein viel einfacherer Weg ist, als sie von Hand zu bearbeiten.

Wo Sie anfangen

Prüfen Sie das Projekt und sortieren Sie jedes Modell danach, was es tut: staged, gekeyt, historisiert oder berechnet. Die ersten drei sind der strukturelle Anteil. Dieser Anteil, plus das Ingestion Produkt davor, ist das, was ein generiertes Warehouse ersetzt. Was übrig bleibt, ist entweder gar kein dbt-Projekt mehr, oder eines, das aus dem Modell generiert und nie von Hand bearbeitet wird.