Home Datenintegration SQL und dbt: Die Zukunft der modernen Datentransformation

SQL und dbt: Die Zukunft der modernen Datentransformation

AI, BigQuery, Datenintegration
3. Dezember 2025
9 Min Lesezeit

Tobias Vogler

Der Artikel beschreibt die Datenverarbeitung in Unternehmen. Dabei werden sowohl die etablierte Technologie SQL (Structured Query Language) als auch das moderne Werkzeug dbt (Data Build Tool) zur Datenmodellierung beleuchtet. SQL als eine Sprache zur Abfrage von Datenbanken. dbt hingegen ist ein Werkzeug, das den Transformationsprozess von Daten in Data Warehouses optimiert, indem es Praktiken des Software-Engineerings auf die Datenanalyse anwendet.

Einleitung

Lasst mich euch eine Geschichte erzählen. Sie handelt von Unternehmen, die sich das Ziel gesetzt haben, ihren Daten wertvolle Erkenntnisse zu entlocken. Seit Jahrzehnten ist dies ein Kampf, dessen Situation verworren und herausfordernd, aber auch vielversprechend und spannend ist. Wir haben ein über die Zeit verödetes Brachland, auf dem Schlachten um eine ungewisse Zukunft toben, die über wichtige Ressourcenverteilungen und Machtgefüge entscheiden. Für diese Schlachten braucht es die erfahrensten Heerführer und die flexibelsten, lernwilligsten Kämpfer.

Die Schlacht in dieser Geschichte ist die um wertvolle Unternehmensdaten, die tief in historischen Datenplattformen verborgen sind. Dies ist darüber hinaus eine Hommage an einen der legendärsten Generäle, der unzählige ruhmreiche Siege errungen hat, sowie an seinen Novizen und rechte Hand: SQL und dbt.

Inhaltsverzeichnis

1. Warum ist SQL old but gold?
2. Welche Schwächen hat der legendäre Heerführer SQL?
3. Wer ist dieser junge Novize namens dbt?
4. Doch wie und wo passt dbt in diesen Kontext?
5. Architektur und prinzipielle Wirkweise von dbt
6. Was macht dbt zur idealen rechten Hand von SQL?
7. Wofür ist dbt eventuell nicht geeignet?
8. Fazit

1. Warum ist SQL old but gold?

SQL bzw. Relationale Datenbank Management Systeme (RDBMS) sind seit vielen Jahrzehnten auf dem Markt etabliert. Das heisst jedoch nicht, dass sie veraltet sind – ganz im Gegenteil.

Unserem weisen Heerführer haben sich über die Jahrzehnte unzählige Kritiker, Rivalen und Feinde entgegengestellt, die er alle überdauert hat. Dieser Artikel fasst die Kernbestandteile einer fundamentalen Arbeit von Google zusammen. In dieser wird erwähnt, dass SQL zunächst für „ausgedient” erklärt wurde, um im Verlauf der Jahre stärker zurückzukehren als je zuvor.

Dieses Phänomen ist allerdings nicht auf Google beschränkt, wie Michael Stonebraker (Turing-Award-Gewinner und Erschaffer von Postgres) und Andrew Pavlo in dieser Arbeit berichten, die auch als Vortrag verfügbar ist. Sie veranschaulichen, dass RDBMS und SQL aufstrebende Technologien, Prinzipien und Ideen adaptieren, wodurch sich das Produkt immer weiter verbessert. Man könnte also sagen, dass unser Heerführer von jedem Widersacher, den er besiegt, etwas lernt und dadurch immer erfahrener wird.

Was über die Jahrzehnte entstanden ist, sind Systeme, die kontinuierlich an Matura zugenommen und dadurch immense Weiterentwicklungen erfahren haben. Doch nicht nur die RDBMS haben sich weiterentwickelt, sondern auch ihre Lingua franca SQL hat sich kontinuierlich verbessert. So ist es beispielsweise in BigQuery möglich, semi-strukturierte Daten in Form von JSON nativ zu verarbeiten. Darüber hinaus können auch Machine-Learning-Workloads in BigQuery per SQL ausgedrückt werden. Mit deren Unterstützung können sogar unstrukturierte Daten unmittelbar in BigQuery verarbeitet werden. Als i-Tüpfelchen sind sogar exotische Workloads wie die Geodatenverarbeitung möglich – und das alles nativ per SQL. Deshalb bezeichnet Google BigQuery nicht mehr nur als Data Warehouse, sondern als „Autonome Daten- und AI-Plattform”.

Als Showcase für das breite Spektrum an Operationen, die mit SQL umgesetzt werden können, sei auf dieses spannende Projekt hingewiesen. Dabei wird der Spiele-Klassiker Tetris in SQL implementiert, um die Turing Completeness von SQL zu demonstrieren. Dies ist eine Spielerei, die die Welt nicht verändert. Sie verdeutlicht jedoch, dass SQL so flexibel ist, dass sich damit auch Operationen umsetzen lassen, für die es nie entworfen wurde. Man kann sich deshalb ausmalen, welche Möglichkeiten es in dem Kontext gibt, für den SQL wirklich entworfen wurde, nämlich die Transformation relationaler Daten. Ich würde sogar so weit gehen zu sagen, dass es keine Datentransformation gibt, die sich nicht in SQL ausdrücken lässt.

Neben den graduellen Fortschritten der Sprache über viele Jahre hinweg gibt es auch Entwicklungen, die fundamentale Veränderungen und Verbesserungen umgesetzt oder zumindest vorgeschlagen haben. Ein Beispiel hierfür ist die fundamentale Neugestaltung der SQL-Syntax mit Pipes, die bereits in Databricks und BigQuery zur Verfügung steht. Ein weiterer faszinierender Gedanke ist der Vorschlag dieser Arbeit. Er möchte mit der bis dato ewig währenden Tatsache aufräumen, dass das Ergebnis einer SQL-Abfrage zwingend eine einzelne Relation/Tabelle sein muss. Stattdessen kann ein ganzes Datenmodell als Ergebnis geliefert werden.

Beide Aspekte unterstreichen die kontinuierlichen Innovationsbestrebungen zur Verbesserung von SQL. Insgesamt können die Jahre, in denen sich SQL und RDBMS in der Industrie halten, somit nicht als Altersschwäche, sondern als kategorische Überlegenheit betrachtet werden.

2. Welche Schwächen hat der legendäre Heerführer SQL?

Datenaufbereitungsprojekte werden oftmals als grosser einmaliger Aufwand betrachtet, dem man Herr werden könnte, indem man genügend Aufwand in eine initiale Analyse- und Designphase investiert. Es gibt allerdings immer einige Aspekte, die vorab nicht bekannt sind oder nicht bedacht wurden, und Anforderungen ändern sich mit der Zeit. In der praktischen Umsetzung hinkt dieser Ansatz daher in der Regel einem iterativen Vorgehen hinterher. Diese Erkenntnis ist in anderen Softwareentwicklungsprojekten Konsens, allerdings eben nicht immer in analytischen Anwendungsfällen. Dies spiegelt sich auch im Tooling für die SQL-basierte Entwicklung wider. Dieses macht es oftmals schwer, etablierte Praktiken der Softwareentwicklung auf datenverarbeitende Prozesse anzuwenden. Hierzu zählen vor allem Praktiken aus DevOps (Version Control, Continous Integration & Deployment in Multi-Environments, Test-Automatisierung) und Softwareentwicklung (Separation of Concerns, Single Responsibility Principle, Wiederverwendung (DRY), Abstraktion & Kapselung)

Für SQL existiert zwar ein offizieller Standard, der das Ziel verfolgt, dass derselbe SQL-Code für unterschiedliche Plattformen kompatibel ist, allerdings wird dieser Standard von keinem Plattform-Anbieter 1:1 implementiert. Dadurch haben unterschiedliche Plattformen ihre eigenen Nuancen, wodurch unterschiedliche SQL-Dialekte entstehen. Somit ist nicht garantiert, dass dieselbe SQL-Abfrage auf unterschiedlichen Plattformen ausführbar ist.

Zudem sind manche Transformationen zwar an sich recht simpel in SQL auszudrücken, allerdings sind diese nur mit vielen repetitiven Schritten darstellbar. Man sagt auch, es ist viel „Boilerplate-Code” notwendig, d. h., es muss viel Code geschrieben werden, um geringfügige Funktionalitäten zu implementieren. Solche Sprach-Features bezeichnet man deshalb auch als verbos. Dieses Beispiel zeigt, wie verbos und repetitiv gängige Transformationen in SQL sein können:

Hierbei wird aus den Attributen „id” und „sku” einer Tabelle ein eindeutiger Hash-Key („supply_sk”) erzeugt. Neben der Verbosität ist dies zudem fehleranfällig und höchstwahrscheinlich über verschiedene Anwendungen hinweg inkonsistent. Stellen Sie sich beispielsweise vor, Sie möchten in einem Projekt an jeder Stelle, an der auf diese Art ein Surrogate-Key erzeugt wird, den angewandten Algorithmus ändern. Dies würde unnötig viele Ressourcen verschlingen.

3. Wer ist dieser junge Novize namens dbt?

Zur Klärung dieser Frage ist ein Exkurs zu Data Pipelines bzw. ETL- bzw. ELT-Prozessen erforderlich. Beide Begrifflichkeiten beschreiben einen ähnlichen Zweck, nämlich die folgende Situation zu bewältigen:

Die Datenmenge D im System S hat mindestens eines von zwei Problemen: Entweder ist D in seiner derzeitigen Form schwer bis gar nicht für einen bestimmten Zweck zu gebrauchen, d. h., man möchte die Struktur von D zu D‘ ändern. Oder D ist schlicht am falschen Ort bzw. im falschen System, d. h., man möchte S ändern. Oder eben beides. Oder kürzer: Das „Wie” (Struktur) oder das „Wo” (System) der Daten ist für einen bestimmten Use Case nicht geeignet.

Aus diesem Grund werden Daten aus einem System extrahiert (Extract = E), in ein anderes System geladen (Load = L) und ggf. transformiert/umstrukturiert (Transform = T). Je nachdem, wann die Transformation durchgeführt wird, entstehen die Akronyme ETL oder ELT. Diese Begriffe werden eher verwendet, wenn Daten tatsächlich von einem System in ein anderes überführt werden sollen. Was aber, wenn Quell- und Zielsystem dasselbe System sind oder gar keine Transformation durchgeführt wird?

Eine Generalisierung des ETL-Prozesses ist der Begriff Data Pipeline. Er beschreibt schlicht einen automatisierten Prozess, der Daten von einer Quelle in ein Ziel transferiert. Dabei ist die Transformation der Daten optional. Quelle und Ziel können auch dasselbe System sein. Ein weiterer Aspekt, der für gewöhnlich zur Differenzierung herangezogen wird, ist, dass ETL-Prozesse in der Regel batch-basiert sind, während Data Pipelines auch Real-Time bzw. Event-basiert arbeiten können.

4. Doch wie und wo passt dbt in diesen Kontext?

Kurz gesagt ist dbt ein Python-basiertes Open-Source-Tool für die Transformation von D zu D‘ innerhalb eines RDBMS mittels SQL. Doch wie genau funktioniert das?

Eine SQL-Abfrage ist lediglich eine Zeichenkette (String), die einer bestimmten Syntax folgen muss, damit ein spezifisches System (RDBMS) sie in konkrete Prozessierungsschritte übersetzen kann.

Dies trifft auch auf Websites zu. Ihnen liegt nämlich immer ein HTML-Dokument zugrunde und ein spezifisches System (Webbrowser) weiss, wie es dieses zu verarbeiten bzw. darzustellen hat. Die meisten Websites sind jedoch nicht statisch, sondern weisen dynamische Inhalte auf, wie z. B. spezifische Inhalte für den eingeloggten Benutzer, die sich während der Nutzung (zur Laufzeit) ändern bzw. aktualisieren können. Hierfür können sogenannte Templating Engines verwendet werden, die es ermöglichen, textbasierte Dokumentinhalte programmatisch zu generieren. Die am weitesten verbreitete Engine im Python-Kontext ist Jinja.

Dies ist die erste Besonderheit von dbt: dbt nutzt Jinja, um SQL-Abfragen dynamisch zur Laufzeit zu generieren. Um das obige Hash-Key-Beispiel nochmals aufzugreifen: Dies würde im dbt-Kontext auf Folgendes eingestampft werden:

Diese dynamischen Inhalte können beliebig komplex werden und reichen von einfachen Funktionalitäten bis hin zur Erzeugung ganzer Tabellen. Diese gekapselten Funktionalitäten können an verschiedenen Stellen wiederverwendet werden, um schädliche Code-Duplikate (Copy & Paste) zu vermeiden. Ein weiterer grosser Vorteil von dbt ist das umfangreiche Ökosystem mit zahlreichen, qualitativ hochwertigen Funktionalitäten, die Out-of-the-Box verfügbar sind und im dbt-package Hub gesammelt werden.

Eine weitere Kernfunktion von dbt nutzt die bereits angesprochene Eigenschaft, dass jede SQL-Abfrage zwar beliebig viele Relationen als Input haben kann, aber immer eine einzelne Relation als Output generiert. Dieser Output könnte dann wieder als Input für eine neue Abfrage dienen.

Hierdurch entsteht ein gerichteter azyklischer Graph (engl.: Directed Acyclic Graph, DAG), der den Datenfluss darstellt. Jeder Knoten in diesem Diagramm ist eine SQL-Abfrage. Im dbt-Jargon wird dies als dbt model bezeichnet.

Das Ergebnis eines jeden dbt models wird als Artefakt in der Datenbank dargestellt (im weiteren Sinne View oder Tabelle). dbt löst die Modell-Referenzen zur Laufzeit in konkrete Datenbank-Referenzen auf.

Der DAG legt auch die Ausführungsreihenfolge der SQL-Abfragen fest. Dabei werden voneinander unabhängige Abfragen parallel verarbeitet, um einen möglichst effizienten Datenfluss sicherzustellen. Somit übernimmt dbt auch die Workflow-Orchestrierung.

Allerdings gibt es in dbt nicht nur Modelle, die zu Datenbank-Artefakten werden, sondern auch andere Konzepte/Ressourcen. Im Folgenden erhalten Sie eine Übersicht zu allen möglichen Arten von dbt-Ressourcen. An dieser Stelle soll nur auf die zweitwichtigste eingegangen werden: dbt-tests. Eine grosse Herausforderung bei der Erstellung von Data Pipelines ist die Wahrung einer angemessenen Daten- und Prozessqualität. Eine der vielversprechendsten Massnahmen zur Qualitätssicherung in der Softwareentwicklung und verwandten Bereichen ist die Durchführung automatisierter Tests. Dies beinhaltet sowohl Tests bezüglich der implementierten Logiken (Code-Tests) als auch Datenqualitäts-Tests im Fall von Data Pipelines, bei denen die Daten selbst auf notwendige Eigenschaften überprüft werden. In dbt werden diese als native Funktionalitäten in Form von data_tests und unit_tests unterstützt. Diese Tests werden auf dbt models angewandt und nach diesen ausgeführt, sodass diese Überprüfungen bei jeder Pipeline-Ausführung durchgeführt werden. Dies führt zu einer deutlichen Verbesserung der Qualitätstransparenz und ermöglicht die Entwicklung stabilerer Lösungen, die sich für eine iterative, schnelllebige Entwicklung eignen. Aus diesem Grund sind die Tests in dbt als wesentliches Kernfeature zu betrachten (Tests als First-Class Citizens).

5. Architektur und prinzipielle Wirkweise von dbt

dbt-core legt den Umfang der mit dbt umsetzbaren Features und Konfigurationen fest. Dieser Bereich wird auch Authoring Layer genannt. Wenn dbt in Kombination mit einem bestimmten RDBMS verwendet werden soll, muss es dafür einen sogenannten dbt-adapter geben. Dieser definiert, wie eine bestimmte Funktionalität innerhalb des spezifischen Systems umgesetzt bzw. implementiert wird. Hier ist eine Auflistung verfügbarer Adapter zu finden. Dies soll eine möglichst plattformunabhängige Definition von SQL-basierten Data Pipelines ermöglichen. Wie bereits angesprochen, haben unterschiedliche Systeme verschiedene SQL-Dialekte, sodass ein dbt model möglicherweise nicht auf zwei unterschiedlichen Plattformen lauffähig ist. Um diesem Problem zu begegnen, gibt es in dbt den sogenannten Adapter-Dispatch. Damit können systemabhängige Definitionen zur Laufzeit dynamisch geändert werden. Hier ein Beispiel dazu:

Das „cents_to_dollars“-Makro kann, wie im obigen Beispiel-Screenshot dargestellt, einfach im dbt model genutzt werden. Wird der dbt-Workflow auf postgres, BigQuery oder MS Fabric ausgeführt, werden die spezifischen Implementierungen verwendet. Für alle anderen Adapter/Plattformen wird die default-Version verwendet.

6. Was macht dbt zur idealen rechten Hand von SQL?

Eine gute rechte Hand weiss um die Schwächen ihres Herren und gleicht diese möglichst aus. Im Verlauf der obigen Ausführungen sollte ein Bild davon gezeichnet worden sein, wie dbt die beschriebenen Schwächen von SQL eliminieren oder zumindest abschwächen kann.

dbt gibt SQL die Möglichkeit, die oben angesprochenen etablierten Praktiken aus DevOps und Softwareentwicklung auf SQL-basierte Datenverarbeitungsprozesse anzuwenden. Dadurch wird ein gänzlich neues Mass an Mautra erreicht. Darüber hinaus ermöglicht dbt die einfache Entwicklung wiederverwendbarer Komponenten, die verbose oder komplexe Logiken sowie plattformspezifische Sprachfeatures kapseln und diese dynamisch zur Laufzeit managen.

Im Folgenden finden Sie eine Auflistung der Kernfunktionen von dbt:

Dynamische SQL-Code-Generierung zur Laufzeit
Workflow-Orchestrierung (DAG)
Schaffung von Transparenz durch Management von Modell-Abhängigkeiten (Data Lineage)
Integrierte Qualitätssicherungs-Mechanismen (data- und unit-tests als First-Class Citizens)
Nutzung von etablierten Software-Engineering-Best-Practices
Plattform-Unabhängigkeit durch Adapter-Dispatch
Open Source als Grundlage für ein umfangreiches Ökosystem (z. B. dbt Package Hub) und eigene spezifische Erweiterungen

7. Wofür ist dbt eventuell nicht geeignet?

dbt in Kombination mit SQL ist zwar mächtig, allerdings ist es nur ein Werkzeug, angedacht für einen bestimmten Zweck.

„If all you have is a hammer, everything looks like a nail“ – Abraham Maslow

dbt ist grossartig für nicht-interaktive (asynchrone), batch-basierte, idempotente, SQL-basierte Datentransformationen. Für Use Cases, die nicht in diese Beschreibung passen, mag dbt zwar nach wie vor eine mögliche Lösung sein, allerdings bewegt man sich ausserhalb der Komfortzone von dbt und andere Tools könnten den Zweck vielleicht besser erfüllen. Wenn ein User beispielsweise eine Datentransformation per User-Interface konfigurieren/parametrisieren und anschliessend starten möchte und auf das Ergebnis wartet, dann sind hierfür andere Tools eventuell besser geeignet als dbt.

Eine weitere Schwäche von dbt ist, dass es SQL-Abfragen nur als Zeichenketten betrachtet und keine Möglichkeit zur Interpretation hat, um Fehler frühzeitig zu erkennen.

dbts treibendes Unternehmen, dbt Labs, hat dieses Manko erkannt und antwortet hierauf mit einem gänzlich neuen Produkt. Dieses ist zur Zeit der Verfassung dieses Artikels allerdings noch in der tiefen Beta-Phase.

8. Fazit

SQL und moderne Datenplattformen (RDBMS) sind das Ergebnis jahrzehntelanger Forschung und Entwicklung. Es sind an Matura kaum zu übertreffende Systeme.

dbt nutzt diese grossartigen Entwicklungen, setzt sie in den Kontext moderner Software-Entwicklungs-Best-Practices und behebt viele der Schwächen von SQL. Besonders hervorzuheben sind die umfangreichen Möglichkeiten zur Testautomatisierung mit integrierter Qualitätssicherung.

Diese Kombination ist ein Bollwerk, mit dem zukünftige Schlachten um wertvolle Unternehmensdaten deutlich siegreicher ausfallen sollten.