+50 XP

dbt (data build tool): industrialisierte SQL-Transformation

dbt (data build tool) ist zur Lingua franca der modernen Datentransformation geworden. Innerhalb von fünf Jahren wurde aus einem Open-Source-Experiment das Standardwerkzeug tausender Data Teams weltweit. dbt zu verstehen, was es tut, warum es funktioniert und wie man es strategisch einsetzt, ist für jeden CDO unverzichtbar, der eine moderne Datenplattform verantwortet.

Was dbt tatsächlich macht

dbt ist ein Transformationswerkzeug. Es sitzt im T von ELT: Nachdem die Daten in Ihr Warehouse geladen sind, transformiert dbt sie mit SQL.

Vor dbt wurden Transformationen typischerweise als Stored Procedures, eigene Python-Skripte oder eingebettet in ETL-Tools geschrieben. Diese Ansätze hatten gemeinsame Probleme: keine Versionskontrolle, keine Tests, keine Dokumentation, kein Lineage.

dbt löst all das in einem Tool:

  • SQL-native: Transformationen sind SQL-SELECT-Statements. Keine neue Sprache zu lernen.
  • Version control: dbt-Modelle sind Dateien in Git. Jede Änderung ist nachvollziehbar, reviewbar und reversibel.
  • Testing: Definieren Sie erwartete Datenqualitätseigenschaften in YAML. dbt prüft sie automatisch.
  • Dokumentation: Automatisch generiert aus den Spaltenbeschreibungen in der YAML-Konfiguration.
  • Lineage: dbt baut einen DAG aller Modellabhängigkeiten und liefert Ihnen damit automatisches Data Lineage.

dbt (data build tool) Tutorial for Beginners

Watch on YouTube

Wissenscheck

1. Wo arbeitet dbt im ELT-Paradigma?

2. Was ist der Hauptzweck der Funktion ref() in dbt?

3. Welche Materialization ist bei einem sehr großen Datensatz am geeignetsten, wenn vollständige Rebuilds unpraktikabel geworden sind?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Probleme der Transformationsansätze vor dbt (Stored Procedures, eigene Skripte, ETL-Tools), die dbt lösen sollte.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen, die Testing und Sources in dbt korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

dbt in der Praxis: die Kernkonzepte

Models: Ein dbt-Model ist eine SQL-Datei, die eine Transformation definiert. Der Dateiname wird zum Tabellen- oder View-Namen in Ihrem Warehouse. Sie schreiben SELECT-Statements; dbt übernimmt CREATE TABLE AS.

Refs: Models verweisen aufeinander über die Funktion ref() (z. B. FROM {{ ref('stg_customers') }}). Das erzeugt den Dependency Graph und erlaubt dbt, Models in der richtigen Reihenfolge auszuführen.

Tests: Zwei Arten: generische Tests (not_null, unique, accepted_values, relationships) und singuläre Tests (eigenes SQL, das null Zeilen zurückgeben sollte, wenn die Daten korrekt sind). Tests laufen nach jedem Build.

Sources: Externe Tabellen (nicht von dbt gebaut), die über die Funktion source() referenziert werden. dbt kann die Aktualität der Sources automatisch prüfen.

Materializations: Wie dbt das Ergebnis erzeugt. Table (vollständiger Rebuild), View (keine Daten gespeichert, die Query läuft beim Zugriff), Incremental (verarbeitet nur neue/geänderte Datensätze, entscheidend bei großen Datenmengen).

Das Incremental-Model-Pattern

Bei großen Datenmengen werden vollständige Refreshes unpraktikabel. Ein Incremental Model verarbeitet nur neue Datensätze:

Das Pattern: Filtern Sie die Quelle auf Datensätze, die neuer sind als der jüngste Datensatz in der Zieltabelle. Beim ersten Lauf wird alles verarbeitet. Bei den folgenden Läufen nur das Delta. Das senkt die Rechenkosten von O(Gesamtzeilen) auf O(neue Zeilen pro Lauf).

Incremental Models brauchen sorgfältiges Design: Wie behandeln Sie spät eintreffende Daten? Aktualisierte Datensätze? Löschungen? An diesen Edge Cases wird das Design von dbt Incremental Models komplex, und hier führen Fehler zu Datenqualitätsproblemen.

dbt im Maßstab organisieren

Ein ausgereiftes dbt-Projekt folgt einem Layer-Pattern:

  • Staging (stg_): Ein Model pro Quelltabelle. Minimale Transformation, Spalten umbenennen, Typen casten, Testdaten entfernen. Keine Business-Logik.
  • Intermediate (int_): Business-Logik wird angewendet. Joins, Aggregationen, abgeleitete Felder. Nicht direkt von BI-Tools konsumiert.
  • Marts (dim_, fct_, agg_): Dimensionale Modelle und Fact Tables. Das ist der Gold Layer, konsumiert von BI-Tools und Datennutzern.

Diese Organisation trennt die Zuständigkeiten: Staging behandelt quellspezifische Eigenheiten, Marts machen Business-Logik verfügbar, Intermediate verbindet beides.

Bei Gitlab (das sein komplettes dbt-Projekt als Open Source veröffentlicht hat) versteht dank dieser Struktur jeder Mitwirkende, wo er nach einer Transformation suchen muss, und Business-Logik sickert nicht in die Staging-Models.

Quizfragen

1. Was ist die wichtigste Neuerung von dbt gegenüber traditionellen SQL-Transformationen (Stored Procedures)?

A) dbt ist schneller

B) dbt ergänzt Version control, automatische Tests, Dokumentation und Data Lineage, also Software-Engineering-Praktiken angewendet auf SQL-Transformationen

C) dbt unterstützt mehr Datenbanken

D) dbt generiert das SQL automatisch

Antwort: B

2. Was ist eine "incremental" Materialization in dbt?

A) Ein Model, das nur eine Stichprobe der Daten verarbeitet

B) Ein Model, das die gesamte Tabelle bei jedem Lauf neu aufbaut

C) Ein Model, das nur die seit dem letzten Lauf neuen oder geänderten Datensätze verarbeitet

D) Ein Model, das automatisch jede Stunde ausgeführt wird

Antwort: C

3. Was enthält in der Organisation eines ausgereiften dbt-Projekts der Layer "Staging"?

A) Die von BI-Tools konsumierten Dimensions- und Fact Tables

B) Die komplexe Business-Logik und die Joins

C) Ein Model pro Quelltabelle mit minimaler Transformation, Umbenennung, Casting, ohne Business-Logik

D) Die Aggregationen für die Executive-Dashboards

Antwort: C

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • dbt einführen, um Version Control, Tests und Dokumentation in die Transformationen zu bringen
Vollständiges Action Playbook ansehen

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.