Löschen über Warehouse, Lake und BI

Scope und Strategie ohne Plattformpfad bleiben Absicht. Löschung hält erst, wenn Raw, Curated, Marts, dbt-Modelle und BI-Extracts in einer festen Reihenfolge und mit klaren Hand-offs ausgeführt werden.

ze/Silver/Gold, dbt-Models, aggregierten Marts, Semantic Models und gebuchten Dashboards. Ein Job löscht die Hub-Tabelle. Der nächste dbt-Run materialisiert den Key aus einer ungeklärten Staging-Quelle zurück. Das BI-Dataset refreshed aus dem alten Extract.

Lösung: Behandeln Sie Cross-Platform-Löschung als orchestrierten Run, nicht als Sammlung unabhängiger Skripte.

In einem Satz: Behandeln Sie Cross-Platform-Löschung als orchestrierten Run, nicht als Sammlung unabhängiger Skripte.

Problem

Analytische Landschaften verdoppeln Identifier entlang des Flusses. Ein Subject landet in Landing-Zonen, Bronze/Silver/Gold, dbt-Models, aggregierten Marts, Semantic Models und gebuchten Dashboards. Ein Job löscht die Hub-Tabelle. Der nächste dbt-Run materialisiert den Key aus einer ungeklärten Staging-Quelle zurück. Das BI-Dataset refreshed aus dem alten Extract.

Typische Ausfälle:

• Warehouse-DELETE ohne Lake-File-/Partition-Bereinigung;
• dbt-Incremental überspringt Deletes, weil nur Inserts/Updates modelliert sind;
• Marts behalten degenerierte Dimensionsschlüssel und lesbare Attribute;
• BI-Importpfade (Gateway, Shared Dataset, QVD, Parquet-Exportdatei) bleiben außerhalb des Jobs;
• Reihenfolge falsch: Nutzer zuerst „sauber“, Upstream speist danach erneut ein;
• keine Idempotenz: zweiter Lauf scheitert oder erzeugt Inkonsistenz.

Diese Serie setzt Scope (Teil 1) und Strategie (Teil 2) voraus. Pillars für Request, Retention und Privacy bleiben: DSDR Governance, Data Lifecycle & Retention, PII & Privacy Governance. Hier geht es um den Ausführungspfad über Plattformen.

Verwandte Nachbarn:

• Hard, Soft, Anonymisieren oder Crypto-Shred wählen — Technik je Umfang-Zeile;
• Auskunfts- und Löschrechte Governance — Fristen und Verantwortung;
• Serie: Löschung, die hält.

Plattformrisiko zeigt sich so:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

1. Source purge OK
2. Landing / raw still has files
3. dbt run rebuilds customer_dim from raw
4. Mart + BI extract republish PII
5. Ticket still "analytics cleaned"

Ein Pfadbruch genügt, und die Löschung hält nicht.

Eine zweite Signatur ist der Orphan Rebuild: Deletes nur in Facts, Dimensionen und Bridges bleiben. Eine dritte ist Extract Lag: Live-SQL ist sauber, gebuchte Extracts nicht. Eine vierte ist Job Siloing: jedes Team hat ein Skript, niemand einen Runbook-Owner für den Gesamtpfad.

Entscheidung

Behandeln Sie Cross-Platform-Löschung als orchestrierten Run, nicht als Sammlung unabhängiger Skripte.

Drei Prinzipien:

1. Upstream vor Downstream, dann Verify. Raw/Landing und gesteuerte Basisschichten zuerst; Marts und BI danach; Stichproben und Negativchecks am Ende.
2. Transforms müssen Deletes kennen. Incremental-, SCD- und Snapshot-Modelle brauchen explizite Delete-/Tombstone-Semantik — sonst ist „dbt run“ ein Undelete.
3. BI ist ein Scope, kein Nachgedanke. Dataset-Refresh, Cache-Invalidierung und Extract-Retire gehören in denselben Runbook-Schritt wie Warehouse-SQL.

Der Runbook-Pfad (Outline):

1. Case lock + Hold-Check;
2. Identifier-Liste freigeben (kanonische Keys);
3. Source-/Ingress-Bestätigung;
4. Lake/Files/Partitions gemäß Strategie;
5. Warehouse-Basisschichten + Bridges;
6. dbt-/Transform-Deletes und Full-Refresh-Entscheidungen;
7. Marts / Serving;
8. BI extracts, caches, published semantics;
9. Verify-Queries und Ausnahme-Log;
10. Evidence-Handoff (Teil 6).

Backup/Time Travel und Nonprod/Side Copies folgen in Teilen 4–5 und dürfen im Runbook als eigene Steps referenziert werden, ohne diesen Teil zu überladen.

Operativ hilft eine einfache Regel: kein Downstream-Step startet, bevor der Upstream-Step Verify bestanden hat — außer der Runbook dokumentiert eine bewusste Parallelität (z. B. unabhängige Dateisystem- und Warehouse-Purges mit gemeinsamer Gate vor BI). Ohne Gate entstehen Race Conditions: Marts lesen noch Rohdaten, während Raw schon geleert wird, oder BI refreshed mitten im Warehouse-Lauf.

Idempotenz ist Teil der Entscheidung, nicht „nice to have“. Ein zweiter Lauf nach Teil-Failure muss denselben Endzustand anstreben: bereits entfernte Keys bleiben entfernt, Tombstones bleiben stabil, Holds bleiben unberührt. Fehlt Idempotenz, wird jeder Retry zum Incident.

Checkliste

Skizzieren Sie den Plattformpfad für einen Pilotfall:

• ordnen Sie Umfang-Zeilen entlang des Datenflusses (raw → curated → mart → bi);
• markieren Sie dbt-Models mit Incremental/SCD/Snapshot-Verhalten;
• definieren Sie Delete-Semantik je Model-Typ;
• legen Sie Run-Reihenfolge und Rückbau-Stopps fest;
• benennen Sie Job-Owner und On-call je Segment;
• listen Sie BI-Artefakte: datasets, gateways, QVDs, extracts, caches;
• planen Sie Verify-Queries (Count = 0 / Token only / Hold intact);
• notieren Sie Idempotenz und Wiederholbarkeit des Runs;
• koppeln Sie Fristen an Auskunfts- und Löschrechte Governance;
• stoppen Sie, wenn der Outline von Identifier-Freigabe bis BI-Verify lückenlos ist.

Artefakt

Erstellen Sie ein Cross-Platform Deletion Runbook (Outline + ausführbare Steps).

Pflichtfelder / Abschnitte:

• Case-ID, Umfang-Matrix- und Decision-Card-Verweise;
• kanonische Identifier und Ausschlusslisten (Hold);
• Step-Liste mit System, Aktion, Strategie, verantwortliche Person, SLA;
• dbt-/Transform-Hinweise (incremental, full-refresh, tombstone);
• BI-Invalidate-/Retire-Steps;
• Verify-Block mit erwarteten Resultaten;
• Failure-Modes und Stop-the-line-Kriterien;
• Nachweis-Outputs (Logs, Query-Hashes, Ticket-Links);
• Version und Review-Datum.

Ergebnisse: wiederholbarer plattformübergreifender Pfad, weniger Rebuild-Überraschungen, klarer Handoff an Backup- und Evidence-Teile.

Tools

Orchestrierung (Airflow, ADF, Fabric Pipelines, dbt Cloud/CLI). Warehouse-/Lake-SQL und File-APIs. Lineage für Abhängigkeitsreihenfolge. BI-Admin-APIs für Dataset-Refresh und Cache. Ticket-System für Step-Sign-off. Least Privilege für destruktive Jobs.

Ressourcen

Interne Quellen: dbt-Projektdocs, Warehouse-Runbooks, Lake-Retention-Jobs, BI-Workspace-Inventare, On-call-Playbooks, frühere „Key came back after dbt run“-Incidents.

Nachbarn: DSDR Governance, Data Lifecycle & Retention, PII & Privacy Governance, Teile 1 und 2, Serie: Löschung, die hält.