dbt (data build tool) ist ein Open Source Command Line Tool, das primär das Testing, die Dokumentation sowie die Transformation von Daten im Data Warehouse unterstützt. Das Tool soll Data Teams die Arbeit mit Daten erleichtern, indem es einen konsistenten und standardisierten Ansatz für die Datentransformation und -analyse bietet. Mit dbt können Nutzer Datenmodelle mithilfe von SQL definieren und anhand dieser Modelle optimierten SQL-Code erzeugen, der gegen ein Data Warehouse ausgeführt werden kann. dbt Labs bietet zwei verschiedene Produkte an. dbt Core ist quelloffen (Open Source) und kann direkt über die Befehlszeile des Code-Editors initiiert werden. dbt Cloud baut auf der dbt-Core-Architektur auf, bietet jedoch zusätzlich ein eigenes User Interface und einige weitere Features wie In-App Job Scheduler, Monitoring von Workflows, Integrationen mit anderen Tools sowie eine integrierte Entwicklungsumgebung (IDE).

Viele Unternehmen scheitern an der Demokratisierung von Informationen bzw. Know-how im Unternehmen. Übertragen auf die Datenanlyse arbeiten Analysten häufig getrennt von anderen Daten-Disziplinen, was suboptimale Ergebnisse fördert. Das Wissen ist isoliert, was zu redundanten Codes oder Abfragen führt, die bereits von einem anderen Teammitglied geschrieben wurden. dbt setzt genau hier an, indem es den Transformationsprozess orchestriert und vereinheitlicht. So lassen sich mittels dbt unter anderem folgende Hürden in der Datenverarbeitung und Datentransformation umgehen:

Konsistenz:
Da dbt eine einheitliche Sprache für alle Transformationen verwendet, können Inkonsistenzen in der Datenverarbeitung vermieden werden. Alle Änderungen an der Datenverarbeitung sind in einer einzigen Codebase dokumentiert, wodurch eine einfache Überprüfung und Korrektur von Fehlern machbar wird.

Datenqualität:
Durch die Möglichkeit, die Datenqualität während der Datenverarbeitung zu überprüfen und zu validieren, kann dbt sicherstellen, dass die Daten korrekt sind und Vorgaben entsprechen. Dies kann dazu beitragen, Fehler in den Daten zu vermeiden, bevor sie in Downstream-Systeme gelangen.

Kollaboration:
Da dbt auf Git basiert, können Teammitglieder durch die Verwendung von Online Code Repositories wie Github unkompliziert Änderungen einreichen, überprüfen und genehmigen, um sicherzustellen, dass die Datentransformationen auf dem neuesten Stand sind. Bei der Nutzung der dbt Cloud stehen zusätzlich native Konnektoren mit anderen Tools wie Slack und Jira zur Verfügung, um Benachrichtigungen und Updates zu Jobs zu erhalten.

Dokumentation:
dbt erstellt automatisch eine Dokumentationen (Website) über dbt Docs für alle Daten-Pipelines und ermöglicht es Nutzern, die Dokumentation einfach über den Code zu aktualisieren. Die Dokumentation ist ein wichtiger Faktor für die Überprüfung und Wartung von Daten-Pipelines und trägt dazu bei, dass Know-how innerhalb eines Teams erhalten bleibt.

Die Hauptfunktion von dbt stellt das Kompilieren und Ausführen von SQL-Modellen dar. Jedes Modell besteht aus einem einzigen SQL-Statement, welches sich in Form von Views und Tabellen im Data Warehouse materialisieren lässt. Modelle werden dabei lokal mit einem Code-Editor bearbeitet und mithilfe des Command Line Interface (CLI) von dbt ausgeführt. dbt verfügt über einen breiten Funktionsumfang. Im Folgenden werden die Kernfunktionalitäten des Tools vorgestellt, um das Konzept zu beschreiben.

Ein in dbt geschriebener Code lässt sich mit einem Git Repository verbinden und somit zur Versionskontrolle des Codes nutzen. Dies ermöglicht es, mit mehreren Entwicklern und Analysten gleichzeitig an einem einzigen Projekt zu arbeiten, ohne dass Versionen überschrieben werden. Dabei ist jeder Entwickler in einer eigenen Branch tätig, die eine Kopie des Projekts und des Projektverlaufs darstellt.

Änderungen werden erst dann in der Main Branch des Repository zusammengeführt, wenn sie validiert wurden. Somit werden alle Änderungen eines Codes im dbt-Projekt dokumentiert und sind chronologisch einsehbar.

Im Code-Editor werden Änderungen farblich hinterlegt und als Konflikt ausgewiesen, um Abweichungen zum Code aus der Main Branch ersichtlich zu machen. Anpassungen im Code müssen vor der Übertragung in die Main Branch mit einem Kommentar deklariert werden. Mit Git können Entwickler so die gesamten Änderungen im Projektverlauf an einem Ort einsehen. Dies ermöglicht eine effektivere Zusammenarbeit von Entwicklern und Analysten und stellt sicher, dass alle Modelle und Abfragen stets auf dem neuesten Stand sind.

Bei der Erstellung eines Modells und des zugehörigen Schemas lassen sich in der spezifischen yml-Datei Deklarationen und weiterer Kontext zum Code hinzufügen. YAML eignet sich als Sprache hervorragend für die Speicherung von Konfigurationsprofilen und ist in Aufbau und Funktion an die Datenstruktur von Python angelehnt. Die yml-Dateien werden bei der Installation von dbt und den Community Packages größtenteils vorgefertigt abgelegt und müssen demnach nur noch leicht an das eigene Projekt angepasst werden.

Eine gute Dokumentation der verwendeten dbt-Modelle hilft dabei, allen Stakeholdern einen schnellen Überblick über Aktualisierungen im Transformationsprozess zu gewähren oder den Einstieg in ein laufendes Projekt zu vereinfachen, falls z. B. ein neuer Entwickler das Projekt übernimmt. dbt bietet zusätzlich die Möglichkeit, eine Dokumentation für das dbt-Projekt zu erstellen und diese als Website darzustellen, die von anderen einsehbar und nutzbar ist.

Die Dokumentationsseite (dbt Docs) für ein spezifisches Projekt lässt sich mit wenigen Befehlen über das Command Line Interface (CLI) erstellen. Im ersten Schritt wird dbt über den Befehl dbt docs generate angewiesen, relevante Informationen über das Projekt und das damit verbundene Data Warehouse in den Dateien manifest.json bzw. catalog.json zusammenzustellen. Anschließend startet der Befehl dbt docs serve einen Webserver (Port 8080), um die Dokumentation über die .json-Dateien lokal im Browser darzustellen.

dbt Docs extrahiert die Metadaten und Beziehungen zwischen den verschiedenen Tabellen und fasst sie in einer klaren Übersicht zusammen. Es dient als zentrale Anlaufstelle für alle Teammitglieder, um die Dokumentation der Daten-Pipeline sowie den Prozess der Datenanalyse und -transformation transparent und verständlich zu organisieren. Darüber hinaus können Metadaten, wie beispielsweise die Beschreibung von Spalten, Beziehungen (ref()) oder Modell-Definitionen, in dbt Docs hinterlegt werden. Dies erleichtert die Zusammenarbeit innerhalb eines Teams und stellt einen übereinstimmenden Kenntnisstand aller Beteiligten sicher. Weitere Vorteile gegenüber der Dokumentation im Code-Editor oder Git sind die einfache Navigation und die integrierte Suchfunktion, die einen schnellen Zugriff auf gewünschte Informationen ermöglichen. Dadurch können auch neue Teammitglieder rasch in die Daten-Pipeline eingearbeitet werden.

dbt nutzt sogenannte ref()-Funktionen, um unter anderem Beziehungen zwischen den einzelnen Modellen herzustellen. In dbt Docs werden diese Funktionen genutzt, um mithilfe des Lineage Graphs den Datenfluss durch das Datenmodell zu visualisieren.

Zu den wichtigsten Funktionen von Data Lineage gehört die Möglichkeit, Abhängigkeiten zwischen Datenquellen, Transformationen und Tabellen aufzuzeigen. Somit wird nachvollziehbar, wie sich die Daten von einer Quelle zur nächsten verändern und woher die Daten für jede Tabelle stammen. Durch die klare Sichtbarkeit des Datenflusses wird es zudem einfacher, Fehler in den Daten zu identifizieren und zu beheben. Darüber hinaus können Entwickler die Datenqualität mithilfe von automatisierten Tests überwachen und sicherstellen, dass die Datenmodelle konsistent und korrekt bleiben. Der Graph ermöglicht eine unkomplizierte Navigation durch das Datenmodell und erleichtert seine Wartung und die Umsetzung von Compliance-Anforderungen, da der Datenfluss transparent und nachvollziehbar dokumentiert wird. Zusammenfassend bietet Data Lineage eine wertvolle Funktion, um komplexe Pipelines im Datenmodell übersichtlich zu visualisieren und somit das Datenmanagement zu rationalisieren.

In dbt gibt es ein integriertes Test-Framework, mit welchem Datenmodelle auf Datenqualität und Genauigkeit getestet werden können. Durch die Verwendung von Tests kann die Konsistenz der Modelle gewährleistet und das Vertrauen in die Daten verbessert werden.

Um die Erstellung von Tests zu vereinfachen, wird die Templating-Sprache Jinja verwendet. Mit Jinja können Tests parametrisiert und somit leicht an sich ändernde Anforderungen angepasst werden. In dbt werden sie in einem separaten Verzeichnis namens „tests“ gespeichert. In diesem Verzeichnis können Entwickler verschiedene Arten von Tests selbst definieren (z.B. Row Count Tests oder Schema Tests) oder bereits vordefinierte generische Tests wie unique, not_null, accepted_values und relationships in dbt nutzen. Anschließend können diese auf spezifische Modelle angewendet werden. Die bereits erwähnte ref()-Funktion in dbt ist eng mit der Verwendung von Tests und Jinja verbunden. Sie dient dazu, eine Referenz auf die Quelldaten in einem Datenmodell zu definieren. Dadurch kann dbt automatisch Join-Keys und Daten-Typen generieren, wenn auf Quelldaten in einem Modell zugegriffen wird. Die ref()-Funktion kann auch verwendet werden, um die Ergebnisse von Datenmodellen mit den Ergebnissen der Quelldaten abzugleichen. So lässt sich beispielsweise überprüfen, ob gewisse Attribute wie eine Transaktions- oder User-ID einzigartig sind.

dbt bietet zudem verschiedene Mechanismen, um die Entstehung von redundantem Code zu verhindern. Macros sind einer davon. Bei Macros handelt es sich um wiederverwendbare, in Jinja geschriebene Funktionen, die innerhalb von Modellen oder anderen Macros aufgerufen werden können. Sie können genutzt werden, um komplexe Berechnungen oder Transformationen auf Daten durchzuführen, die in anderen Modellen oder Datenquellen referenziert werden. Durch die Verwendung von Macros können so komplexe Transformationen in einfachere, leichter verständliche und weniger wartungsintensive Einheiten aufgeteilt werden.

Snapshots in dbt ermöglichen es, historische Daten in einem Data Warehouse zu speichern und diese mit aktuellen Daten zu vergleichen. Dafür werden die Daten zu einem bestimmten Zeitpunkt in einem separaten Tabellenschema abgelegt und zu einem späteren Zeitpunkt mit den aktuellen Daten verglichen. Gerade bei der Verwendung und Analyse sogenannter Slowly Changing Dimensions (SCD) kann diese Funktion hilfreich sein. SCD beschreiben die Art und Weise, wie sich Daten im Laufe der Zeit verändern können. Durch einen Snapshot wird der Zustand einer Dimension zu einem bestimmten Zeitpunkt abgespeichert, was den Vergleich mit früheren Zuständen dieser Dimension erlaubt. Dadurch können beispielsweise Änderungen in den Daten im Laufe der Zeit verfolgt oder historische Analysen durchgeführt werden. Dies macht die sukzessive Änderung des Status eines Nutzers oder aber den Lieferstatus einer Bestellung nachvollziehbar. Mit der Snapshot-Funktion können auch inkrementell Schnappschüsse erstellt werden, die nur die Änderungen seit dem letzten Snapshot erfassen, um die Datenmenge zu reduzieren und die Ladezeiten zu verkürzen.

Die Abbildung zeigt den grundlegenden technischen Workflow von dbt als Bestandteil des Cloud-Ökosystems. Über Data Loader wie Fivetran, Segment oder Snowplow werden die Daten aus den relevanten Quellsystemen in ein Cloud Data Warehouse wie Google BigQuery, Snowflake, Microsoft Azure oder AWS Redshift geladen. Dort werden die Daten im Rohformat des Quellsystems entgegengenommen und in Form von Tabellen oder Views abgelegt. Ab dieser Stelle fungiert dbt als eine Art „Orchestration Layer”. Die in dbt definierten Modelle (SQL) werden auf die abgelegten Rohdaten im Data Warehouse ausgeführt, ohne dass dabei die Transformation direkt in der Datenquelle vorgenommen wird. Neben den bereits vorgestellten Git-Funktionalitäten wie Version Control können über die dbt Cloud zusätzlich Benachrichtigungen per E-Mail oder Slack eingerichtet werden, die darüber Auskunft geben, wenn ein ausgeführter Job erfolgreich ist, fehlschlägt oder abgebrochen wird, was die Resilienz des Datenmodells erhöht.

Seit Ende 2022 ist Dataform ein integrativer Bestandteil von Google BigQuery. Auf funktioneller Ebene bestehen kaum Unterschiede zu dbt (data build tool). Auch Dataform nutzt Git und verfügt somit über Funktionen wie Version Control und die Dokumentation von Modellen und Transformationen.

Ein wesentlicher Unterschied auf funktioneller Ebene ist allerdings, dass dbt auf einem eigenen Server betrieben werden kann, während Dataform in BigQuery integriert ist und somit die Google Cloud Platform (GCP) als Infrastruktur nutzt. Eine Spezialisierung und Fokussierung auf BigQuery in der Rohdatenanalyse ist also unabdingbar. Zudem nutzt Dataform eine JavaScript API, um interaktiv mit SQL-Modellen zu arbeiten, während dbt die Templating-Sprache Jinja verwendet, die der Syntax von Python ähnelt. Für dbt existiert eine große Open-Source-Gemeinschaft, die das Tool ständig weiterentwickelt und vorgefertigte Modelle für diverse Use Cases und Quellsysteme in Form von Packages zur Verfügung stellt. Dataform ist im Vergleich weniger stark verbreitet als dbt, weshalb die Anzahl an Packages für Dataform überschaubar ist. Wenn bereits mit der GCP-Plattform bzw. BigQuery gearbeitet wird, dann kann Dataform längerfristig eine bessere Integration bieten. Eine pauschale Aussage lässt sich jedoch nicht treffen und ist abhängig von der individuellen Ausgangslage des Unternehmens und den Kompetenzen im Data Team.