Thema: Teil 2. Warum Bankdaten Spezifikationen erfordern
Schwierigkeitsgrad: Mittelstufe
Geschätzte Lernzeit: 3-4 Stunden
Voraussetzungen: Grundlegende SQL-Kenntnisse (SELECT, JOIN, GROUP BY, Aggregatfunktionen)
Vertrautheit mit dem Konzept von Data Marts und einer Schichtenarchitektur (staging, intermediate, marts)
Erstes Verständnis von dbt (Modelle, Tests not_null/unique/accepted_values, Befehl dbt build)
Allgemeines Verständnis von personenbezogenen Daten (PII) und Grundsätzen der Bankanalytik
Lernziele: Erklären, warum im Bankbereich ein Datenfehler gefährlicher ist als ein Syntaxfehler und wie sich dies von Fehlern in Webanwendungen unterscheidet.
Die fünf Risikoklassen von Bankdaten aufzählen und für jede Klasse eine überprüfbare Regel formulieren (kein Schlagwort).
Die fünf Spezifikationsschichten in SDD Data (dbt-Tests, ODCS, ODPS, Modellspezifikation, Reviewer-Bericht) abgrenzen und erklären, was jede Schicht konkret prüft.
Eine „schlechte" Data-Mart-Spezifikation in eine „gute" umwandeln, indem Grain, PII-Richtlinie, Freshness-SLA, Pflichtfakten und Eigentümer hinzugefügt werden.
Abnahmekriterien für ein Mart-Modell so formulieren, dass die Arbeit eines Agenten oder Entwicklers auf formaler Grundlage abgelehnt werden kann.
Übersicht: Bankdaten sind ein Bereich, in dem „ungefähr richtig" besonders teuer zu stehen kommt: Ein Fehler im Kunden- oder Zahlungs-Mart kann wie eine gewöhnliche Tabelle mit grünen Tests aussehen, dabei aber für die Berichterstattung, das Risikomanagement oder den Kundenservice eine falsche Bedeutung tragen. Genau deshalb eignet sich der Bankkontext zum Erlernen von SDD Data (Specification-Driven Development for Data) – eines Ansatzes, bei dem jede Zusage eines Datenprodukts explizit aufgeschrieben, durch konkrete Regeln begrenzt und durch Nachweise belegt werden muss. Im Kapitel werden die fünf Risikoklassen (PII, Zahlungen, Einwilligungen, Kreditportfolio, Berichterstattung) behandelt, es wird erklärt, warum dbt-Tests allein nicht ausreichen, und ein mehrschichtiges Spezifikationsmodell eingeführt: Tests fangen Form und einen Teil der Fakten ab, ODCS hält den technischen Vertrag fest, ODPS beschreibt das Datenprodukt und den Konsumenten, die Modellspezifikation beschreibt Grain und Abnahmefakten, und der Reviewer-Bericht verknüpft die Änderung mit den Zusagen. Anhand eines konkreten Beispiels des Mart customer_360 wird der Unterschied zwischen einer „zuversichtlichen, aber leeren" schlechten Spezifikation und einer „engen, aber überprüfbaren" guten Spezifikation gezeigt. Die wichtigste praktische Fähigkeit des Kapitels ist die Gewohnheit, die Frage „Wie wird das nachgewiesen?" zu stellen und jede Aussage über Daten in einen Befehl, eine SQL-Abfrage, einen manuellen Reviewer-Schritt oder eine menschliche Bestätigung verwandeln zu können.
Schlüsselkonzepte: Sdd data: Specification-Driven Development for Data – ein Ansatz, bei dem die Entwicklung eines Datenprodukts mit einer expliziten Spezifikation beginnt: Was verspricht das Produkt, wer braucht es, welche Einschränkungen hat es (Grain, PII, Freshness) und wie werden diese Zusagen überprüft. In SDD Data muss ein Agent oder Entwickler nicht raten, was „korrekt" bedeutet – er erhält Kriterien, anhand derer seine Arbeit abgelehnt werden kann.
Die fünf Risikoklassen von Bankdaten: In der Lernbank werden fünf Risikoklassen unterschieden: (1) PII und direkte Identifikatoren, (2) Zahlungen und Risikosignale, (3) Datenzugriffseinwilligungen, (4) Kreditportfolio und Überfälligkeit, (5) Berichterstattung und Reproduzierbarkeit von Berechnungen. Jede Klasse erfordert nicht nur eine SQL-Lösung, sondern auch eine überprüfbare Regel – das Schlagwort „personenbezogene Daten nicht offenlegen" muss in eine konkrete Liste verbotener Spalten in der Mart-Schicht und in eine Reviewer-Prüfung verwandelt werden.
Grain Granularität: Die Detailebene einer Zeile in einem Mart, zum Beispiel „eine Zeile pro customer_id". Dies ist eine Zusage des Datenprodukts, die sich nicht automatisch aus dbt-Tests ableiten lässt – sie muss in der Spezifikation festgehalten werden. Eine Änderung des Grain bricht unbemerkt alle nachgelagerten Berichte; deshalb muss der Grain entweder festgelegt oder mit Bestätigung des Eigentümers explizit geändert werden.
Pii und direkte Identifikatoren: Personally Identifiable Information – Felder, anhand derer ein Kunde direkt oder indirekt identifiziert werden kann (E-Mail, Telefon, passport_number, Steuernummer usw.). Die PII-Richtlinie in SDD Data drückt sich durch konkrete Verbote aus, zum Beispiel: „models/marts/ enthält keine Spalten pii_email, phone, passport_number", und wird vom Reviewer vor dem Release geprüft, nicht durch allgemeine Floskeln zur „Einhaltung von Anforderungen".
Freshness Datenaktualität: SLA für die Aktualität der Daten in einem Mart, zum Beispiel „Daten nicht älter als 24 Stunden". Freshness muss in der Spezifikation als messbare Zusage festgehalten werden, sonst kann der Konsument nicht beurteilen, ob er dem Mart vertrauen kann. In dbt wird dies durch source freshness unterstützt, aber die Richtlinie selbst lebt weiterhin in der Spezifikation.
Vertragsdrift: Eine Situation, in der sich die Struktur oder Semantik eines Marts für den Konsumenten unbemerkt ändert: das Hinzufügen von product_code, die Änderung der Formel risk_flag, das Auftauchen einer neuen NULL-Ebene. Vertragsdrift wird nur durch den Vergleich der aktuellen Version mit der festgehaltenen Spezifikation (ODCS, ODPS, Modellspezifikation) erkannt.
Spezifikationsschichten in sdd data: Mehrschichtiger Schutz des Datenprodukts: (1) dbt-Tests – Form und ein Teil der Fakten, (2) ODCS – technischer Vertrag (Felder, Typen, Eigentümer), (3) ODPS – Beschreibung des Datenprodukts und seiner Konsumenten, (4) Modellspezifikation – Grain und Abnahmefakten, (5) Reviewer-Bericht – Verknüpfung der Änderung mit den Zusagen. Jede Schicht fängt das ab, was die anderen nicht sehen.
Odcs und odps: ODCS (Open Data Contract Standard) – ein Standard für den technischen Datenvertrag: Liste der Felder, Typen, Eigentümer, Einschränkungen. ODPS (Open Data Product Standard) – ein Standard zur Beschreibung des Datenprodukts: Wer ist der Konsument, welche Aufgabe löst das Produkt, welche SLAs und Abnahmekriterien hat es. Zusammen liefern sie sowohl die technische als auch die produktseitige Seite des Vertrags.
Abnahmefakten acceptance facts: Konkrete überprüfbare Aussagen über einen Mart, die erfüllt sein müssen: „customer_id unique/not_null", „total_balance_rub not_null", „risk_event_count_7d vorhanden", „Liste der verbotenen direkten PII taucht in der Mart-Schicht nicht auf". Dies ist die Brücke zwischen Spezifikation und Umsetzung – sie können in Tests automatisiert oder manuell geprüft werden.
Grüner dbt build vs. brauchbare Daten: Ein erfolgreicher Lauf von dbt build bedeutet nur, dass der Modellgraph ausgeführt wurde und die angegebenen Tests bestanden sind. Es beweist nicht, dass die richtige Granularität gewählt wurde, dass im Mart nicht Kunde und Konto vermischt werden, dass ein Lern-risk_flag nicht als produktives Scoring ausgegeben wird. Dies ist die Grenze des Werkzeugs, nicht sein Mangel.
Überprüfbare Regel statt Schlagwort: Die wichtigste Fähigkeit des Kapitels: Jede Aussage über Daten muss in einen Befehl, eine SQL-Abfrage, einen manuellen Reviewer-Schritt oder eine menschliche Bestätigung verwandelt werden. Das Schlagwort „Risiken berücksichtigen" ist für einen Agenten nutzlos; die Regel „mart_customer_360 enthält keine Spalten aus der Liste verbotener PII, geprüft vom Schema-Reviewer vor dem Release" ist nützlich.
Datenprodukt-Eigentümer: Die Person oder Rolle, die Änderungen am Mart-Vertrag abnimmt: Stimmt sie einem neuen Feld zu, ist sie bereit, die Konsequenzen einer Grain-Änderung zu tragen, an wen ist bei einem Freshness-Alarm zu schreiben? Ohne Eigentümer „hängt die Spezifikation in der Luft" und niemand stoppt die Drift.
Übungsaufgaben: Name: Verwandlung einer schlechten Spezifikation in eine überprüfbare
Problem: Gegeben ist eine schlechte Mart-Spezifikation: „Einen Kunden-Mart für Analysten erstellen. Nützliche Felder zu Konten und Transaktionen hinzufügen. Datenqualität prüfen". Schreiben Sie sie in das Format einer guten Spezifikation um (nach dem Vorbild customer_360): Geben Sie den Namen des Datenprodukts, den Konsumenten, den Namen des Mart, die Granularität, die PII-Richtlinie, die Aktualität, die Pflichtfakten an. Erklären Sie, welche Risiken jeder hinzugefügte Punkt abdeckt.
Lösung: Schritt 1. Name des Datenprodukts und Konsument. Ersetzen Sie „für Analysten" durch eine konkrete Rolle, zum Beispiel „Analysten des Kundenportfolios und der Kreditrisikoabteilung". Damit wird festgelegt, wer berechtigt ist, Änderungen zu verlangen. Schritt 2. Name des Mart. Ersetzen Sie „Kunden-Mart" durch mart_customer_360 und geben Sie die Schicht an (models/marts/). Schritt 3. Granularität. Fügen Sie „eine Zeile pro customer_id" hinzu – sonst lässt sich nicht sagen, was als Duplikat zählt. Schritt 4. PII. Fügen Sie „der Mart enthält keine direkten Identifikatoren: E-Mail, Telefon, passport_number, Steuernummer" hinzu. Damit wird das Risiko eines Datenlecks personenbezogener Daten geschlossen. Schritt 5. Aktualität. Fügen Sie „nicht älter als 24 Stunden" hinzu – sonst kann ein Bericht auf einem veralteten Snapshot basieren. Schritt 6. Pflichtfakten. Listen Sie auf: customer_id unique/not_null, total_balance_rub not_null, accounts_count >= 0, Prüfung der verbotenen PII-Spalten bestanden. Das ist die in überprüfbare Aussagen verwandelte „Datenqualität". Schritt 7. Eigentümer. Fügen Sie „Eigentümer: Team Kundenanalytik" hinzu – wer die Drift abnimmt. Jeder Punkt deckt eine der fünf Risikoklassen ab und verwandelt ein Schlagwort in ein Kriterium, mit dem die Arbeit abgelehnt werden kann.
Komplexität: beginner
Name: Formulierung überprüfbarer Regeln für drei Risiken
Problem: Nehmen Sie einen beliebigen Mart aus Ihrem dbt-Projekt (oder einen gedachten mart_customer_transactions). Schreiben Sie dafür drei Risiken auf: (1) Grain, (2) PII, (3) Vertragsdrift. Formulieren Sie für jedes Risiko keine Floskel, sondern eine überprüfbare Regel. Wenn sich die Regel nicht prüfen lässt – schreiben Sie sie so lange um, bis sie ein Befehl, ein SQL oder ein manueller Reviewer-Schritt ist.
Lösung: Beispiel für mart_customer_transactions: (1) Grain. Floskel: „eine Transaktion pro Zeile". Überprüfbare Regel: „SELECT COUNT() FROM (SELECT transaction_id FROM mart_customer_transactions GROUP BY transaction_id HAVING COUNT() > 1) muss 0 zurückgeben; der Reviewer prüft, dass transaction_id in der Schlüsselliste des Modells steht und als unique markiert ist". (2) PII. Floskel: „sicher". Überprüfbare Regel: „grep -E 'pii_email|phone|passport_number|card_pan' models/marts/mart_customer_transactions.sql muss ein leeres Ergebnis zurückgeben; der Reviewer führt vor dem Release das Skript list_pii_columns.sql aus und bestätigt, dass die Liste leer ist". (3) Vertragsdrift. Floskel: „Vertrag ist stabil". Überprüfbare Regel: „bei Änderung der schema.yml in models/marts/ muss der Agent den Bericht diff_spec.md mit der Liste der hinzugefügten/entfernten Spalten erzeugen und in den PR legen; der Produkteigentümer (Analyst des Kundenportfolios) hinterlässt vor dem Merge einen approve-Kommentar".
Komplexität: intermediate
Name: Analyse: Ein grüner dbt build beweist noch nicht die Korrektheit
Problem: Im Mart mart_customer_360 sind alle dbt-Tests grün: customer_id unique/not_null, total_balance_rub not_null, accepted_values für risk_flag. In den Mart ist jedoch versehentlich das Feld source_system geraten, und ein Teil der Zeilen wird nun nach (customer_id, source_system) aggregiert, das heißt der tatsächliche Grain ist jetzt „eine Zeile pro (customer_id, source_system)", obwohl die Spezifikation „eine Zeile pro customer_id" verspricht. Welche Tests würden dieses Problem übersehen und warum? Was muss in der Spezifikation ergänzt werden, um eine solche Drift frühzeitig zu erkennen?
Lösung: Schritt 1. Warum die dbt-Tests nicht anschlugen. Die Tests unique/not_null prüfen einzelne Spalten, nicht Kombinationen. Der Test unique auf customer_id bestünde auch dann, wenn die Tabelle zwei Zeilen mit derselben customer_id und unterschiedlichem source_system enthielte – er sähe Eindeutigkeit, wenn man naiv nach diesem Feld gruppiert (tatsächlich würde er fehlschlagen, aber das Problem ist, dass der Grain breiter ist als erwartet). Der Test accepted_values auf risk_flag hat überhaupt keinen Bezug zum Grain. dbt-Tests sehen also Form, aber nicht die Semantik des Grain. Schritt 2. Was in die Spezifikation gehört. Eine explizite Aussage: „Granularität = eine Zeile pro customer_id", „source_system gehört nicht zum Grain und darf im finalen Mart nicht vorhanden sein", „die Liste der zulässigen Spalten ist in ODCS festgehalten". Schritt 3. Welche Prüfungen das nach sich zieht. Ein benutzerdefinierter dbt-Test, der COUNT(DISTINCT customer_id) zählt und mit COUNT(*) vergleicht: Bei Ungleichheit schlägt der Test fehl. Manueller Reviewer-Schritt: Die Spaltenliste des Mart vor dem Merge mit dem ODCS-Vertrag abgleichen. Alarm an den Eigentümer: Wenn in diff_spec.md die Spalte source_system auftaucht, ist ein approve des Produkteigentümers erforderlich.
Komplexität: intermediate
Name: Wo die PII-Richtlinie festgehalten wird
Problem: Das Team diskutiert, wo die PII-Richtlinie für den Kunden-Mart am besten festgehalten wird: (a) im Team-Chat, (b) in einem SQL-Kommentar am Anfang des Modells, (c) in der Spezifikation (ODCS/ODPS/Modellspezifikation). Wählen Sie eine Variante und begründen Sie Ihre Wahl anhand der Idee einer überprüfbaren Regel. Zusätzlich: Schlagen Sie vor, wie die gewählte Variante in eine automatische Prüfung verwandelt werden kann.
Lösung: Schritt 1. Wahl der Variante. Die richtige Antwort ist (c) Spezifikation. Der Chat (a) ist ein Ort, an dem Vereinbarungen nach einer Woche vergessen und für neue Teammitglieder einschließlich des Agenten unsichtbar sind. Ein SQL-Kommentar (b) kommt näher, aber ein Kommentar ist Dokumentation ohne Eigentümer und ohne automatische Prüfung: Er kann versehentlich gelöscht werden, und niemand bemerkt es. Die Spezifikation (c) hält die Richtlinie als Verpflichtung fest: Sie hat einen Eigentümer, eine Version und wird mit dem realen Schema verglichen. Schritt 2. Automatisierung. (1) In ODCS werden erlaubte und verbotene Spalten aufgelistet. (2) Vor dem Release wird das Skript list_pii_columns.py ausgeführt, das die schema.yml in models/marts/ liest und mit der Liste der verbotenen Spalten vergleicht – bei einer Übereinstimmung wird der Release blockiert. (3) Im Reviewer-Bericht (review_report.md) wird festgehalten: „Liste der verbotenen PII abgeglichen, keine Übereinstimmungen" – so wird der manuelle Schritt zu einer reproduzierbaren Prüfung. Schritt 3. Bezug zum Prinzip des Kapitels. Jede Richtlinie muss in einen Befehl, ein SQL, einen manuellen Reviewer-Schritt oder eine menschliche Bestätigung verwandelt werden. Der Chat liefert keinen einzigen dieser vier Punkte.
Komplexität: intermediate
Name: Kontrollfragen zum Kapitel
Problem: Beantworten Sie ausführlich die drei Kontrollfragen aus der Quelle: (1) Warum beweist ein grüner dbt build nicht die Korrektheit eines Datenprodukts? (2) Welcher Defekt ist gefährlicher – ein SQL-Syntaxfehler oder eine unbemerkte Grain-Änderung? (3) Wo sollte die PII-Richtlinie am besten festgehalten werden – im Chat, in einem SQL-Kommentar oder in der Spezifikation?
Lösung: (1) dbt build beweist nur, dass der Modellgraph fehlerfrei ausgeführt wurde und die angegebenen Tests bestanden sind. Es prüft nicht, ob die Granularität der Zusage entspricht, ob überflüssige Spalten im Mart aufgetaucht sind, ob eine Vermischung von Entitäten (zum Beispiel Kunde und Konto) stattgefunden hat, ob ein Lern-Risikoflag als produktives Scoring ausgegeben wird. Dies ist die Grenze des Werkzeugs: Tests fangen Form und einen Teil der Fakten ab, aber nicht die Semantik des Produkts. (2) Eine unbemerkte Grain-Änderung ist gefährlicher. Ein SQL-Syntaxfehler bricht die Pipeline – er ist sofort sichtbar und blockiert den Release. Eine Grain-Änderung bricht nichts: Tests sind grün, der Bericht wird erstellt, aber die Zahlen werden falsch, und diese Falschheit verbreitet sich über alle nachgelagarten Marts und die reguläre Berichterstattung. Genau deshalb wird der Grain in der Spezifikation separat als Verpflichtung des Eigentümers festgehalten. (3) In der Spezifikation. Der Chat hat keine Version, keinen Eigentümer und keine automatische Prüfung. Ein SQL-Kommentar ist besser, geht aber leicht verloren und hat ebenfalls keinen Eigentümer. Die Spezifikation (ODCS/ODPS/Modellspezifikation) ist eine Verpflichtung mit Eigentümer, Version und der Möglichkeit, das Schema des Mart vor dem Release automatisch mit dem Vertrag abzugleichen.
Komplexität: beginner
Fallstudien: Name: Fall 1. Grain-Drift im Mart customer_360 der Lernbank
Szenario: Der Analyst des Kundenportfolios der Lernbank bat das Datenteam, in den Mart mart_customer_360 das Feld source_system aufzunehmen, damit nachvollzogen werden kann, aus welchem System der Kunde kam (Mobile Banking, Filiale, Partnerprogramm). Der Agent, der die Aufgabe erhielt, fügte die Spalte in SELECT hinzu, aktualisierte schema.yml, führte dbt build aus – alle Tests waren grün. Die Mart-Spezifikation war zuvor in allgemeiner Form geschrieben worden und erwähnte weder source_system noch eine Liste zulässiger Spalten.
Aufgabe: Nach einem Monat begann die Kreditrisikoabteilung sich zu beschweren, dass ihr Bericht zur Kundenbasis Daten doppelt zähle: Derselbe Kunde werde zweimal gezählt, weil er nun gleichzeitig aus zwei Systemen komme. Der Analyst brauchte einen Tag, um zu verstehen, dass sich der Grain des Mart faktisch von „eine Zeile pro customer_id" zu „eine Zeile pro (customer_id, source_system)" geändert hatte, obwohl dies niemand abgestimmt hatte. Es gab keine Syntaxfehler, die dbt-Tests waren weiterhin grün, aber die Berichterstattung war zusammengebrochen.
Lösung: Das Datenteam unternahm drei Schritte. (1) Stellte den Grain wieder her, indem source_system vorübergehend aus dem Mart entfernt und in die Zwischenschicht models/intermediate/ verschoben wurde. (2) Präzisierte die Spezifikation von mart_customer_360: schrieb explizit „Grain = eine Zeile pro customer_id", „die Liste zulässiger Spalten ist in ODCS festgelegt", „jede Spaltenergänzung erfordert einen Bericht diff_spec.md und die Freigabe des Produkteigentümers". (3) Fügte einen benutzerdefinierten dbt-Test hinzu, der COUNT(DISTINCT customer_id) und COUNT(*) im Mart vergleicht: Bei Abweichung schlägt der Test fehl. (4) Führte einen obligatorischen manuellen Reviewer-Schritt vor dem Merge ein: schema.yml des Mart mit dem ODCS-Vertrag abgleichen und den Link dem PR beifügen.
Ergebnis: Der Mart kehrte innerhalb eines Releases zum zugesagten Grain zurück. Der benutzerdefinierte Test und der manuelle Reviewer-Schritt hätten eine solche Drift grundsätzlich unmöglich gemacht, weil das Hinzufügen von source_system ohne explizite Entscheidung des Eigentümers bereits im Code Review blockiert worden wäre. Das Team bewertete den Vorfall als „heilsamen Schlag": Er zeigte, dass „grüner dbt build" nicht gleichbedeutend mit „Produkt ist nutzbar" ist, und beschleunigte die Einführung der mehrschichtigen Spezifikation in allen Marts des Projekts.
Gewonnene Erkenntnisse: Ein syntaktisch korrekter Mart mit grünen Tests kann semantisch kaputt sein – Form ist nicht gleich Bedeutung.
Grain ist eine Zusage, die sich nicht aus Tests ableiten lässt; sie muss explizit in der Spezifikation festgehalten und durch einen eigenen Test auf COUNT(DISTINCT) abgesichert werden.
Das Hinzufügen einer „harmlosen" Spalte in SELECT kann unbemerkt den Grain ändern und die gesamte nachgelagerte Berichterstattung zerstören.
Die Richtlinie „der Vertrag darf nicht ohne Eigentümer geändert werden" muss als obligatorischer Reviewer-Schritt ausgedrückt werden, nicht als Satz im Chat.
Verwandte Konzepte: Grain_Granularität
Vertragsdrift
Spezifikationsschichten_in_SDD_Data
Grüner_dbt_build_vs._brauchbare_Daten
Abnahmefakten_acceptance_facts
Name: Fall 2. PII-Leak über einen „sicheren" Transaktions-Mart
Szenario: Das Datenteam baute mart_customer_transactions – einen Transaktions-Mart für Antifraud-Analysten. Laut Spezifikation sollte der Mart nur Aggregate enthalten (Transaktionssumme über 7 Tage, Anzahl der Transaktionen, durchschnittlicher Bon) und keine direkten Identifikatoren. Der Agent erzeugte das Modell und fügte „zur Fehlersuche" die Spalte phone sowie das Feld card_pan in die ersten 100 Zeilen ein. Die dbt-Tests auf not_null bestanden, der Produkteigentümer sah sich den PR flüchtig an und mergte.
Aufgabe: Zwei Wochen später stellte sich heraus, dass der Mart regelmäßig in einem Dashboard verwendet wurde, auf das Analysten benachbarter Abteilungen Zugriff hatten, die nicht berechtigt waren, mit personenbezogenen Daten der Kunden zu arbeiten. Die Spalten phone und card_pan wurden für die Antifraud-Abteilung formal nicht benötigt, landeten aber im Export und in Ad-hoc-Berichten. Die Rechtsabteilung verlangte eine Erklärung.
Lösung: Das Team führte eine sofortige Prüfung durch: entfernte die PII-Spalten aus dem Mart, verlagerte sie vollständig (sie wurden in der Mart-Schicht nicht gebraucht). Anschließend implementierte es vier Barrieren. (1) Listete in ODCS explizit die verbotenen Spalten auf: pii_email, phone, passport_number, card_pan, Steuernummer. (2) Erstellte ein pre-commit-Skript list_pii_columns.py, das models/marts/ nach der Liste der verbotenen Spalten durchsucht und bei einem Treffer den Commit blockiert. (3) Ergänzte in der Spezifikation von mart_customer_transactions den Punkt „PII: der Mart enthält keine direkten Identifikatoren; die Prüfung durch den Reviewer vor dem Release ist obligatorisch". (4) Führte einen obligatorischen Schritt im Reviewer-Bericht ein: „Liste der verbotenen PII abgeglichen, keine Übereinstimmungen, Datum, Unterschrift", der dem PR beigefügt wird.
Ergebnis: Das Datenleck wurde geschlossen, die Prozesse wurden verschärft. Im folgenden Monat schlug das pre-commit-Skript bei anderen Modellen zweimal an und verhinderte Versuche, phone und E-Mail „zur Fehlersuche" hinzuzufügen. Die Antifraud-Analysten stellten fest, dass die Arbeitsqualität nicht litt – sie brauchten tatsächlich nur Aggregate. Die Rechtsabteilung schloss den Vorfall ohne Beanstandungen, da das Team nachweisen konnte, dass die PII-Richtlinie nun in Form überprüfbarer Regeln ausgedrückt war, nicht als Schlagworte.
Gewonnene Erkenntnisse: „Zur Fehlersuche hinzufügen" ist ein typischer Weg, wie PII in produktive Marts gelangt; Fehlersuche gehört in die Schichten staging/intermediate, nicht in marts.
Das Schlagwort „personenbezogene Daten nicht offenlegen" ist nutzlos, wenn es nicht in eine konkrete Liste verbotener Spalten und eine automatische Prüfung verwandelt wird.
Die PII-Richtlinie muss in der Spezifikation festgehalten werden, nicht in SQL-Kommentaren und nicht im Chat – sonst hat sie keinen Eigentümer und keine Möglichkeit, automatisch durchgesetzt zu werden.
Mehrschichtiger Schutz (ODCS + pre-commit + manueller Reviewer-Schritt + Bericht) fängt das ab, was eine einzelne Barriere durchlässt.
Verwandte Konzepte: PII_und_direkte_Identifikatoren
Überprüfbare_Regel_statt_Schlagwort
ODCS_und_ODPS
Spezifikationsschichten_in_SDD_Data
Name: Fall 3. Umstrittene Interpretation von risk_flag im Lern-Mart
Szenario: Im Mart mart_customer_360 tauchte die Spalte risk_flag mit den Werten {low, medium, high} auf. In der Quelle wird sie als Lernsignal gebildet: „der Kunde hat an einer Trainings-Antifraud-Kampagne teilgenommen". Die Mart-Spezifikation beschrieb risk_flag als „aggregierten Risikoindikator", ohne zu präzisieren, dass es sich um ein Lernsignal handelt und nicht um produktives Scoring. Der dbt-Test accepted_values auf {low, medium, high} war grün.
Aufgabe: Nach einem Quartal begann die Kreditrisikoabteilung, mart_customer_360 als Quelle für ein Pre-Scoring zu nutzen. Sie verwendeten risk_flag als fertiges Merkmal und bezogen es in das Modell zur Limitberechnung ein. In der Quartalssitzung stellte sich heraus, dass „high" im Mart in Wirklichkeit nicht „hohes Risiko" bedeutete, sondern „der Kunde war Teil der Trainingsstichprobe" – das Signal war also inhaltlich invertiert. Der Fehler führte zu keinen realen Verlusten (es ist eine Lernbank), aber der Prozess war gefährlich.
Lösung: Das Team führte eine Analyse durch. (1) Benannte die Spalte in training_risk_flag um, damit der Name bereits auf die Natur der Daten hinweist. (2) Aktualisierte ODCS und die Spezifikation: ergänzte den Abschnitt „Semantik und Anwendungsbeschränkungen", in dem explizit angegeben wurde, dass training_risk_flag eine Zugehörigkeitsmarkierung zur Trainingsstichprobe ist, kein Scoring-Ergebnis, und seine Verwendung in produktiven Modellen verboten ist. (3) Fügte in der Spaltenbeschreibung in schema.yml eine Warnung hinzu, die in der von dbt generierten Dokumentation erscheint. (4) Führte einen obligatorischen Schritt ein: Wenn jemand eine Spalte mit dem Wort risk oder score zu einem Mart hinzufügt, muss der Reviewer dem PR eine Bestätigung des Produkteigentümers zur Natur des Feldes beifügen.
Ergebnis: Die Kreditrisikoabteilung nutzte mart_customer_360 nicht mehr als Quelle für Scoring-Merkmale und wechselte auf einen separaten Mart für produktives Risiko-Scoring. Die semantische Verwechslung wurde beseitigt. Das Team etablierte die Praxis „jedes Feld mit sensiblem Namen (risk, score, limit, status) erfordert eine explizite Semantikbeschreibung in der Spezifikation", was die Wahrscheinlichkeit ähnlicher Fehler in Zukunft senkte.
Gewonnene Erkenntnisse: Spaltenname und Test auf accepted_values schützen nicht vor falscher Semantik – der Wert „high" bedeutet in einem Kontext das eine, in einem anderen etwas anderes.
dbt-Tests fangen Form, aber nicht die Interpretation ab: Semantik ist die Verantwortung der Spezifikation.
In SDD Data zählt nicht nur „welche Felder gibt es", sondern auch „wie das Feld NICHT verwendet werden darf" – auch das ist Teil des Vertrags.
Gefährliche Spaltennamen (risk, score, limit) erfordern einen eigenen Review-Prozess – sonst werden sie leicht als fertiges Produkt missverstanden.
Verwandte Konzepte: Vertragsdrift
Abnahmefakten_acceptance_facts
Überprüfbare_Regel_statt_Schlagwort
ODCS_und_ODPS
Lerntipps: Halten Sie einen realen (oder gedachten) Mart aus Ihrem dbt-Projekt griffbereit: Das Kapitel lässt sich leichter verstehen, wenn Sie gleichzeitig die Spezifikation Ihres eigenen Marts umschreiben und nicht die eines abstrakten customer_360.
Machen Sie es sich zur Regel: Nach jedem Absatz einer Spezifikation fragen Sie sich „wie werde ich das prüfen?". Wenn es keine Antwort gibt – schreiben Sie den Absatz so lange um, bis er ein Befehl, ein SQL, ein manueller Reviewer-Schritt oder eine menschliche Bestätigung ist.
Vergleichen Sie „schlechte" und „gute" Spezifikationen nicht auf der Ebene der Länge, sondern auf der Ebene der Überprüfbarkeit: Eine gute Spezifikation wirkt enger, weil sie kaum Raum für Raten lässt.
Üben Sie das Verwandeln von Schlagworten („Qualität sicherstellen", „Risiken berücksichtigen") in überprüfbare Regeln – das ist die Hauptfähigkeit des Kapitels und die häufigste Fehlerquelle in der Produktion.
Denken Sie daran, dass „grüner dbt build" ein Ausgangspunkt ist, kein Endpunkt. Fragen Sie danach: „Ist das der richtige Grain? Gibt es überflüssige Spalten? Habe ich die Semantik von risk_flag richtig verstanden?".
Verwenden Sie die Checkliste „fünf Risikoklassen" als Gewohnheit: Für jeden neuen Mart fragen Sie, ob PII, Zahlungen, Einwilligungen, Kreditportfolio und Reproduzierbarkeit der Berichterstattung berücksichtigt sind.
Schreiben Sie nicht in AGENTS.md „halte Bankanforderungen ein": Für einen Agenten ist das ein leerer Satz. Listen Sie besser konkrete Verbote, erlaubte Eingabemodelle, Vertragsfelder und Prüfungen auf.
Legen Sie eine eigene Datei „Notizen zu Datenrisiken" mit Abschnitten PII / Grain / Freshness / Vertragsdrift / Menschliche Bestätigungen an – das Kapitel fordert ein solches Artefakt direkt, und es hilft tatsächlich in der täglichen Arbeit.
Üben Sie sich darin, Spezifikationen „vom Gegenteil her" zu schreiben: Stellen Sie sich zunächst vor, wie ein Reviewer oder Agent den Mart kaputtmachen würde (überflüssige Spalte hinzufügen, Grain ändern, ein Lernflag als produktiv verwenden) und schließen Sie genau diese Wege in der Spezifikation.
Unterscheiden Sie „die Tabelle wurde gebaut" und „die Daten sind nutzbar": Ersteres ist eine technische Tatsache, Letzteres eine Produktverpflichtung. Im Bankbereich klaffen sie öfter auseinander, als man denkt.
Zusätzliche Ressourcen: Open data contract standard (odcs): Standard für den technischen Datenvertrag des AIDA Data Council. Beschreibt Felder, Typen, Eigentümer, Einschränkungen. Wird in SDD Data als Schicht des technischen Vertrags verwendet.
Open data product standard (odps): Standard zur Beschreibung des Datenprodukts des AIDA Data Council. Beschreibt Konsument, Aufgabe, SLA, Abnahmekriterien. Wird in SDD Data als Schicht des Produktvertrags verwendet.
Dbt documentation: tests: Abschnitt der offiziellen dbt-Dokumentation zu Tests (generische Tests not_null, unique, accepted_values, relationships; benutzerdefinierte Tests über singular SQL). Quelle für Informationen darüber, was dbt-Tests konkret abfangen.
Dbt documentation: sources und freshness: Abschnitt der dbt-Dokumentation zu Quellen und zur Konfiguration von source freshness. Hilft, die Schicht der Datenaktualität in der Spezifikation abzudecken.
Dbt Labs Blog: „why data tests are not enough": Eine Reihe von Materialien von dbt Labs zu den Grenzen automatischer Datentests. Stützt die Idee des Kapitels vom mehrschichtigen Schutz.
DSGVO und 152-FZ (russischsprachige Quellen): Regulatorische Grundlage für den Umgang mit personenbezogenen Daten in der EU und der Russischen Föderation. Nützlich als Kontext, um zu verstehen, warum die PII-Richtlinie in einer Bank in konkreten Regeln ausgedrückt werden muss und nicht in Schlagworten.
Buch „fundamentals of data engineering" (Joe Reis, Matt Housley): Modernes Lehrbuch zur Data Engineering, in dem Datenverträge, Lineage, Qualität und Reproduzierbarkeit ausführlich behandelt werden – das konzeptionelle Fundament für die Ideen des Kapitels.
Datafold-Blog und Ressourcen zu data contracts: Materialien zu data contracts und data diffing. Nützlich, um zu verstehen, wie sich Vertragsdrift zwischen Mart-Versionen automatisch erkennen lässt.
Zusammenfassung: Die größte Herausforderung bei Bankdaten ist nicht die Komplexität von SQL, sondern die Tatsache, dass ein Fehler oft normal aussieht: Die Tabelle ist erstellt, die Tests sind grün, aber die Bedeutung ist bereits zerstört. Deshalb ist im Bankbereich die Disziplin der Spezifikationen besonders wichtig: Jede Aussage über Daten muss in einen Befehl, ein SQL, einen manuellen Reviewer-Schritt oder eine menschliche Bestätigung verwandelt werden. Das Kapitel führt fünf Risikoklassen (PII, Zahlungen, Einwilligungen, Kreditportfolio, Berichterstattung), fünf Schutzschichten (dbt-Tests, ODCS, ODPS, Modellspezifikation, Reviewer-Bericht) und die Schlüsselfertigkeit ein, „die Tabelle wurde gebaut" von „die Daten sind nutzbar" zu unterscheiden. Das praktische Ergebnis des Kapitels ist eine gefüllte Datei „Notizen zu Datenrisiken" mit konkreten, überprüfbaren Regeln für PII, Grain, Freshness, Vertragsdrift und menschliche Bestätigungen. Eine enge, überprüfbare Spezifikation ist immer besser als eine breite Floskel: Gerade die Enge macht die Arbeit ablehnbar und damit steuerbar.