Wächst Ihre dbt-Rechnung in Seats oder in Engineers?

dbt, inzwischen gemeinsam mit Fivetran unter einem Dach, gab SQL die Dinge, die Software Engineering seit Jahren hatte: Versionskontrolle, Tests, Modularität. Deshalb setzen Teams es ein. Das Gespräch über die Kosten kommt später, und es kommt auf beiden Wegen, die dbt anbietet.

Warum die Schicht mehr kostet als die Lizenz

• dbt Core ist kostenlos zum Herunterladen, nicht kostenlos im Betrieb. Jemand richtet den Orchestrator, die CI Pipeline, den Artifact-Storage und das State-Deferral ein und hält sie dann am Laufen. Dieser Jemand ist ein Engineer, der eingestellt wurde, um Daten zu modellieren.
• dbt Cloud wird pro Entwickler plus Nutzung bepreist. Seats skalieren mit dem Team, und die Nutzungsmessung bedeutet, dass die Rechnung sich damit bewegt, wie oft Modelle gebaut werden. Vorhersehbar in einem ruhigen Monat, weniger in einem bewegten.
• Beide Wege zahlen Warehouse Compute obendrauf. Jeder Lauf wird in Snowflake, BigQuery oder Databricks ausgeführt, und diese Rechnung ist getrennt von den Seats wie von den Gehältern.
• Bei beiden Modellen bleibt der Support an Ihnen hängen. dbt Core wird von der Community unterstützt; dbt Cloud fügt Herstellersupport hinzu, für die Plattform, nicht für die Patterns in Ihrem Projekt.
• Beide Wege erfordern, die Lademuster selbst zu warten. Wenn die Datenbank eine neue Funktion ausliefert, aktualisiert jemand die Makros, testet sie, schreibt Migrationsskripte für jede bestehende Struktur und testet auch diese. Diese Arbeit hat auf keiner der beiden Rechnungen eine Position, und über die Lebensdauer eines Warehouse ist sie der größte Wartungsposten der Schicht.
• Offenheit ist der Vorteil, und die Kosten. Jedes Pattern und jede Konvention können Sie wählen, das ist der Reiz, und Sie müssen sie bauen, testen und aktuell halten, das ist die Rechnung.
• Die Wahl wird als Entweder-oder dargestellt. Entweder Abonnements oder Platform Engineering. Die Option, die niemand präsentiert, ist eine Transformationsschicht, die von vornherein weniger handgeschriebenen Code braucht.

Wo die Kosten tatsächlich sitzen

• Der Großteil eines dbt-Projekts ist dasselbe Pattern, wiederholt. Staging-Modelle, Schlüsselbehandlung, Deduplizierung und Historienlogik werden pro Quelle geschrieben und pro Zeitplan neu ausgeführt.
• Wiederholte Patterns sind das, wofür Generatoren da sind. Eine modellgetriebene Plattform leitet diesen Code aus dem Modell ab, er wird also weder von Hand geschrieben noch gepflegt.
• Eigene Logik ist der kleine Teil. Geschäftsregeln und Kennzahlen, die wirklich maßgeschneidertes SQL brauchen, sind ein Bruchteil der Codebasis, und sie sind der Teil, in dem dbt am besten ist.

Was sich mit Datavault Builder ändert

Datavault Builder generiert die Schichten Staging, Raw Vault und Business Vault aus einem visuellen Modell, mit Orchestrierung, Deployment, Dokumentation und Lineage in derselben Plattform.

• Der generierte Teil fällt als Wartungsaufwand aus der Codebasis heraus. Keine Staging-Modelle zu schreiben, keine inkrementellen Makros zu pflegen, keine Historisierungslogik, die für jede Quelle erneut getestet werden muss.
• Orchestrierung und CI kommen mit. Git und Gitflow-Unterstützung, Deployment- und Rollback-Skripte sowie Lineage sind Teil der Plattform, kein zweiter Stack, den Sie betreiben.
• Pattern Updates, Datenbank Updates und Support ebenfalls. Neue Datenbankfunktionen kommen als aktualisierte Lademusters an, mit den Migrationsskripten für bestehende Strukturen inklusive, und Support ist Teil der Lizenz statt ein Forum.
• Die Auslieferungsschicht ist ebenfalls modellgetrieben. Marts und Datenprodukte werden per Drag-and-Drop auf der semantischen Schicht zusammengestellt, mit Geschäftsregeln, die in der Plattform verwaltet und versioniert werden, sodass fachlich orientierte Personen entscheiden, welche Daten sie brauchen, ohne einen dbt-Entwickler dazwischen.
• dbt bleibt weiterhin optional nutzbar. Teams, die den Betrieb in dbt behalten wollen, bekommen die dbt-Modelle aus demselben Modell generiert. Der Prozess bleibt modellgetrieben, und eine Änderung ist ein Modell-Update und eine Neugenerierung, keine Handbearbeitung.
• Die Kosten sind vorhersehbar. Eine Serverlizenz in einer von drei Größen plus die Zahl der Entwickler, und nichts, was pro Lauf oder pro Load gemessen wird. Kein Orchestrierungs Cluster zu betreiben, und keine Rechnungsposition, die sich damit bewegt, wie oft die Modelle gebaut wurden.

Was zu entscheiden ist

Prüfen Sie das Projekt und zählen Sie die Modelle, die nur existieren, um eine Quelle zu stagen, zu deduplizieren, mit Keys zu versehen oder zu historisieren. Für genau diesen Anteil zahlen Sie doppelt: einmal für die Entwicklung und einmal für die tägliche Ausführung. Es ist der Teil, der einem Generator gehören sollte.