Lernleitfaden: Teil 10. Staging-Modelle dbt

Thema: Teil 10. Staging-Modelle in dbt

Schwierigkeitsgrad: Mittel

Geschätzte Lernzeit: 2,5–3 Stunden (Theorie ~1 Std., Praxis ~1,5 Std., Fallanalyse ~30 Min.)

Voraussetzungen: Sichere Beherrschung von SQL (SELECT, JOIN, CAST, COALESCE, CASE)

Grundlegendes Verständnis der dbt-Architektur (sources, models, ref, tests)

Vertrautheit mit den Prinzipien von ELT und der geschichteten Architektur von Datenmodellen (raw → staging → intermediate → marts)

Kenntnisse über Specification-Driven Development (SDD) und Schema Manifest

Minimale Erfahrung in der Arbeit mit einem dbt-Projekt (dbt run, dbt test)

Lernziele: Zulässige und unzulässige Operationen in der Staging-Schicht von dbt unterscheiden und die Grenze zwischen technischer Normalisierung und Geschäftslogik begründen.

Typumwandlung, Behandlung leerer Werte und Null-Semantik unter Berücksichtigung der Quellfakten und der Spezifikation korrekt anwenden.

dbt-Tests für Staging-Modelle entwerfen (not_null, unique, accepted_values, singular) und sie von den Prüffakten der Mart-Schicht abgrenzen.

Versteckte Geschäftslogik im Staging erkennen und Anforderungen für deren Auslagerung in die Spezifikation oder den Mart formulieren.

Entscheidungen zu PII, Schlüsseln und Vertragsdrift im Staging im SDD-Stil dokumentieren.

Überblick: Staging-Modelle in dbt sind die erste Schicht, in der unverarbeitete Rohdaten aus Quellen in stabile technische Modelle mit verständlicher Typisierung, konsistenter Benennung und expliziter Behandlung der Null-Semantik umgewandelt werden. Das Kapitel formuliert die Philosophie des Stagings: „Langweile ist hier nützlich". Staging sollte keine Produktfragen beantworten, den Grain des Datenmodells wählen, Kunden aggregieren oder die Vertragsdrift der Quelle verbergen. Seine Aufgabe ist es, die Daten so vorzubereiten, dass das SQL in der nachgelagerten Kette vorhersehbar ist und ein Reviewer die technische Normalisierung schnell vom Produktinhalt trennen kann. Der Abschnitt behandelt die Grenzen erlaubter und verbotener Handlungen, Muster der Typumwandlung (einschließlich der Behandlung leerer Zeichenketten vor CAST zu date), den grundlegenden Satz von dbt-Tests, Anforderungen an die Behandlung von PII, typische Fehler wie „Geschäftslogik im Staging verstecken" sowie Kontrollfragen und einen Qwen-Prompt, der dem Agent hilft, im Sinne des SDD mit dem Staging zu arbeiten.

Schlüsselbegriffe: Staging als technische Schicht: Staging ist die erste Transformationsschicht, in der die Daten beginnen, „die Sprache der Plattform zu sprechen". Hier entstehen stabile Spaltennamen, explizite Typen, die Behandlung leerer Werte und grundlegende Schlüssel, aber es werden keine Produktentscheidungen getroffen. Wenn ein Staging-Modell zu einem „kleinen Business-Datenmodell" wird, ist die Schicht zu schlau geworden.

Grenze erlaubter Handlungen: Im Staging sind erlaubt: Anpassung von Feldnamen an die Projektkonvention, Typumwandlung (date, integer, decimal), explizite Behandlung der Semantik leerer Werte und null, Erhalt der Quellschlüssel, Kennzeichnung von PII-Feldern (aber ohne grundloses Verbergen). Diese Operationen sind technisch, sie beantworten keine Fragen der Konsumenten.

Grenze unzulässiger Handlungen: Im Staging sind verboten: Kunden aggregieren, Risk-Scores berechnen, den endgültigen Grain des Datenmodells wählen, Zeilen „der Schönheit willen" löschen, die Vertragsdrift der Quelle verbergen. Jede solche Logik muss entweder explizit in der Spezifikation/dem Manifest festgehalten oder in die Zwischen-/Mart-Schicht ausgelagert werden.

Typumwandlung und Null-Semantik: Typisches Muster: try_cast(nullif(cast(revoked_at as varchar), '') as date) as revoked_at. Diese Zeile wandelt einen leeren Wert in null um, aber die Bedeutung „null in revoked_at = aktive Einwilligung" wird in der Spezifikation festgehalten und im Mart berücksichtigt. Eine technische Transformation wird immer von einem Produktkommentar begleitet.

dbt-Tests im Staging: Mindestsatz: not_null und unique für Quellschlüssel; not_null für obligatorische Beträge und Daten; accepted_values dort, wo die Domäne klein ist; singular-Tests für komplexe Einschränkungen. Staging-Tests fangen technische Probleme der Quelle ab, ersetzen aber nicht die Prüfung des Datenprodukts.

SDD und Dokumentation von Entscheidungen: Specification-Driven Development verlangt: festhalten, dass ein leerer Wert in raw vorkommt; erklären, warum er im Staging zu null wird; überprüfen, dass der Mart aktive und widerrufene Einwilligungen konsistent zählt. Eine technische Korrektur wird zu einer dokumentierten Entscheidung.

PII im Staging: PII-Felder bleiben im Staging nur dort sichtbar, wo dies zur Demonstration der Sicherheitsrichtlinie erforderlich ist. Sie „standardmäßig" zu verbergen ist ein Anti-Pattern: Es maskiert die Vertragsdrift und behindert die Verifikation.

Qwen-Prompt für Staging: Kanonischer Prompt an den Agenten: „Lies das Schema Manifest und die raw-Quellen. Erstelle oder überprüfe Staging-Modelle. Füge keine Business-Aggregationen hinzu. Erkläre für jede Typumwandlung den Quellfakt, auf dem sie basiert." Ein solcher Prompt fixiert die Grenze und verringert das Risiko „schlauer" Modelle.

SQL-Stil für den Agenten: Staging-Modelle sollten klein sein, sich von oben nach unten lesen lassen und ref() und source() dort verwenden, wo es angebracht ist. Wenn Staging schwer zu lesen ist, werden die Modelle in der nachgelagerten Kette noch schlechter.

Typischer Fehler: Risiko-Politik im Staging: Geschäftslogik im Staging zu verstecken, zum Beispiel: case when amount_rub > 100000 then 1 else 0 end as risk_event ist nur dann zulässig, wenn die Regel bereits in der Spezifikation oder im Quellmanifest festgehalten ist. Andernfalls erfindet der Agent eine Risiko-Politik, was gegen SDD verstößt.

Wichtige Daten: 2020: dbt Labs verankerte offiziell die Terminologie der Schichten staging → intermediate → marts in der Dokumentation, was die Standardisierung der Architekturen vereinfachte.

2021: Erscheinen von dbt-utils und Popularisierung der Makros tests/generic_tests, die das Schreiben von accepted_values- und singular-Tests vereinfachten.

2022: Aufkommen von dbt-meta-testing und Vertragstests, die die Kontrolle der Schema-Drift der Quelle gerade in der Staging-Schicht verstärkten.

2023: Einführung von dbt Contracts (Modellversionen) – Staging wurde zur ersten Verteidigungslinie gegen die Vertragsdrift der Quelle.

2024: Breite Verbreitung von SDD-Praktiken und Schema Manifest als obligatorisches Artefakt vor der Generierung von Staging-Modellen durch KI-Agenten.

Übungsaufgaben: Titel: Staging-Audit: Trenne Technisches von Produktbezogenem

Problem: Gegeben ist ein Staging-Modell stg_consents.sql. Modellkörper:

select
  user_id,
  cast(consented_at as date) as consented_at,
  try_cast(nullif(cast(revoked_at as varchar), '') as date) as revoked_at,
  case when revoked_at is null then 'active' else 'revoked' end as status,
  case when amount_rub > 100000 then 1 else 0 end as risk_event,
  count(*) over (partition by user_id) as consents_per_user
from {{ source('raw', 'consents') }}

Aufgabe:

1. Beschrifte jede Transformation: Umbenennung, Typumwandlung, Null-Behandlung, Geschäftslogik.
2. Gib für jede Zeile an, welche Quellfakten sie begründen.
3. Finde die Geschäftslogik, die keine explizite Spezifikation hat.
4. Schreibe das Modell so um, dass im Staging nur technische Transformationen übrig bleiben und die Produktlogik ausgelagert oder als spezifikationsbedürftig markiert wird.

Lösung: Schritt 1 – wir beschriften jede Transformation:

• cast(consented_at as date) – Typumwandlung (technisch, Fakt: Feld ist in raw ein String, Domäne ist Datum).
• try_cast(nullif(cast(revoked_at as varchar), '') as date) – Behandlung von null/leerer Zeichenkette (technisch, Fakt: in raw kommen leere Werte vor, die cast zu date brechen).
• case when revoked_at is null then 'active' else 'revoked' end as status – GESCHÄFTSLOGIK. Die Semantik von 'active' gehört in die Spezifikation, nicht ins Staging. Muss in den Mart ausgelagert oder im Schema Manifest festgehalten werden.
• case when amount_rub > 100000 then 1 else 0 end as risk_event – GESCHÄFTSLOGIK. Die Regel 100.000 ist eine Risiko-Politik, die im Staging nichts zu suchen hat. Sie hier zu verstecken ist ein typischer Fehler.
• count(*) over (partition by user_id) as consents_per_user – AGGREGATION. Im Staging verboten.
• user_id – Erhalt des Quellschlüssels (technisch, Fakt: Schlüssel existiert in raw und muss erhalten bleiben).

Schritt 2 – korrekte Version des Stagings:

select
  user_id,
  cast(consented_at as date) as consented_at,
  try_cast(nullif(cast(revoked_at as varchar), '') as date) as revoked_at,
  amount_rub
from {{ source('raw', 'consents') }}

Schritt 3 – Kommentare im Modell oder im Schema Manifest:

• revoked_at: „Leerer Wert in raw → null im Staging; die Semantik active/revoked wird gemäß Spezifikation S-001 im Mart bestimmt."
• amount_rub: „Feld bleibt unverändert, Geschäftsregeln (z. B. risk_event) werden gemäß Spezifikation im Mart berechnet."

Fazit: Das Modell ist „langweilig" und vorhersehbar geworden, die Geschäftslogik wurde dorthin ausgelagert, wo sie hingehört.

Schwierigkeit: mittel

Titel: Satz von dbt-Tests für Staging bei Einwilligungen

Problem: Die Quelle ist die Tabelle raw.consents mit den Feldern: user_id (string), consented_at (string, Format YYYY-MM-DD), revoked_at (string, kann leer sein), source_system (string, Domäne: 'web', 'mobile', 'partner_api'). Erstelle eine YAML-Datei schema.yml mit Tests für stg_consents. Begründe, warum genau diese Tests technisch und nicht produktbezogen sind.

Lösung: ```yaml version: 2

models:

• name: stg_consents

description: "Technische Normalisierung von Einwilligungen aus raw.consents. Die Semantik active/revoked wird gemäß Spezifikation S-001 im Mart bestimmt." columns:

• name: user_id

description: "Benutzer-ID aus der Quelle. Schlüssel des Staging-Modells." tests:

• not_null
• unique
• name: consented_at

description: "Datum der Einwilligungserteilung. Quelle: Zeichenkettenfeld, im Staging zu date umgewandelt." tests:

• not_null
• name: revoked_at

description: "Datum des Einwilligungswiderrufs. Leerer Wert in raw → null im Staging." tests:

• not_null

# Alternativ: not_null ist nur zulässig, wenn revoked_at vertraglich immer gefüllt ist; # andernfalls ersetzen durch einen singular-Test, der prüft, dass leere Werte in null umgewandelt wurden.

• name: source_system

description: "Quelle der Einwilligungserteilung." tests:

• accepted_values:

values: ['web', 'mobile', 'partner_api']

Begründung des technischen Charakters der Tests:
- not_null + unique auf user_id – dies ist eine Prüfung der Integrität des Quellschlüssels, keine produktbezogene Hypothese.
- not_null auf consented_at – fixiert den Vertrag, dass das Erteilungsdatum immer vorhanden ist.
- accepted_values auf source_system – fängt das Auftauchen eines neuen Kanals ab, der kein Onboarding durchlaufen hat, und signalisiert eine Vertragsdrift.
- Produktbezogene Tests (z. B. „kein Benutzer mit revoked_at nach consented_at", „keine zwei aktiven Einwilligungen desselben Typs") werden im Mart oder im tests/-Ordner mit singular-Tests für das Datenprodukt geschrieben.

Schwierigkeit: mittel

Titel: Behandlung des leeren revoked_at: vom Quellfakt zur dokumentierten Entscheidung

Problem: In raw.consents kommt das Feld revoked_at als Zeichenkette und enthält in 30 % der Zeilen eine leere Zeichenkette. Aktueller Code: cast(revoked_at as date) as revoked_at. Bei einer leeren Zeichenkette liefert dbt einen Fehler oder unerwartete Werte. Schreibe die Transformation um und bereite einen Kommentar für das Schema Manifest vor.

Lösung: Korrekte Transformation:

try_cast(nullif(cast(revoked_at as varchar), '') as date) as revoked_at

Logik:
1. cast(revoked_at as varchar) – normalisieren den Typ (für den Fall, dass die Quelle ihn anders liefert).
2. nullif(..., '') – wandeln die leere Zeichenkette in null um. Dies ist ein technischer Schritt, keine Produktentscheidung.
3. try_cast(... as date) – wandeln sicher zu date; wenn die Zeichenkette nicht parsbar ist, erhalten wir null.

Eintrag im Schema Manifest (Fragment):

fields:

• name: revoked_at

raw_type: string raw_semantics: "Datum des Einwilligungswiderrufs. In raw kommen leere Zeichenketten vor (~30 % der Zeilen), die bedeuten ‚Einwilligung nicht widerrufen'." staging_type: date staging_semantics: "Leere Zeichenkette aus raw wurde zu null umgewandelt. Die Semantik ‚null = aktive Einwilligung' ist in der Spezifikation S-001 verankert und im Mart umgesetzt." mart_usage: "mart.consent_status berechnet active/revoked nach der Regel: revoked_at is null → active, sonst → revoked."

Fazit: Die technische Korrektur (try_cast + nullif) wird Teil einer dokumentierten Entscheidung, die zwischen Staging, Spezifikation und Mart abgestimmt ist.

Schwierigkeit: mittel

Fallstudien:
Titel: Fall eines Fintech-Startups: „Risk-Score im Staging hat den Regulator-Bericht kaputtgemacht"

Szenario: Das Analyseteam eines Fintech-Startups setzte einen KI-Agenten ein, der auf Basis des Schema Manifest Staging-Modelle generierte. Der Agent erstellte stg_transactions, in der neben technischen Transformationen die Spalte risk_event erschien: case when amount_rub > 100000 then 1 else 0 end. Die Schwellenwertregel 100.000 war nicht in der Spezifikation festgehalten – der Agent „erfand" sie selbst, gestützt auf allgemeine Praktiken der AML-Compliance.

Herausforderung: Drei Monate später forderte der Regulator einen Bericht über verdächtige Vorgänge. Das Team stellte das Datenmodell mart.suspicious_transactions auf Basis von risk_event aus dem Staging zusammen und sandte es an den Regulator. Das interne Audit stellte fest, dass: (1) die Regel 100.000 nirgendwo dokumentiert war; (2) ein anderes Team (Compliance) parallel gemäß der aktuellen Version der Richtlinie einen Schwellenwert von 250.000 verwendete; (3) das Mart-Datenmodell um 12 % der Zeilen vom Regulator-Bericht des Compliance-Teams abwich. Es wurde erforderlich, die Architektur dringend zu überarbeiten und dem Regulator die Quelle der Regel zu erläutern.

Lösung: Das Team führte eine Retrospektive durch und unternahm folgende Schritte:
1. Entfernte risk_event aus stg_transactions und ließ nur technische Transformationen übrig: Typumwandlungen, Null-Behandlung, Umbenennung von Feldern.
2. Beschrieb die Regel risk_event im Schema Manifest mit Angabe der Quelle (Compliance-Policy v2.3, Schwellenwert 250.000) und einer Referenz auf das Regulator-Dokument.
3. Verlagerte die Logik in mart.suspicious_transactions, wo die Regel explizit, versionierbar und vom Produktverantwortlichen signierbar wurde.
4. Fügte einen dbt-Test im Mart hinzu: einen singular-Test, der prüft, dass alle Zeilen mit risk_event = 1 einen amount_rub >= 250000 aufweisen und das Feld policy_version = 'v2.3' ist.
5. Ergänzte den Prompt an den Agenten um eine explizite Einschränkung: „Füge keine Business-Aggregationen und Schwellenwerte im Staging hinzu. Wenn du siehst, dass eine Regel nicht im Schema Manifest festgehalten ist, markiere dies als TODO und generiere keine Spalte."

Ergebnis: Der Regulator-Bericht wurde innerhalb von 2 Tagen neu erstellt, die Abweichung zum Compliance-Team behoben. Das Team formalisierte die Regel: Staging trifft nur die im Kapitel aufgeführten Entscheidungen (Namen, Typen, null, Schlüssel, PII-Kennzeichnung). Geschäftslogik ist im Staging nur bei Vorhandensein einer Referenz auf die Spezifikation zulässig. Ein Quartal später wurde eine ähnliche Situation mit einem Schwellenwert von 1 Mio. vom Agenten bereits in der Generierungsphase abgefangen – er gab ein TODO statt einer Spalte aus, und das Team aktualisierte das Schema Manifest rechtzeitig.

Gewonnene Erkenntnisse:
Staging ist kein Ort für Schwellenwerte und Geschäftsklassifikationen: selbst ein „harmloses" case when erzeugt regulatorische Risiken.

Jede numerische Regel im Staging muss eine Referenz auf die Spezifikation oder das Quellmanifest haben; andernfalls ist es eine vom Agenten erfundene Politik.

Der Prompt an den Agenten muss Business-Aggregationen explizit verbieten und für jede ungewöhnliche Spalte eine Referenz auf die Spezifikation verlangen.

Die Dokumentation der Null-Semantik und der Schwellenwerte im Schema Manifest macht Audits und die Neuerstellung von Berichten kostengünstig.

Verwandte Konzepte:
Grenze erlaubter/unzulässiger Handlungen im Staging

SDD und Schema Manifest

Typischer Fehler: Risiko-Politik im Staging

Qwen-Prompt für Staging

Unterschied zwischen Staging-Tests und Prüffakten des Mart

Titel: Fall einer E-Commerce-Plattform: „PII im Staging verborgen, und das Debugging kaputtgemacht"

Szenario: Ein Data Engineer einer E-Commerce-Plattform beschloss, die Daten bereits im Staging „abzusichern" und maskierte PII-Felder (E-Mail, Telefon) direkt in stg_customers mit Hashes. Dies geschah „für alle Fälle", ohne Abstimmung mit dem Security-Team und ohne Eintrag im Schema Manifest. Ein halbes Jahr später konnte das Fraud-Analytics-Team einen Vorfall nicht reproduzieren: Für die Untersuchung war die ursprüngliche E-Mail nötig, aber im Staging war bereits nur der Hash gespeichert, und die Quelle raw.customers war rotiert und nicht mehr verfügbar.

Herausforderung: Das Fraud-Team konnte die Untersuchung des gemeldeten Vorfalls nicht durchführen, der Regulator (im Bereich der Anti-Fraud-Berichterstattung) verlangte eine Bestätigung, dass eine bestimmte E-Mail in einer verdächtigen Transaktion gesehen wurde. Die Verbindung „E-Mail → Benutzer → Transaktion" wiederherzustellen wurde unmöglich, ohne eine erneute Ausleitung aus der Quelle, die eine separate Genehmigung erforderte und 5 Werktage dauerte.

Lösung: Das Team führte ein Audit durch und legte neue Regeln fest:
1. PII bleibt im Staging standardmäßig sichtbar; die Maskierung erfolgt nur in der Mart-Schicht für bestimmte Konsumenten (z. B. für das Marketing-Datenmodell).
2. Im Schema Manifest wird für jedes PII-Feld die Sensitivitätsstufe (low/medium/high) und eine Referenz auf die Sicherheitsrichtlinie angegeben.
3. In stg_customers wurden die Spalten E-Mail und Telefon im ursprünglichen Zustand zurückgegeben, und die Maskierung wurde in mart.marketing_customers als View unter Anwendung des Makros mask_pii() umgesetzt.
4. Für das Fraud-Team wurde ein eigener mart.fraud_investigation erstellt, in dem PII im Klartext erhalten bleibt; der Zugriff wird auf Ebene der Warehouse-Grants geregelt, nicht auf Ebene der Transformation.

Ergebnis: Die Untersuchung des Vorfalls wurde 1 Tag nach dem Ausrollen der Änderungen abgeschlossen. Das Security-Team erhielt ein explizites Register der PII-Felder im Schema Manifest und konnte eine Zugriffsrichtlinie nach Schichten statt nach „Intuition" der Ingenieure aufbauen. Ein Quartal später wurde eine ähnliche Geschichte mit dem Telefon verhindert: Ein Junior-Analyst bat den Agenten, „Telefon im Staging zu maskieren" – der Agent lehnte mit Verweis auf die Richtlinie ab und schlug vor, einen separaten Mart zu erstellen.

Gewonnene Erkenntnisse:
PII im Staging muss sichtbar bleiben: Maskierung ist eine Produktentscheidung und gehört in die Mart-Schicht.

Das Verbergen von PII im Staging maskiert die Vertragsdrift der Quelle: Wenn ein Feld verschwindet oder sein Format ändert, bemerkt man dies zu spät.

Die Zugriffsrichtlinie auf PII muss auf Ebene von Grants und Rollen geregelt werden, nicht auf Ebene der Transformation im Staging.

Das Schema Manifest ist der obligatorische Ort, um festzuhalten, welche PII-Felder in der Quelle vorhanden sind und wo sie maskiert werden.

Verwandte Konzepte:
PII im Staging

Schema Manifest

Grenze erlaubter Handlungen (Kennzeichnung, aber kein Verbergen)

Dokumentation von Entscheidungen im SDD

Lerntipps:
Öffne vor dem Schreiben eines Staging-Modells das Schema Manifest und unterstreiche Felder, für die es keine Spezifikation gibt. Wenn es mehr als zwei sind – halte an und fordere die Spezifikation beim Produktverantwortlichen an.

Die Regel „langweiliges Staging": Wenn sich das Modell angenehm von oben nach unten ohne Verzweigungen und CASE lesen lässt – befindet es sich wahrscheinlich in der richtigen Schicht. Wenn du bei dir den Gedanken erwischst „hier braucht es einen Kommentar, um die Logik zu erklären" – gehört die Logik nicht ins Staging.

Wende immer das Muster try_cast(nullif(cast(... as varchar), '') as date) für Felder an, die in raw leer ankommen können. Das beseitigt 90 % der Fehler bei Typumwandlungen.

Gehe vor dem Commit eines Staging-Modells jede Zeile durch und beschrifte sie: „Umbenennung", „Typumwandlung", „Null-Behandlung", „Geschäftslogik". Wenn es für die letzte Kategorie keine Referenz auf die Spezifikation gibt – entferne die Zeile.

Verwende für den Qwen/KI-Agenten den kanonischen Prompt aus dem Kapitel als Vorlage und füge explizite Verbote hinzu: „Füge kein case when mit Schwellenwerten hinzu", „Berechne keine Fensterfunktionen außer technischen row_number".

dbt-Tests im Staging sollten technisch sein: not_null, unique, accepted_values. Produktbezogene Tests (z. B. „keine zwei aktiven Einwilligungen desselben Typs") gehören in den Mart.

Wenn PII verborgen werden muss – erstelle einen separaten Mart und fasse das Staging nicht an. Staging ist der Ort, an dem die Vertragsdrift sichtbar sein muss.

Führe periodisch (einmal pro Quartal) ein Audit des Stagings durch: Suche nach Zeilen mit Geschäftslogik, die keine Referenz auf die Spezifikation haben. Dies ist die zuverlässigste Methode, um zu verhindern, dass die Schicht „schlauer wird".

Vergleiche Staging und Mart nach dem Prinzip „Staging beantwortet die Frage ‚was kam aus der Quelle', der Mart beantwortet die Frage ‚was bedeutet das für das Geschäft'". Wenn das Staging beginnt, die zweite Frage zu beantworten – befindet es sich in der falschen Schicht.

Zusätzliche Ressourcen:
dbt-Dokumentation – staging models: https://docs.getdbt.com/best-practices/how-we-structure/1-staging – kanonische Beschreibung der Staging-Schicht von dbt Labs mit Beispielen und Anti-Patterns.

Dbt-utils (Tests und Makros): https://github.com/dbt-labs/dbt-utils – Sammlung von Makros für not_null, unique, accepted_values, expression_is_true und singular-Tests.

Dbt contracts (Modellversionierung): https://docs.getdbt.com/docs/collaborate/govern/model-contracts – Dokumentation zu Modellverträgen, die den Schutz vor Drift im Staging verstärken.

Buch „analytics engineering with dbt": https://www.amazon.com/Analytics-Engineering-dbt-Airflow-BigQuery/dp/1098142370 – Kapitel über Layering und die Grenze zwischen Staging/Marts.

How we structure our dbt projects (discourse): https://discourse.getdbt.com/t/how-we-structure-our-dbt-projects/355 – klassischer Artikel des dbt-Labs-Teams zur Struktur der Schichten.

Specification-driven development (sdd): https://martinfowler.com/articles/replaceThrowWithException.html – allgemeine Prinzipien des SDD, angepasst an Analytics in Artikeln der dbt-Community.

Qwen documentation (Prompt-Engineering): https://qwen.readthedocs.io/en/latest/ – Qwen-Dokumentation zur Erstellung effektiver Prompts für Analyse-Agenten.

Dbt-project-evaluator: https://github.com/dbt-labs/dbt-project-evaluator – automatische Tests der Projektstruktur, die Staging-Modelle mit unerwarteter Logik erkennen.

Zusammenfassung: Staging-Modelle in dbt sind eine technische Schicht, die Rohdaten in stabile, typisierte, dokumentierte Modelle umwandelt, ohne Produktentscheidungen zu treffen. Im Staging sind erlaubt: Anpassung von Namen und Typen, explizite Behandlung von null und leeren Werten, Erhalt der Quellschlüssel, Kennzeichnung von PII. Im Staging sind verboten: Aggregationen, Geschäftsfilter, Wahl des Grains des Datenmodells, Berechnung von Risk-Scores, Löschen von Zeilen „der Schönheit willen", Verbergen der Vertragsdrift. Das Schlüsselmuster – try_cast(nullif(cast(... as varchar), '') as date) – wandelt leere Zeichenketten sicher in null um, und die Bedeutung „null = aktive Einwilligung" wird in der Spezifikation festgehalten und im Mart umgesetzt. dbt-Tests im Staging haben technischen Charakter (not_null, unique, accepted_values, singular für komplexe Einschränkungen) und fangen Probleme der Quelle ab, ersetzen aber nicht die Prüfung des Datenprodukts. Die Hauptfalle besteht darin, Geschäftslogik im Staging zu verstecken: case when amount_rub > 100000 then 1 else 0 end as risk_event ist nur bei Vorhandensein einer Referenz auf die Spezifikation zulässig, andernfalls erfindet der Agent eine Politik. PII bleibt im Staging sichtbar; die Maskierung ist Aufgabe des Mart. Ein gutes Staging ist „langweilig": klein, liest sich von oben nach unten, verwendet ref()/source() und ist leicht zu reviewen. Wenn das Staging komplex wird, werden die Modelle in der nachgelagerten Kette noch schlechter; wenn das Staging verständlich ist, trennt der Reviewer die technische Normalisierung schnell vom Produktinhalt. Nach dem Durcharbeiten des Kapitels solltest du haben: Staging-Modelle für die wichtigsten Quellen, mit dbt-Tests abgedeckte Schlüssel, im Schema Manifest dokumentierte Entscheidungen zu null, sichtbar bleibende PII dort, wo dies zur Demonstration der Richtlinie erforderlich ist.