Dokumentation und Transformation von Daten mit dbt Core in der Cloud

Mit dem Aufkommen von Cloud-Data-Warehouse-Lösungen wie Amazon Redshift, Microsoft Azure, Google BigQuery oder Snowflake hat sich die Art und Weise, wie Daten verarbeitet werden, stark verändert. Früher wurden ETL-Prozesse (Extract, Transform, Load) genutzt, um Daten aus verschiedenen Quellen zu extrahieren, zu bereinigen und in ein Data Warehouse zu laden. Diese Prozesse sind jedoch zeitaufwändig, ressourcenintensiv und führen oftmals zu einer Verlangsamung der Analyseprozesse. In diesem Zusammenhang haben sich Anbieter wie Fivetran oder Snowplow am Markt etabliert, die Daten aus Quellsystemen mit geringer Latenzzeit in das Cloud Data Warehouse laden können. Das Ergebnis sind stabile Data Pipelines, die den Fokus auf komplexe Transformationsprozesse im Data Warehouse zulassen. Bei zunehmender Größe des Data Teams werden Themen wie Dokumentation, Codequalität und Demokratisierung von Informationen im Transformationsprozess immer relevanter, da mehr Struktur und Abstimmung gefragt sind. Der organisatorische Aufwand steigt, um die Datenqualität zu sichern. Tools wie dbt (data build tool) gehen dieses Problem an, indem alle Transformationsprozesse über eine Schnittstelle orchestriert, gemanagt und vollzogen werden.

In diesem Blogbeitrag zeigen wir, welche Probleme dbt im Transformationsprozess und Management einer Modern Data Pipeline löst, welche Kernfunktionalitäten das Tool bietet und wann ein Einsatz sinnvoll ist.

1. Über dbt Labs

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).

1.1 Welche Probleme versucht dbt zu lösen?

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.

1.2 Kernfunktionalitäten des Tools

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.

1.2.1 Git Version Control

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.

Abbildung 1: Darstellung Version Control (vereinfacht)

Ä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.

Abbildung 2: Darstellung Version Control (Code-Editor)

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.

1.2.2 Dokumentation (dbt Docs)

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.

Abbildung 3: dbt-Modelle und yml-Datei (Code-Editor)

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.

Abbildung 4: Dokumentation der dbt-Modelle (dbt Docs)

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.

1.2.3 Data Lineage

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.

Abbildung 5: Lineage Graph (dbt Docs)

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.

1.2.4 Testing und Macros

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.

Abbildung 6: dbt-Test (Beispiel)

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.

Abbildung 7: dbt Macros (Beispiel)

1.2.5 Snapshots

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.

1.3 dbt Workflow

Abbildung 8: dbt Workflow

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.

2. Unterschiede zu Dataform

Abbildung 9: Dataform Workflow

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.

3. Fazit

Mit seiner Git-Anbindung bringt dbt bewährte Standards und Workflows aus dem Software-Engineering in die Welt der Datenanalyse und Datentransformation, indem der Code über das Command Line Interface (CLI) direkt aus dem Repository ausgeführt werden kann. Damit ist die Konzentration von Entwicklern und Analysten auf die Umsetzung der Business-Logik in der Datenmodellierung möglich. Der Fokus auf Kollaboration und Dokumentation fördert die Demokratisierung der Daten im Unternehmen und schafft Transparenz über Versionierung und Änderungen im Transformationsprozess. Durch die Erweiterung der SQL-Logik mit Jinja-Templating und Macros lässt sich der Code über mehrere Modelle hinweg recyclen, wodurch das Ausmaß an redundantem Code reduziert wird. Mithilfe integrierter Tests lassen sich Daten zudem gegen ein fest vordefiniertes Schema prüfen, um die gewünschte Datenqualität sicherzustellen. Gerade für größere Data Teams mit komplexen Transformationsprozessen bieten Tools wie dbt oder auch Dataform demnach einen signifikanten Mehrwert für das Data Management.

Dieser Beitrag steht Ihnen ebenfalls in hochwertiger Form eines Whitepapers als PDF zum Download zur Verfügung.

Zum Whitepaper