Vom SQL-Chaos zur Daten-Effizienz: Max’ Reise mit dbt

Max ist ein Data Engineer im Team für das Data Warehouse einer grossen Schweizer Versicherung. Jeden Tag kümmert er sich darum, wichtige Daten aus verschiedenen Quellen zu extrahieren, zu transformieren und für die Analyse bereitzustellen. Doch je mehr Code Max und seine Kollegen schreiben, desto komplexer werden seine täglichen Aufgaben.

Eines Morgens merkt Max, dass er für ein neues Projekt eine SQL-Abfrage benötigt, die er vor einigen Wochen erstellt hat. Ein kurzer Blick in den Code zeigt ihm, dass er sich nicht erinnern kann, wo er diese Abfrage abgelegt hat. «Warum gibt es nicht einfach eine zentrale Stelle für solche Informationen?», murmelt er genervt. Hinzu kommt, dass Max mehrere duplizierte SQL-Codes findet. Das kommt daher, dass mehrere Entwickler:innen ständig unabhängig voneinander ähnliche Abfragen schreiben, was den Code unübersichtlich macht und zu Fehlern führt.

Die Situation wird komplizierter, als Max versucht, seine Änderungen nachzuvollziehen. Ohne Versionskontrolle kann er frühere Versionen nicht vergleichen. Bei einem letzten Deployment hat ein Kollege versehentlich einen Fehler eingebaut. Max denkt an die mühselige Zeit, die er mit der Überprüfung der Daten verbracht hat – eine systematische Methode, um neue Daten und Code zu testen, hat Max’ Team bisher nicht gefunden.

Die Zusammenarbeit mit seinem Team gestaltet sich ebenfalls schwierig. Jeder hat seinen eigenen Ansatz, und die Dokumentation ist oft lückenhaft. «Ich wünschte, ich könnte einfach nachschlagen, wie die anderen das machen», denkt Max frustriert, während er versucht, den Code eines Kollegen zu verstehen.

Als er schliesslich versucht, die Abhängigkeiten zwischen den verschiedenen Modulen nachzuvollziehen, wird ihm klar: «Das ist alles zu kompliziert!» Er erkennt, dass es an der Zeit ist, über den Tellerrand hinauszusehen. Von seinem Kollegen Fredi, der als Software Engineer in einer anderen Abteilung arbeitet, hört er nie von derartigen Problemen.

Wie Data Teams dank dbt von Software Engineering Best Practices profitieren

Diese und ähnliche Probleme hat nicht nur Max, sondern auch viele andere Data Engineering Teams. dbt ist ein Werkzeug, welches eine Lösung für diese Probleme verspricht:

1. dbt ermöglicht Data Engineers, SQL-Code zu schreiben, um Daten in Warehouses effizient und nachhaltig zu bearbeiten.
2. dbt setzt dabei auf Best Practices aus der Softwareentwicklung, wie Modularisierung, Versionskontrolle und automatisierte Tests.
3. Datenmodelle können in kleinere, wiederverwendbare Teile gegliedert werden.
4. Mit integrierten Tests lässt sich die Datenqualität kontinuierlich überwachen.
5. Zudem bietet dbt die Möglichkeit, automatisch eine Dokumentation der Datenmodelle zu erstellen, was die Nachvollziehbarkeit und Zusammenarbeit im Team fördert.
6. dbt ist besonders nützlich, um Transformationen zu automatisieren und in bestehende CI/CD-Prozesse einzubinden, was es zu einem leistungsstarken Werkzeug für datengetriebene Unternehmen macht.

Doch wie funktioniert dbt nun genau? Die Abbildung visualisiert das Prinzip von dbt:

dbt wird zur Transformation von Daten innerhalb eines Data Warehouses verwendet. Der Workflow beginnt, nachdem die Rohdaten im Warehouse verfügbar sind. In einer lokalen Entwicklungsumgebung werden Transformationen mit dbt entwickelt. dbt wandelt diese Transformationen so um, dass sie im Data Warehouse ausgeführt werden können. Nach der Transformation stehen die Daten in verarbeiteter Form zur Verfügung und können von BI-Tools für Analysen und Berichte genutzt werden.

Max’ Erfolgsgeschichte und Herausforderungen mit dbt  

dbt in der Praxis: Licht- und Schattenseiten

Max konnte sein Team überzeugen dbt einzuführen. Von diesem Schritt hat er sich bedeutende Vorteile erhofft, aber wurde dbt diesen in der Praxis auch gerecht? Ein halbes Jahr nach der Einführung wagt Max einen ersten Rückblick. Er fasst seine Erfahrungen zu den Vorteilen, aber auch Herausforderungen bei der Nutzung von dbt im Folgenden zusammen. Starten wir mit den Vorteilen:

1. Lineage: Durch die Nutzung von dbt sind alle Abhängigkeiten innerhalb der Datenplattform einfach feststellbar und visualisierbar. Verweise auf andere Tabellen beispielsweise werden nicht hart-codiert, sondern als Referenz auf ein dbt Objekt beschrieben. Auf diese Weise kann dbt einen Graphen erstellen, in welchem es alle Objekte inklusive ihrer Abhängigkeiten untereinander darstellt. Will Max eine Änderung an einer Tabelle durchführen, ist so nun einfach ersichtlich, welche anderen Objekte davon abhängen und durch die Änderungen potenziell beeinflusst werden. Ein weiterer Vorteil der Lineage ist die Flexibilität beim Aktualisieren von Tabellen. Wird zum Beispiel Tabelle A für einen Report genutzt und soll dieser zu einem bestimmten Zeitpunkt den aktuellen neuesten Stand anzeigen, so kann dbt mit einer Aktion erkennen, von welchen anderen Tabellen diese Tabelle abhängt und alle gemeinsam updaten, sodass der Report zuverlässig die neuesten Daten berücksichtigt. 
2. Modularisierung und Wiederverwendbarkeit: In klassischen DWHs sind Datentransformationen oftmals von monolithischer Natur, beispielsweise in langen SQL-Skripten verwaltet und entsprechend schwer zu pflegen. dbt hingegen unterstützt die Modularisierung von wiederholt genutzten Funktionalitäten durch den Einsatz von Macros und Templates. Max war positiv überrascht, wie schnell seine Kolleg:innen Modularisierungen umgesetzt haben, da der Nutzen für sie intuitiv spürbar war. Das Resultat ist ein besser wartbarer und lesbarer Code. Gleichzeitig werden Fehlerquellen reduziert, da Funktionalitäten nicht an verschiedenen Stellen mehrfach umgesetzt werden müssen.
3. Datenqualität: Innerhalb von dbt kann man für alle seine Objekte Dokumentationen pflegen und sie mit Metadaten anreichern. Darüber hinaus bietet dbt eine Reihe von Datentests an, welche von einfachen Bedingungen (not null / unique) bis hin zu komplexeren Zusammenhängen reichen. Speziellere Tests können auch selbst definiert werden. Kurzum, alles, was als SQL Query darstellbar ist, kann auch als Datentest benutzt werden. Max’ Team hat schrittweise mit der Dokumentation und ersten generischen Tests begonnen. dbt unterstützt das Team dabei, indem es sicherstellt, dass die Qualitätsstandards im Entwicklungsprozess gelebt werden. Das Team definiert dazu Mindestanforderungen, die dbt beispielsweise in CI-Pipelines automatisch überprüft und durchsetzt.

Neben den genannten Vorteilen hat Max auch Herausforderungen bei der Einführung von dbt beobachtet.

1. Skillset: In erster Linie werden Datentransformationen in dbt in SQL beschrieben, wodurch die Einstiegshürden für Max und seine Kolleg:innen gering waren. Das Nutzen von dbt erfordert darüber hinaus jedoch ein erweitertes technisches Skillset. In der dbt Community hat sich der Begriff des ‚Analytics Engineer‘ gebildet, der beschreibt, dass man nun auch verstärkt Know-how im Bereich Versionskontrolle (git und Einsatz eines git flow), sowie CI/CD Pipelines benötigt. Hier musste Max’ Team Know-how aufbauen, konnte aber auch von einem Wissenstransfer innerhalb der Organisation und von Fredi profitieren, da vieles davon bereits in Software Engineering Teams etabliert war.
2. dbt verzeiht keine Abkürzungen: Wenn das dbt-Projekt während der Entwicklung eines neuen Features in einem unsauberen Zustand ist, beispielsweise weil eine Abhängigkeit zu einer anderen Tabelle noch nicht definiert ist oder man eine zyklische Abhängigkeit eingebaut hat, dann verweigert ddbtbt das Kompilieren des Projekts. Dadurch können eine Vielzahl von dbt-Befehlen nicht ausgeführt werden, bis das zugrundeliegende Problem korrigiert ist. Für die Entwickler:innen mag dies im ersten Moment mühsam sein, dies sorgt aber gleichzeitig dafür, dass die Qualität hochgehalten wird.

Zusammenfassend findet Max, dass die Herausforderungen zwar nicht zu vernachlässigen sind, jedoch teilweise eine logische Konsequenz aus gewissen Vorteilen sind, die dbt in einem Datenprojekt mit sich bringt. 

Mit Unit Tests zu robusterer Datenqualität: dbt setzt neue Standards

Max freut sich über die Vorteile der Nutzung von dbt und erzählt auch seinem Kollegen Fredi, dem Software Engineer, stolz, welche Fortschritte sie durch Versionierung und Testing erreicht haben. In dem Gespräch wird auch das Thema Unit Tests angesprochen, von denen Max bisher noch nichts gehört hatte. Er recherchiert und findet heraus, dass seit kurzem auch diese Art Tests mit dbt möglich sind. Ziel von Unit Tests ist es, mögliche Probleme früh im Entwicklungsprozess zu erkennen und zu beheben. Hierzu werden kleine Bausteine der Datentransformationen isoliert getestet, damit zum Beispiel die Erweiterung eines bestehenden SQL-Skripts nicht dazu führt, dass ein Fehler in einer bestehenden Funktionalität eingeführt wird. 
dbt ermöglicht dieses Risiko zu reduzieren. Die Unit Tests und die dafür notwendigen Input- und Output-Daten werden direkt im dbt-Projekt definiert (entweder inline in den Metadaten oder als separate CSV-Dateien). Sie sind damit ebenfalls unter Versionskontrolle und können lokal als auch im Rahmen von CI-Pipelines ausgeführt werden, bevor neue Objekte auf die Datenplattform deployed werden. Unit Tests mit dbt sind ein weiteres Beispiel dafür, wie dbt Software Engineering Best Practices zu Data Teams bringt.