Moderne Datentransformation: von Stored Procedures zu dbt

Viele Unternehmen setzen noch immer auf komplexe Stored Procedures zur Datentransformation, so auch in unserem Fall. In unserer Datenlösung haben wir im Rahmen eines Studienprojekts eine bestehende DWH-Beladung von Stored Procedures nach dbt migriert.

​Dieser Blogbeitrag beschreibt die Umsetzung der Migration, gibt eine Einführung in das Deployment über Azure DevOps und schließt mit einem persönlichen Rückblick auf unsere erste dbt-Erfahrung ab.

Die bisherige Datenbeladung war auf drei Layer aufgebaut und umfasste pro Layer etwa 80 Datenbankobjekte. Die Transformationslogik für Datentypen und insbesondere die SCD2-Historisierung wurde dabei vollständig über Stored Procedures gelöst.

Durch dbt lassen sich diese Transformationen heute transparenter, wartbarer und effizienter gestalten. Eine Einführung in dbt findet ihr hier.

Die Datentransformation erfolgte bislang über drei Ebenen: Staging, Core und Datamart.

In der Staging-Ebene werden Datentypen festgelegt und die Rohdatenquelle definiert. Für die Historisierung wird außerdem ein Hash Key erzeugt, ein künstlicher Identifikator, der sich ändert, sobald sich relevante Werte in einem Datensatz ändern und damit eine neue Version erzeugt. Die Core-Ebene bildet die eigentliche Historisierungslogik, im Datamart findet sich hauptsächlich die Unternehmenslogik.

Ähnlich wie in dbt wurde ein Template-Generator auf Basis von Stored Procedures implementiert, um die Verarbeitung von Daten nach dem SCD2-Prinzip zu automatisieren. Der Ansatz weist Parallelen zu dbt auf, das die Generierung von SQL-Code mithilfe von Templates und Jinja stark vorantreibt. Dadurch konnten wir wertvolle Einblicke in moderne Ansätze der Datenmodellierung und Automatisierung gewinnen, weshalb die Technologie für uns von besonderem Interesse war.

Das System funktionierte, brachte jedoch Herausforderungen mit sich: Stored Procedures sind schwieriger zu testen, kaum selbstdokumentierend und bei Änderungen schnell fehleranfällig. Wer neu ins Projekt kam, brauchte Zeit, um zu verstehen, was wo passiert und warum.

In dbt werden die drei bestehenden Ebenen um zwei weitere ergänzt, was sich direkt auf Transparenz und Wartbarkeit auswirkt.

Der Raw Layer bildet die Verbindung zur Datenquelle und trennt die Rohdaten sauber vom Rest der Pipeline. Die Staging-Ebene übernimmt wie bisher die Datentypumwandlung und die Erzeugung des Hash Keys, allerdings nun in SQL-Modellen, die versioniert, testbar und nachvollziehbar sind. Die neue Snapshot-Ebene ersetzt die manuelle Historisierungslogik aus der Core-Ebene: dbt verfolgt Änderungen an Datensätzen automatisch nach und speichert deren Zustände über die Zeit. Core und Datamart schließen die Pipeline wie gewohnt ab.

Der entscheidende Unterschied zur alten Welt ist nicht nur die zusätzliche Struktur, sondern dass jeder Schritt explizit, dokumentiert und automatisch testbar ist. Was früher implizit in Stored Procedures steckte, liegt jetzt offen da.

Für das Deployment und die Ausführung von dbt wird eine automatisierte Infrastruktur auf Basis von Azure DevOps verwendet. Die Deployments erfolgen getrennt für die Umgebungen dev, uat und prod, sodass Entwicklungen, Tests und produktive Prozesse voneinander isoliert bleiben.

Änderungen werden zunächst in einem Feature Branch entwickelt und anschließend in die jeweiligen Umgebungen (dev, uat, prod) übernommen. Dabei können Deployments entweder automatisiert über die tägliche Beladung oder gezielt über eine variable Pipeline erfolgen, um einzelne Modelle direkt zu testen. Nach erfolgreichen Tests in den jeweiligen Umgebungen werden die Änderungen schrittweise bis in die Produktivumgebung gemerged und deployed.

Die Ausführung erfolgt über einen Self-Hosted Agent, der auf einer virtuellen Maschine on-premise läuft. Der Agent stellt die Verbindung zwischen Azure DevOps und den Zielsystemen her und führt die dbt-Builds aus.

Die erzeugten Modelle werden anschließend direkt in die jeweilige SQL-Datenbank im Azure-Portal geschrieben. Zusätzlich können die Datenbanken vor der Verarbeitung automatisch skaliert und nach Abschluss wieder reduziert werden, um Ressourcen effizient zu nutzen.

Zur Absicherung des Deployments werden die Pipeline-Ausführungen überwacht. Bei Fehlern oder fehlgeschlagenen Ausführungen werden automatische Benachrichtigungen erzeugt.

Der Einstieg in dbt war leichter als erwartet. Ich hatte mit einer steilen Lernkurve gerechnet, stattdessen hatte ich nach kurzer Zeit meine ersten Modelle laufen. dbt ist im Kern überraschend simpel: Man schreibt SQL, das man sowieso beherrscht und dbt übernimmt den Rest.

Was mich am meisten überrascht hat, ist das Zusammenspiel aus allem: Eine Änderung wird gemacht, der nächste Lauf erledigt den Rest. Tests hängen direkt an den Daten und schlagen sofort Alarm, wenn etwas nicht stimmt. Dokumentation entsteht quasi nebenbei. Das klingt nach Komfort, aber in der Praxis bedeutet es, dass ich mich auf das konzentrieren kann, was wirklich zählt.

Wenn ich heute auf die Stored-Procedure-Ära zurückschaue, würde ich es definitiv nicht mehr tauschen wollen.

Während des Projekts hatte ich meinen ersten intensiveren Kontakt mit dbt. Der Einstieg war anfangs nicht ganz einfach, da sich die Arbeitsweise von klassischen SQL-Prozessen unterscheidet.

Besonders spannend fand ich jedoch das Deployment über Azure DevOps mit automatisierten Pipelines und Self-Hosted Agents. Vor allem das Exception Handling und die automatische Fehlerbehandlung haben mir gezeigt, wie strukturiert und modern Deployments im Data Engineering umgesetzt werden können.

Seminarempfehlung