dbt – Qualitätssicherung im Datenumfeld: Teststrategien mit dem data build tool

Testen ist unerlässlich, um Vertrauen in die eigene Software zu schaffen und frühzeitig Probleme sowohl in der Datenqualität als auch in der Businesslogik zu erkennen. Was sich in der modernen Softwareentwicklung längst als Standard etabliert hat, ist im Umfeld von Data Warehouses und auch kleineren Datenanwendungen oft ein unbeliebtes Thema. Nicht zuletzt, weil gängige Datenwerkzeuge nur selten eigene Testfunktionalitäten bieten. dbt revolutioniert im Datenumfeld das Testen und bringt direkt mehrere Möglichkeiten out-of-the-box mit sich. In diesem Beitrag werfen wir einen Blick auf verschiedene Teststrategien. Wenn dbt für euch neu ist, werft zunächst einen Blick in den vorangegangenen Artikel. 

Warum überhaupt testen?

Daten gelten oft als Grundlage für kritische Entscheidungen. Im Versicherungs- und Bankenumfeld gibt es beispielsweise mit DORA (Digital Operational Resilience Act) regulatorische Anforderungen und Vorgaben, die regelmäßige Tests sowie deren Nachweis erfordern. Aber auch in anderen Bereichen ist eine saubere Datengrundlage unerlässlich. dbt ermöglicht es uns, Tests direkt in den Entwicklungsprozess zu integrieren, statt sie als nachträgliche Aufgabe zu betrachten. 

Die drei Teststrategien in dbt

dbt bietet im Wesentlichen drei verschiedene Testarten, die miteinander kombiniert werden können:

1. Generic Tests

Gelten als Standardtests und werden deklarativ für ein Datenbankobjekt in einer YAML-Datei definiert und sind wiederverwendbar.. Von Haus aus stehen hier unique-, not_null-, accepted_values- und relationships-Tests zur Verfügung.

2. Singular Tests

Kommen insbesondere für individuelle Businesslogik zum Einsatz. Einfache Spaltentransformierungen, aber auch komplexe Logiken können hiermit geprüft werden. Die Tests werden als SQL-Abfrage abgelegt. Wenn die Abfrage einen Datensatz zurückgibt, gilt der Test als fehlgeschlagen.

3. Unit Tests

Ab dbt 1.8 (Mai 2024) werden auch Unit Tests unterstützt. Diese erlauben es, Mock-Daten zu definieren. Die Transformationen werden anschließend mit diesen Daten ausgeführt und das Ergebnis mit dem erwarteten Output verglichen.

Fallbeispiele – Deep Dive in die Teststrategien

Deep Dive Generic Tests

Anhand des dbt-Standardbeispiels jaffle-shop zeigen wir die Teststrategien im Einsatz. Abbildung 1 zeigt das Model stg_order.sql und Abbildung 2 die zugehörige Konfiguration in stg_order.yml. Durch ein paar Zeilen Konfiguration werden hier drei verschiedene Tests erstellt:

1. Unique Test auf Spalte order_id
2. Not Null Tests auf Spalte order_id
3. Accepted Values Tests für die Spalte status

Neben den vordefinierten Tests bietet dbt auch die Möglichkeit, eigene Generic Tests zu schreiben und diesen in jeder Konfiguration wiederzuverwenden. Ermöglicht werden diese Funktionen durch die Templatesprache Jinja, mit der selbstgeschriebene Tests auch parametrisiert werden können. Neben eigenen Generic Tests, lassen sich auch weitere Packages in eure dbt-Umgebung integrieren, die eine Vielzahl an weiteren vordefinierten Tests mitbringen, beispielsweise  „expression_is_true“ oder „expect_column_values_to_be_between“. 

Deep Dive Singular Tests

dbt nutzt für Transformationslogiken SQL. Mit dem gleichen Mittel lassen sich spezifische Tests abbilden. Abbildung 3 zeigt einen Singular Test, der prüft, ob die Summe einzelner Bezahlungen „< 0“ beträgt. Liefert die SQL-Abfrage eine Ergebnismenge zurück, gilt der Test als fehlgeschlagen.

Deep Dive Unit Test

Für einzelne Objekte lassen sich Mock-Daten generieren. Hier werden stg_customer-Beispieldaten für die Mailadresse sowie die customer_id und der erwartete Output definiert. dbt führt die Transformationslogiken mit den Mock-Daten aus und vergleicht diese mit dem erwarteten Output. 

Operationalisieren der Tests

Warnung oder Abbruch

Die möglichen Konfigurationen in den YAML-Dateien sind nahezu unbegrenzt. Für die Tests lassen sich beispielsweise Error- und Warnlevel festlegen, also ab wann Tests für einen Abbruch sorgen oder lediglich eine Warnung generieren sollen. Abbildung 5 zeigt eine solche Konfiguration. Darüber hinaus lässt sich auch die Datenmenge definieren, die getestet werden soll. Dadurch können auch große Tabellen performant getestet werden, indem nur neue Daten geprüft werden und historische Daten ignoriert werden, da diese bereits in der Vergangenheit geprüft wurden. 

Ausführung mit #dbt test

Mit dbt test werden Tests ausgeführt. Dabei lässt sich einfach festlegen, welche Objekte geprüft werden sollen. Durch einen gezielten Start des Kommandos in eurem Scheduler steuert ihr den Ausführungszeitpunkt. Dabei kann der Ausführungszeitpunkt auch einfach mit einem Pull-Request gekoppelt werden, um sicherzustellen, dass nur sauber getestete Artefakte in die nächste Umgebung gelangen. 

Dokumentation

Ein weiteres Feature von dbt ist die automatische Erzeugung einer umfassende Dokumentation eures Datenprojektes. Darunter zählen auch vorhandene und konfigurierte Tests eurer Objekte. Damit können nicht nur die Entwickler:innen auf einen Blick die vorhandenen Tests einsehen, sondern auch Stakeholder, Prüfer:innen oder Fachanwender:innen. Mehr dazu in einem unserer folgenden Blogbeiträge zu dbt. Folgt uns gerne auf LinkedIn, um informiert zu bleiben.

Zusammenfassung

dbt bringt bereits mehrere Ansätze out-of-the-box mit, um Tests praxisnah, entwicklerfreundlich und einfach umzusetzen. Externe Testframeworks, in denen Tests oft umständlich nachkonfiguriert werden müssen, sind nun nicht mehr zwingend notwendig.

Die drei grundlegenden Teststrategien in der Übersicht:

Für saubere Daten in eurem Warehouse empfiehlt sich immer, eine Mischung der Teststrategien zu verwenden. Das schafft Vertrauen bei den Stakeholdern und schont die Nerven der Entwickler:innen.

Wie sieht eure Teststrategie aus? Nutzt ihr bereits die neuen Unit Tests oder setzt ihr auf externe Frameworks? Wir freuen uns auf den Austausch mit euch.

Seminarempfehlung