Tests & Auswahl
Version prüfen
CLI- und Adapterstand für Support und Reproduzierbarkeit erfassen.
dbt --version
Versionen nicht aus einem fremden Projekt übernehmen.
Tests & Auswahl
Auswahl ohne Build prüfen
Welche Knoten erreicht der Selektor?
dbt ls --select "+fct_orders"
Das Plus vor dem Namen nimmt Vorfahren dazu; Umfang vor Build prüfen.
Tests & Auswahl
Modell und Abhängigkeiten bauen
Ausgewählte Ressourcen im konfigurierten dev-Target verarbeiten.
dbt build --select "+fct_orders" --target dev
Kann Datenbankobjekte verändern. dev muss im Projekt tatsächlich definiert sein.
Tests & Auswahl
Tests gezielt ausführen
Vorhandene Tests für ein Modell prüfen.
dbt test --select fct_orders --target dev
Nicht definierte Geschäftsregeln werden dadurch nicht automatisch geprüft.
Tests & Auswahl
Vereinigung und Schnittmenge
Auswahlmengen unterscheiden.
dbt ls --select "tag:finance tag:daily"
dbt ls --select "tag:finance,tag:daily"
Leerzeichen vereinigt Mengen; Komma bildet die Schnittmenge. Shell-Quoting beibehalten.
Tests & Auswahl
Modellbezug ausdrücken
In einer dbt-Modelldatei statt hart codiertem Datenbanknamen.
SELECT order_id, amount
FROM {{ ref('stg_orders') }}
WHERE amount IS NOT NULL
ref wird von dbt kompiliert; das ist kein direkt ausführbares Warehouse-SQL.
Modellierung
Quelle referenzieren
Eine in YAML deklarierte Quelle im Modell verwenden.
SELECT order_id, amount
FROM {{ source('sales', 'orders') }}
source definiert keine Datenbankverbindung und lädt keine Rohdaten.
Arbeitsablauf
SQL kompilieren
Gerendertes SQL im Zielordner untersuchen.
dbt compile --select stg_orders --target dev
Kein Modell-Build, aber Makros können Datenbankabfragen auslösen; nicht als garantiert offline behandeln.
Tests & Auswahl
State-Auswahl vorprüfen
Geänderte Modelle und abhängige Knoten vor Slim CI auflisten.
dbt ls --select "state:modified+" --state ./artifacts/prod
Vergleichsmanifest separat aufbewahren; Auswahl ist kein Nachweis vollständiger Testabdeckung.
Tests & Auswahl
Abhängigkeiten bewusst auflösen
Befehlsargumente für einen CI-Aufbau mit separater Referenz planen.
dbt build --select "state:modified+" --defer --state ./artifacts/prod --target ci
Als eine Shell-Zeile ausführen. Deferral kann unselektierte Eltern im Referenzziel lesen; Rechte und Datenklasse prüfen.
Datenqualität
Pflichtfeld und Schlüssel testen
Zwei unterschiedliche Eigenschaften als Tests hinterlegen.
version: 2
models:
- name: stg_orders
columns:
- name: order_id
data_tests:
- not_null
- unique
Syntax und dbt-Version bestätigen. Datenbank-Constraints und ausgeführte Tests sind unterschiedliche Nachweise.
Modellierung
Materialisierung lokal wählen
Ein Modell als View konfigurieren.
{{ config(materialized='view') }}
SELECT order_id FROM {{ ref('stg_orders') }}
Kein universelles Performance-Rezept; Adapter, Rechte und Nutzung prüfen.
Modellierung
Inkrementellen Filter begrenzen
Ein einfaches Inkrementalmuster als Ausgangspunkt prüfen.
{{ config(materialized='incremental', unique_key='order_id') }}
SELECT order_id, updated_at, amount
FROM {{ ref('stg_orders') }}
{% if is_incremental() %}
WHERE updated_at >= (SELECT COALESCE(MAX(updated_at), '1900-01-01') FROM {{ this }})
{% endif %}
Keine allgemeine Lösch- oder Late-Arrival-Lösung. Adapterstrategie, Datentyp, Dubletten und rückdatierte Änderungen testen.
Betrieb & Fehlersuche
Artefakte einem Lauf zuordnen
Nachweise so ablegen, dass Code und Ergebnis zusammenpassen.
manifest.json → Projektgraph / Konfiguration
run_results.json → ausgeführte Knoten / Status
Commit + Umgebung + Lauf-ID + tatsächliche Version
run_results enthält nur die in diesem Aufruf behandelten Knoten; ein grüner Ausschnitt beweist nicht den gesamten Graphen.
Arbeitsablauf
Benannten Selektor definieren
Wiederkehrende Auswahl nachvollziehbar in selectors.yml ablegen.
selectors:
- name: finance_daily
definition:
intersection:
- method: tag
value: finance
- method: tag
value: daily
Mit dbt ls --selector finance_daily prüfen. Eine Änderung am Selektor kann den Prüfungsumfang verändern.
Tests & Auswahl
Generische Tests auflisten
Vor Ausführung den Umfang generischer Datentests lesen.
dbt ls --select "test_type:generic"
Singuläre Tests sind eine eigene Auswahl; beide Testarten im Prüfplan berücksichtigen.
Datenqualität
Erlaubte Werte testen
Einen vereinbarten Wertebereich prüfen.
version: 2
models:
- name: stg_orders
columns:
- name: status
data_tests:
- accepted_values:
arguments:
values: [OPEN, CLOSED]
Arguments-Syntax setzt eine unterstützte dbt-Version voraus. NULL mit not_null separat prüfen.
Datenqualität
Beziehung als Datentest prüfen
Nicht vorhandene Dimensionseinträge finden.
version: 2
models:
- name: fct_orders
columns:
- name: customer_id
data_tests:
- relationships:
arguments:
to: ref('dim_customer')
field: customer_id
Prüft nicht automatisch die Eindeutigkeit des Zielschlüssels oder Pflichtbelegung der Quelle; eigene Tests ergänzen.
Betrieb & Fehlersuche
Verbindungsdiagnose bewusst starten
Konfiguration und freigegebene Testverbindung prüfen.
dbt debug --target dev
Kann das Datenbanksystem kontaktieren; Protokolle vor Weitergabe auf sensible Angaben prüfen.
Arbeitsablauf
Seeds vor dem Laden finden
Vor einem Seed-Lauf betroffene statische Datensätze identifizieren.
dbt ls --resource-type seed
Das Auflisten lädt die CSV-Dateien nicht. Echtes Laden und spätere Nutzung brauchen einen eigenen Test.
