Thema: Teil 9. Raw- und Bronze-Landung
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 2-3 Stunden (Theorie + Praxis)
Voraussetzungen: Grundlegendes Verständnis der Data-Lakehouse-Architektur (Schichten Raw, Bronze, Silver, Gold)
Erfahrung mit dbt oder ähnlichen Datentransformationstools
Kenntnisse in SQL und Konzepten von Datenschemata
Verständnis der Prinzipien von Lineage und Metadaten
Grundlegende Kenntnisse in Python (zur Erzeugung synthetischer Daten)
Lernziele: Die Verantwortungsbereiche der Raw- und Bronze-Schichten unterscheiden und formulieren können, welche Transformationen in jeder von ihnen zulässig sind
Erklären können, warum Daten in der Raw-Schicht ohne explizite geschäftliche Begründung nicht verändert, gelöscht oder verborgen werden dürfen
Akzeptanzfakten (acceptance facts) zur Überprüfung der Reproduzierbarkeit des Eingangs in den Speicher erstellen
Die Semantik von Leerwerten und Null über das Quell-Manifest beschreiben, nicht über manuelle Korrekturen
Eine Beweiskette Raw → Manifest → Spezifikation → Staging → Test aufbauen, um Produktentscheidungen zu schützen
Übersicht: Kapitel 9 widmet sich den ersten beiden Schichten der Lakehouse-Architektur – Raw und Bronze – die für die Reproduzierbarkeit des Dateneingangs verantwortlich sind. Im Lernbeispiel wird Raw durch CSV-Dateien dargestellt, die vom Skript scripts/generate_data.py erzeugt werden; in einer Produktionsumgebung kann dies eine Landing-Zone im Objektspeicher, ein Kafka-Topic, eine CDC-Tabelle oder eine externe API sein. Trotz der unterschiedlichen physischen Implementierung gilt ein einziges Prinzip: Im ersten Schritt darf die Bedeutung der Daten nicht verändert werden. Raw beantwortet die Frage „Was ist angekommen" und bewahrt den Input unverändert – einschließlich Leerwerten, PII und Widersprüchen. Bronze fügt eine minimale technische Normalisierung hinzu (Dateiformat, Typisierung, Lademetadaten, Lineage), trifft jedoch keine Produktentscheidungen. Ziel des Kapitels ist es, den Leser zu befähigen, die Beschreibung von Daten von ihrer Korrektur zu unterscheiden, zu verstehen, dass „langweiliges und ehrliches" Raw eine Absicherung gegen künftige Diskussionen über die Datenherkunft darstellt (besonders kritisch im Bankenkontext), und eine kurze Beweiskette aufzubauen, die jedem Reviewer erlaubt, den Weg von der Quelle bis zum Data Mart zurückzuverfolgen.
Schlüsselkonzepte: Raw-Schicht: Die Landing-Zone, die die Frage „Was ist angekommen" beantwortet. Sie bewahrt die Daten in ihrer ursprünglichen Form: dieselben Feldnamen, dieselbe Reihenfolge, dieselben Leerwerte und Null-Marker. Es ist verboten, Geschäftsfelder umzubenennen, Zeilen zu löschen, PII zu verbergen, Werte ohne Belege zu korrigieren und jegliche Aggregationen durchzuführen. Die Raw-Schicht ist absichtlich „langweilig": Ihre Aufgabe ist es, ein ehrlicher Spiegel der Quelle zu sein, nicht ein Filter oder Normalisierer.
Bronze-Schicht: Eine technische Zwischenschicht, die eine minimale Normalisierung ohne Produktlogik hinzufügt: Dateiformat (Parquet, Delta), grundlegende Typisierung der Felder, Lademetadaten (Zeit, Quelle, batch_id), Kontrolle der Spaltenpräsenz und grundlegendes Lineage. Bronze darf keine Geschäftsentscheidungen treffen – zum Beispiel entscheiden, dass ein leerer revoked_at eine aktive Einwilligung bedeutet. Diese Entscheidung wird in die Staging-Spezifikation verlagert.
Reproduzierbarkeit des Eingangs: Eine Schlüsseleigenschaft des Lakehouse: die Möglichkeit, die Raw-Daten erneut zu erzeugen und die Transformationskette bis zum Data Mart mit demselben Ergebnis zu durchlaufen. Dies wird durch Versionierung der Erzeugungsskripte, Quell-Manifeste, Kopfzeilenprüfungen und Fixierung der synthetischen Daten erreicht.
Akzeptanzfakten Raw/Bronze: Ein minimaler Satz von Prüfungen, die bestätigen, dass der Eingang korrekt ist: Quelldateien existieren und sind zugänglich, Kopfzeilen entsprechen dem erwarteten Quellschema aus der Domänenkarte, die Erzeugung synthetischer Daten ist reproduzierbar, die Semantik der Leerwerte und Null ist im Manifest beschrieben, PII geht bis zur Genehmigung der Verarbeitungsrichtlinie nicht verloren.
Semantik der Leerwerte: Eine Interpretationsregel für leere Zellen und NULL-Werte, die im Quell-Manifest festgehalten wird, nicht im Code oder in den Daten. Beispielsweise kann ein leerer revoked_at „Einwilligung aktiv" oder „Einwilligung vor Einführung des Feldes widerrufen" bedeuten – die Wahl wird vom Business getroffen und explizit dokumentiert, nicht aus Bequemlichkeit für einen bestandenen Test angenommen.
Lineage und Lademetadaten: Technische Informationen, die auf Bronze-Ebene hinzugefügt werden: Quellname, Pfad zur Datei oder zum Topic, Ladezeitstempel, Batch-Identifikator, Schema-Version. Sie ermöglichen die Rückverfolgung der Herkunft jeder Zeile im Data Mart bis zum ursprünglichen Ereignis.
Quell-Manifest: Ein Dokument, das die erwartete Struktur und Semantik der Raw-Daten festhält: Liste der Spalten mit Typen, Beschreibung der Leerwerte und Null-Marker, Geschäftsinhaber, Aktualisierungsrichtlinie, offene Fragen zu strittigen Feldern. Es verbindet die Datenquelle mit dem Rest der Architektur.
Sdd Data (specification-driven data): Ein Ansatz, bei dem Entscheidungen über Daten in Spezifikationen und Manifesten festgehalten werden, nicht im Transformationscode oder, erst recht, in den Daten selbst. Raw/Bronze ist der Ort, an dem SDD das künftige Gespräch mit einem Reviewer oder Regulator schützt.
Typischer Fehler des „grünen Tests": Die Versuchung, die Quell-CSV zu korrigieren, damit dbt build durchläuft. Äußerlich verschwindet der Fehler, aber mit ihm verschwindet auch der Beleg, dass die Quelle einen mehrdeutigen Wert geliefert hat. Der korrekte Weg: Den Eingang fixieren, die Interpretation im Staging-Vertrag beschreiben, einen Test hinzufügen.
Domänenkarte: Eine Karte des Fachgebiets, die Entitäten, ihre Beziehungen, Dateninhaber und erwartete Quellen beschreibt. Sie wird als Referenz beim Abgleich der Kopfzeilen von Raw-Dateien verwendet.
Wichtige Termine: Evolutionsphase des Lakehouse (ca. 2019-2020): Aufkommen der Terminologie der Medallion-Architektur (Bronze/Silver/Gold) bei Databricks und Verankerung der Idee einer schichtweisen Datenverarbeitung mit expliziter Trennung zwischen technischer Normalisierung und Geschäftslogik.
Einführung von dbt in die SDD-Praxis (ab 2021): Wachstum der Popularität von dbt als Tool, das die Staging- und Mart-Schichten „in SQL kommunizieren ließ", verstärkte die Aufmerksamkeit auf Modellspezifikationen und Tests und erhöhte damit die Bedeutung einer ehrlichen Raw-Schicht.
Regulatorische Änderungen zu PII (DSGVO seit 2018, Aktualisierungen von FZ-152 in der RF): Verschärfung der Anforderungen an die Verarbeitung personenbezogener Daten, durch die die Regel „PII vor Genehmigung der Richtlinie nicht verbergen" besonders im Banken- und Finanzsektor kritisch wurde.
Übungsaufgaben: Name: Suche nach einem Feld mit mehrdeutiger Semantik der Leere
Problem: Öffnen Sie das Verzeichnis book3/examples/bank-lakehouse/raw und untersuchen Sie alle CSV-Dateien. Finden Sie ein Feld, in dem sowohl leere Zeichenketten als auch explizite Null-Marker (oder ein Wert, der wie 'unknown', 'n/a' usw. aussieht) vorkommen. Beschreiben Sie für das gefundene Feld: (1) wie es als Raw-Fakt gespeichert werden soll; (2) wo und wie die technische Typisierung in Bronze erfolgt; (3) in welcher Staging-Spezifikation die Geschäftsregel zur Interpretation erscheinen wird; (4) welcher Test in dbt die Korrektheit der Interpretation bestätigen soll. Hinweis: Beginnen Sie mit der Datei consents.csv und dem Feld revoked_at.
Lösung: Schritt 1. Öffnen Sie raw/consents.csv und suchen Sie Zeilen, in denen revoked_at leer ist. Schritt 2. Fixieren Sie den Raw-Fakt: Die leere Zelle wird als leer gespeichert (oder als NULL nach dem Lesen mit Pandas/duckdb, je nach Parser), ohne Standardwerte einzusetzen. Schritt 3. Führen Sie im Bronze-Modell stg_consents (oder einem äquivalenten) die Typumwandlung auf DATE oder TIMESTAMP durch, ohne die Leere zu interpretieren. Schritt 4. Fügen Sie in der Staging-Spezifikation (z. B. in schema.yml oder in _models/_docs) die Regel hinzu: Ein leerer revoked_at wird in der Staging-Logik als „Einwilligung zum Zeitpunkt der Ausladung aktiv" behandelt. Schritt 5. Schreiben Sie einen dbt-Test, der prüft, dass nach der Transformation für alle aktiven Einwilligungen der Wert is_active = true dem erwarteten Anteil entspricht (z. B. not_null oder accepted_values). Schritt 6. Halten Sie die Entscheidung in einer Testnotiz fest, die erklärt, warum genau so.
Komplexität: intermediate
Name: Abgleich der Kopfzeilen mit der Domänenkarte
Problem: Führen Sie mit Qwen (oder manuell) die Anfrage aus dem Abschnitt „Qwen-Anfrage" aus: Überprüfen Sie die Raw-Quellen in book3/examples/bank-lakehouse/raw, vergleichen Sie die Kopfzeilen mit den erwarteten Quellen aus der Domänenkarte und erstellen Sie eine Liste von Quellfakten und offenen Fragen. Ändern Sie dbt-Modelle nicht. Ziel ist es, Abweichungen festzuhalten, bevor sie zu Fehlern im Staging führen.
Lösung: Schritt 1. Öffnen Sie jede CSV im Verzeichnis raw und notieren Sie die tatsächlichen Kopfzeilen. Schritt 2. Öffnen Sie die Domänenkarte (z. B. docs/domain_map.md oder eine ähnliche Datei im Repository) und notieren Sie die erwarteten Kopfzeilen für jede Quelle. Schritt 3. Erstellen Sie eine Tabelle der Abweichungen: Welches Feld fehlt, welches wurde umbenannt, welches hat einen unerwarteten Typ. Schritt 4. Klassifizieren Sie jede Abweichung: (a) tatsächlicher Quellfehler → offene Frage an den Eigentümer; (b) Begriffsabweichung → Manifest präzisieren; (c) Domänenmodell hat sich geändert → Karte aktualisieren. Schritt 5. Erstellen Sie ein Markdown-Dokument „Quellfakten und offene Fragen", das als Einstiegspunkt für den Reviewer dient.
Komplexität: intermediate
Name: Anti-Pattern: CSV reparieren statt Vertrag reparieren
Problem: Simulieren Sie die Situation: Sie führen dbt build aus, und das Modell stg_consents bricht mit dem Fehler „NULL value not allowed for column revoked_at_iso" ab. In der Raw-Datei gibt es tatsächlich Zeilen mit leerem revoked_at. Modellieren Sie zwei Lösungswege – den falschen und den richtigen – und beschreiben Sie die Folgen jedes Wegs nach 1, 6 und 12 Monaten.
Lösung: Falscher Weg: CSV öffnen, leere Zeichenketten durch einen Platzhalter-Datum ersetzen (z. B. 1900-01-01), Datei neu speichern, dbt build erneut starten – er ist grün. Nach 1 Monat erinnert sich niemand mehr an die Substitution. Nach 6 Monaten kommt ein Auditor und fragt, warum 12 % der Einwilligungen im System ein Widerrufsdatum im Jahr 1900 haben. Nach 12 Monaten können Sie nicht mehr rekonstruieren, welche Kunden tatsächlich die Einwilligung widerrufen haben und welche nicht. Richtiger Weg: Raw unverändert fixieren; im Staging-Modell safe_cast oder try_cast verwenden, der Leere in NULL umwandelt; im Manifest beschreiben, dass ein leerer revoked_at als „aktive Einwilligung" interpretiert wird; dbt-Test not_null auf das abgeleitete Feld is_active hinzufügen sowie einen Konsistenztest is_active ↔ revoked_at. Nach 1, 6 und 12 Monaten bleibt die Beweiskette intakt: Raw → Manifest → Staging → Test.
Komplexität: intermediate
Name: Entwurf von Akzeptanzfakten für eine neue Quelle
Problem: Das Team bindet eine neue Quelle an – eine Ausladung von Kartenoperationen aus einem externen Processing. Die Quelle kommt täglich als Parquet-Datei in S3 an. Entwerfen Sie einen Satz von Akzeptanzfakten für die Raw- und Bronze-Schicht, die automatisiert geprüft werden (z. B. Great Expectations, dbt-source-freshness oder ein eigenes Python-Skript).
Lösung: Raw-Akzeptanzfakten: (1) Datei existiert unter dem erwarteten Pfad s3://bucket/raw/card_ops/yyyy/mm/dd/; (2) Dateigröße > 0; (3) Kopfzeilen entsprechen dem Manifest (card_id, txn_id, amount, currency, txn_ts, mcc); (4) Prüfsumme stimmt mit dem Manifest überein (Schutz gegen Substitution); (5) keine unerwarteten Spalten; (6) PII-Felder (card_id) sind vorhanden und nicht maskiert. Bronze-Akzeptanzfakten: (1) Schema ist auf die erwarteten Typen abgebildet (amount → DECIMAL, txn_ts → TIMESTAMP); (2) Lademetadaten hinzugefügt (loaded_at, source_batch_id, source_file_path); (3) Zeilenanzahl Raw und Bronze stimmt überein (Schutz gegen Verluste bei der Konvertierung); (4) Freshness: Daten nicht älter als N Stunden; (5) Lineage in die Meta-Tabelle geschrieben. Alle Prüfungen laufen vor dem Start von dbt build und blockieren ihn bei Fehlschlag.
Komplexität: advanced
Fallstudien: Name: Streit um die Kundeneinwilligung ein halbes Jahr nach der Ausladung
Szenario: Eine Retailbank erhält eine Beschwerde von einem Kunden: „Ich habe meine Einwilligung zur Verarbeitung personenbezogener Daten bereits im März widerrufen, und man ruft mich im August weiterhin mit Werbeangeboten an." Die Rechtsabteilung fordert vom Datenteam eine Bestätigung des Einwilligungsstatus für jeden Tag von März bis August. Die Daten kommen aus einem externen CRM in Form täglicher CSV-Ausladungen, die in die Raw-Schicht und anschließend über dbt in die Einwilligungs-Mart transformiert werden.
Aufgabe: Bei der Erstladung der CSV-Datei für März war das Feld revoked_at teilweise leer (die Quelle lieferte die Daten in einer Übergangsphase, in der einige Systeme das Widerrufsdatum noch nicht übermittelten). Das Team öffnete, damit der grüne dbt build durchlief, die Datei und ersetzte die leeren Zellen durch das Datum 1900-01-01. Technisch sehen die Daten „sauber" aus, aber der Kunde, der tatsächlich Mitte März widerrufen hat, gilt nun bis August als aktiv – weil der „Widerruf" im System im Jahr 1900 stattfand.
Lösung: Das Datenteam rekonstruiert im Audit die Ereigniskette: findet in der Git-Historie den Commit, in dem die CSV-Datei mit dem eingesetzten Datum neu gespeichert wurde; prüft das Staging-Modell und stellt fest, dass die Interpretation revoked_at = 1900-01-01 → is_active = false nicht dokumentiert war. Das Team überarbeitet den Prozess: (1) Stellt die ursprüngliche CSV aus einer versionierten S3-Sicherung wieder her; (2) hält im Quell-Manifest fest, dass ein leerer revoked_at als „keine Daten" behandelt wird, nicht als „aktiv"; (3) fügt in der Staging-Logik eine explizite Regel hinzu: is_active = (revoked_at IS NULL AND consent_given_at IS NOT NULL); (4) fügt einen dbt-Test hinzu, der das Auftreten des Datums 1900-01-01 in Produktionsdaten verbietet; (5) gibt die Einwilligungs-Mart neu heraus und liefert den Juristen die korrekte Historie.
Ergebnis: Die Rechtsabteilung erhält einen korrekten Zeitstrahl: Der Kunde hat tatsächlich am 14. März widerrufen, und ab diesem Datum hätte er keine Marketingkommunikation mehr erhalten dürfen. Die Bank regelt den Streit ohne Bußgeld. Der interne Prozess wird überarbeitet: Jegliche manuelle Bearbeitung von Raw-Dateien wird verboten, in der CI wird eine Prüfung hinzugefügt, dass die Git-Historie der CSV nach dem initialen Commit leer ist, und alle Interpretationen von Leerwerten durchlaufen ein Manifest-Review.
Gewonnene Erkenntnisse: Ein „grüner Test" ist kein Beweis für Korrektheit; die Korrektur von Quelldaten ersetzt das Signal und zerstört die Reproduzierbarkeit
Die Semantik der Leerwerte gehört in die Spezifikation, nicht in den Code oder in die Daten selbst
Im Bankenkontext entsteht der Streit nicht heute, sondern in Monaten – deshalb muss die Beweiskette Raw → Manifest → Staging → Test jederzeit wiederherstellbar sein
Die Versionierung der Raw-Daten (S3 Versioning, DVC, git-lfs) ist eine Absicherung, die es erlaubt, eine „manuelle Reparatur" rückgängig zu machen und zu sehen, was die Quelle tatsächlich geliefert hat
Verwandte Konzepte: Raw-Schicht
Semantik der Leerwerte
Quell-Manifest
SDD Data
Typischer Fehler des „grünen Tests"
Reproduzierbarkeit des Eingangs
Name: Anbindung eines Kafka-Topics als neue Raw-Quelle
Szenario: Das Team wechselt von paketweisen CSV-Ausladungen zu einer Streaming-Erfassung von Zahlungsereignissen über Kafka. Das Topic payments.events wird über Kafka Connect im Avro-Format in den Objektspeicher geschrieben. Das Team muss entscheiden, wo die Grenze zwischen Raw und Bronze verläuft und wer für das Avro-Schema verantwortlich ist.
Aufgabe: Es entstehen neue Fragen: (1) Gilt die von Kafka Connect erzeugte Parquet-Datei in S3 bereits als Bronze-Schicht (weil dort Schema und Metadaten vorhanden sind), oder ist es immer noch Raw? (2) Muss der rohe Avro-Byte-Strom für Audit-Zwecke erhalten bleiben? (3) Wie beschreibt man die Semantik der Leerwerte in Streaming-Daten, in denen „Fehlen eines Ereignisses" ebenfalls ein Fakt ist?
Lösung: Das Team trifft folgende Entscheidung: Der rohe Avro-Snapshot jedes Batches wird in S3 im Verzeichnis raw/payments_avro/ für Audit-Zwecke gespeichert – dies ist das eigentliche Raw. Die von Kafka Connect erzeugten Parquet-Dateien werden im Verzeichnis raw/payments/ abgelegt und als Raw-Fakt betrachtet: Sie enthalten technische Kafka-Metadaten (Offset, Partition, Timestamp), aber keine geschäftliche Interpretation. Das Bronze-Modell payments_bronze führt nur Folgendes aus: (1) Abbildung des Avro-Schemas auf dbt-Typen; (2) Hinzufügen von loaded_at, source_partition; (3) Prüfung der Präsenz obligatorischer Felder (event_id, amount, currency); (4) Kontrollprüfung, dass die Anzahl der Datensätze im Avro-Snapshot und im Parquet übereinstimmt. Die Semantik der Leerwerte wird im Manifest fixiert: Eine leere merchant_category bedeutet „MCC vom Quellsystem nicht ermittelt", nicht „Kategorie fehlt nach Geschäftsentscheidung".
Ergebnis: Das Team erhält zwei unabhängige Beweisschichten: Avro-Snapshots für tiefe Audits und Parquet für die tägliche Transformation. Bei jeder Abweichung zwischen Mart und Quelle lässt sich innerhalb von Stunden rekonstruieren, was genau aus Kafka angekommen ist. Die Kosten für die Speicherung der Avro-Snapshots rechtfertigen sich durch die Senkung des regulatorischen Risikos.
Gewonnene Erkenntnisse: Das physische Dateiformat (Parquet, Avro, CSV) bestimmt nicht automatisch die Schicht – entscheidend ist die Rolle der Daten in der Pipeline
Raw muss auch dann erhalten bleiben, wenn Downstream-Tools (Kafka Connect, Fivetran) bereits technische Metadaten hinzufügen
In Streaming-Daten ist das „Fehlen eines Ereignisses" ein ebenso gültiger Fakt wie das Ereignis selbst und muss im Manifest beschrieben werden
Bronze darf nicht die Verantwortung für die Interpretation des Quellschemas übernehmen – dies ist Aufgabe der Staging-Spezifikation
Verwandte Konzepte: Bronze-Schicht
Lineage und Lademetadaten
Akzeptanzfakten Raw/Bronze
Reproduzierbarkeit des Eingangs
Domänenkarte
Name: CDC-Tabelle als Raw: Die Grenze zwischen Technisch und Produktseitig
Szenario: Das Team wechselt auf CDC (Change Data Capture) aus PostgreSQL: Debezium schreibt die Änderungen in ein Topic, von dort gelangen die Daten in eine Iceberg-Tabelle raw.customers_cdc. Die Tabelle enthält alle Operationen (INSERT, UPDATE, DELETE) mit den Metadaten __op, __ts_ms, __source_ts_ms. Die Analysten benötigen nur die aktuelle Version des Kunden.
Aufgabe: Wo soll die Regel „nur die letzte Version des Kunden behalten" leben – in Bronze oder in Staging? Wenn in Bronze, dann trifft Bronze eine produktseitige Entscheidung. Wenn in Staging, dann erhält Staging einen Strom von Operationen und muss die CDC-Semantik verstehen. Außerdem ist zu entscheiden, was mit DELETE-Operationen geschehen soll – ob sie als „Löschung des Kunden" oder als „Operation im Quellsystem" zählen.
Lösung: Das Team fixiert: raw.customers_cdc speichert alle Operationen wie angekommen, ohne Filterung. Das bedeutet, dass INSERT, UPDATE, DELETE und sogar TOAST-Aktualisierungen in der Tabelle verbleiben. Das Bronze-Modell customers_cdc_bronze führt nur Folgendes aus: (1) explizite Typumwandlung (insbesondere für JSON-Felder in PostgreSQL); (2) Umbenennung der technischen CDC-Felder in Lineage-Felder (cdc_op, cdc_ts_ms); (3) Hinzufügen von loaded_at, source_db, source_table. Alle Entscheidungen über „letzte Version", „aktiver Kunde", „ob DELETE angewendet werden soll" wandern in die Staging-Spezifikation stg_customers, wo sie explizit beschrieben und durch Tests abgedeckt werden. Beispielsweise prüft ein Test, dass nach Anwendung der CDC-Operationen die Anzahl der aktiven Kunden mit dem operativen System übereinstimmt.
Ergebnis: Das Team erhält ein „langweiliges" Raw, in dem alle Nuancen der Quelle sichtbar sind: Beispielsweise stellt sich heraus, dass UPDATE-Operationen manchmal vor den INSERTs ankommen (aufgrund der Partitionsreihenfolge in Kafka), und dies erfordert eine spezielle Logik im Staging. Ohne den Raw-Fakt wäre diese Anomalie durch die „saubere" Bronze-Schicht verborgen geblieben und hätte sich erst bei Streitigkeiten mit dem Regulator über die Korrektheit der Saldenneuberechnung gezeigt.
Gewonnene Erkenntnisse: CDC-Daten sind immer Raw, weil sie die interne Mechanik der Quelle widerspiegeln, nicht die produktseitige Sicht
Die „letzte Version einer Entität" ist eine Staging-Entscheidung, die dokumentiert und durch einen Test abgedeckt sein muss
Technische CDC-Metadaten (__op, __ts_ms) sind als Lineage wichtig und dürfen auf Bronze-Ebene nicht verworfen werden
Die Raw-Schicht schützt vor Kontextverlust bei Änderungen der Staging-Logik: Wenn das Business morgen die Regel ändert, was als aktiver Kunde zählt, kann die Mart ohne Verlust der ursprünglichen Operationen neu berechnet werden
Verwandte Konzepte: Raw-Schicht
Bronze-Schicht
Lineage und Lademetadaten
SDD Data
Reproduzierbarkeit des Eingangs
Lerntipps: Öffnen Sie vor dem Lesen des Kapitels das Verzeichnis book3/examples/bank-lakehouse/raw und überfliegen Sie alle CSV-Dateien – dies hilft, reale Beispiele für Leerwerte und Widersprüche zu sehen, die im Text besprochen werden.
Führen Sie ein separates Notizbuch „Offene Fragen zu Raw", in das Sie alle strittigen Felder beim Lesen eintragen. Dieses Notizbuch wird zur Grundlage für das Quell-Manifest in Ihrem eigenen Projekt.
Sprechen Sie die Regel laut aus: „Raw beantwortet die Frage WAS angekommen ist, Staging – die Frage WAS ES BEDEUTET". Wenn Sie im Unterricht die Grenze vergessen haben – kehren Sie zu diesem Satz zurück.
Versuchen Sie beim Studium der Fallstudien zunächst selbst, den „falschen Weg" vorzuschlagen, und vergleichen Sie ihn dann mit dem des Autors – so wird das Anti-Pattern aktiver geformt, und in der Produktion wird die Hand nicht zur CSV-Korrektur greifen.
Verwenden Sie die Technik der „umgekehrten Lineage": Gehen Sie von jedem Feld in der Mart zurück bis zur Raw-Datei und prüfen Sie, dass jede Transformation dokumentiert ist. Wenn die Kette irgendwo abbricht, ist das ein Signal, dass es versteckte Produktlogik in Bronze oder Raw gibt.
Formulieren Sie eine persönliche Regel: „Bevor Sie eine Datei korrigieren, fragen Sie sich – ist das eine Beschreibung der Daten oder eine Korrektur der Daten?" Wenn es eine Korrektur ist – halten Sie inne und überprüfen Sie den Staging-Vertrag.
Erstellen Sie sich eine Checkliste aus 5 Raw-Akzeptanzfakten und hängen Sie sie neben den Monitor – dies verwandelt abstrakte Anforderungen in eine tägliche Gewohnheit bei der Annahme neuer Quellen.
Zur Einprägung des Unterschieds Raw/Bronze verwenden Sie die Mnemonik: „Raw ist der Spiegel, Bronze ist der Rahmen um den Spiegel". Der Rahmen kann die Sicht verbessern, darf aber das Spiegelbild nicht verändern.
Zusätzliche Ressourcen: Buch 'Fundamentals of Data Engineering' (Joe Reis, Matt Housley, O'Reilly 2022): Das Kapitel zu Storage und Ingestion erläutert ausführlich, warum die erste Schicht „langweilig" sein muss und wie Raw, Bronze und das Immutability-Prinzip zusammenhängen.
dbt-Dokumentation: 'About dbt Project Structure' und 'Source Freshness': Beschreibung, wie man in dbt korrekt Sources deklariert und Freshness prüft – dies ist die Formalisierung der Raw-Akzeptanzfakten.
Artikel 'The Medallion Architecture: A Guide to Bronze, Silver, and Gold Layers' (Databricks): Die Originalbeschreibung der Medallion-Architektur mit Schwerpunkt auf den Schichtgrenzen und dem Verbot von Geschäftslogik in Bronze.
Materialien zu 'Great Expectations' (oder Alternative Soda Core): Tools zur Formalisierung von Raw/Bronze-Akzeptanzfakten als Code, damit die Prüfungen versionierbar und reproduzierbar sind.
Buch 'Designing Data-Intensive Applications' (Martin Kleppmann, Kapitel zu Stream Processing): Eine tiefgehende Erklärung dessen, was ein „Fakt des Ereigniseingangs" ist und warum es wichtig ist, ihn von seiner Interpretation zu trennen.
Standard FZ-152 (RF) und DSGVO (EU) zur Verarbeitung von PII: Die regulatorische Grundlage, die erklärt, warum PII in Raw vor Genehmigung der Richtlinie nicht verborgen werden darf – dies ist eine rechtliche und nicht nur eine ingenieurtechnische Norm.
dbt-utils-Paket: Source-Freshness- und Accepted-Values-Tests: Fertige Tests zur Formalisierung eines Teils der Raw/Bronze-Akzeptanzfakten in einem Standard-dbt-Projekt.
Qwen (oder ein ähnlicher LLM-Assistent): Ein Tool zur Automatisierung der Routineprüfung der Kopfzeilen von Raw-Dateilen gegen die Domänenkarte – ein Beispiel für eine Anfrage ist im Kapitel enthalten.
Zusammenfassung: Kapitel 9 „Raw- und Bronze-Landung" formuliert drei Schlüsselprinzipien. Erstens: Raw ist eine „langweilige und ehrliche" Schicht, die den Input in seiner ursprünglichen Form bewahrt: Sie benennt Felder nicht um, löscht keine Zeilen, verbirgt keine PII, korrigiert keine Werte und aggregiert nicht. Ihre Aufgabe ist es, ein Spiegel der Quelle zu sein, kein Filter. Zweitens: Bronze fügt eine minimale technische Normalisierung hinzu (Dateiformat, Typisierung, Lademetadaten, Lineage), darf jedoch keine produktseitigen Entscheidungen treffen – die Interpretation strittiger Werte wird in die Staging-Spezifikation verlagert. Drittens: Die Reproduzierbarkeit des Eingangs wird durch Akzeptanzfakten überprüft: Existenz der Dateien, Korrektheit der Kopfzeilen, Reproduzierbarkeit der Erzeugung, beschriebene Semantik der Leerwerte und Erhalt der PII bis zur Genehmigung der Richtlinie. Der häufigste typische Fehler ist die Korrektur der Raw-Daten für den „grünen Test", die äußerlich das Problem beseitigt, aber die Beweiskette zerstört und es unmöglich macht, die Wahrheit nach Monaten wiederherzustellen (was im Bankenkontext kritisch ist). Nach dem Studium des Kapitels sollte der Leser in der Lage sein, die Beschreibung von Daten von ihrer Korrektur zu unterscheiden, Akzeptanzfakten für neue Quellen zu entwerfen und eine kurze wiederherstellbare Kette Raw → Manifest → Spezifikation → Staging → Test aufzubauen.