Wohin Steuerdaten gehören: Control-DB, Lake oder Warehouse

Geteilte Statuscodes für sales_otc liegen als CSV im Lake — niemand versioniert, niemand testet Joins. Platzierung folgt Maintenance und Distribution, nicht dem nächsten Speichertrend.

zdem zur Gewohnheit: CSV im Lake als Pflege-UI, obwohl niemand versioniert und Joins nicht testet.

Lösung: Default ist eine kleine relationale Control-Datenbank für fachlich gepflegte geteilte Tabellen; Lake oder Warehouse nur für Distribution und Historie — nie CSV-im-Lake als Maintenance-UI.

In einem Satz: Pflege-UI und Speichertrend sind nicht dieselbe Entscheidung.

Problem

Nach der Klassifikation (Teil 4) greifen Teams trotzdem zur Gewohnheit:

• „alles Analytische geht ins Warehouse“ — inklusive zwanzigzeiliger Codelisten, die Stewards nur in Excel editieren können;
• „der Lake ist unsere Plattform“ — also überschreiben Stewards s3://…/mappings/countries.csv und hoffen, dass Crawler es merken;
• „Postgres ist zu operational“ — also bleiben Parameter in Pipeline-Variablen und INLINE-Blöcke kehren zurück;
• „nur eine Kopie“ — also stirbt historisches As-of-Reporting, oder jeder Nutzer liest die Live-Edit-Tabelle ohne Publish-Schritt.

Anti-Patterns explizit benennen:

• CSV-in-Lake als Maintenance-UI — keine Constraints, schwaches Audit, leichte stille Korruption (Teil 3);
• Warehouse-Tabelle als einzige Editor-Oberfläche ohne Stewardship-Rechte und Validierung;
• BI-App-INLINE als SoT, nachdem Sie bereits entschieden haben zu extrahieren (Teil 2);
• Duplicate Masters in Kontrollregel-DB und unkontrolliertem Excel und Seed-Ordnern;
• Berechtigung-Listen in weltlesbaren Lake-Pfaden (Access & Security Governance).

Warehouse und Lake bleiben essenziell für Analytics-Distribution, SCD-Snapshots und große abgeleitete Hierarchien. Sie sind selten der beste Ort, an dem Menschen kleine geteilte Wahrheit pflegen. Das entspricht dem Plattform-Split in Building a Modern Data Warehouse und dünnen Consumers in Fachliche Logik außerhalb der BI-Apps halten.

Entscheidung

Standard: kleine relationale Control-Datenbank für fachlich gepflegte geteilte Control-Tabellen. Lake oder Warehouse für Snapshots, Distribution und Analytics — nie CSV-in-Lake als Maintenance-UI.

Praktische Defaults nach Operating Class:

PostgreSQL (oder das Standard-RDBMS der Organisation) ist für viele Control-DBs ausreichend: Constraints, Keys, Rollen, Migrations, langweiliges Backup. Die Marke zählt weniger als die Eigenschaften — relationale Integrität, Zugriffskontrolle, Change Audit und eine API/UI, die Stewards nutzen können.

Publish-Muster:

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

Steward UI / validated template
        → Control DB (system of record)
        → batch or CDC publish
        → Warehouse / Lake snapshots (system of distribution)
        → BI apps / dbt / semantic models (consumers)

Consumers dürfen nicht in die Distribution-Kopie zurückschreiben, als wäre sie der Master. Katalogeinträge sollten sowohl auf das Control-Asset als auch auf seine veröffentlichten Projektionen zeigen (Catalog Deep Dive).

Entscheidungs-Flowchart:

flowchart TD
  A[Control data item] --> B{Shared across consumers?}
  B -->|No| C{Sensitive or audit needed?}
  C -->|No| D[Keep local inline/file with review date]
  C -->|Yes| E[Extract to control DB]
  B -->|Yes| F{Berechtigung or PII-linked?}
  F -->|Yes| G[Hardened control DB + approval]
  F -->|No| H{Business-maintained?}
  H -->|Yes| E
  H -->|No| I[Control DB or repo-synced table with owner]
  E --> J{Need analytics history or wide distribution?}
  G --> J
  I --> J
  J -->|Yes| K[Publish snapshots to WH and/or lake]
  J -->|No| L[Consumers read control DB or thin API]
  K --> M[BI / dbt / models consume publish layer]
  L --> M
  K --> N[Never edit lake/WH CSV as SoT]
  N --> E

Dokumentieren Sie jede nicht-triviale Platzierung als leichte Architekturentscheidung, damit das nächste Team die Debatte nicht neu entdeckt.

Checkliste

• Classification Card als vollständig bestätigen;
• Maintain-Store wählen (meist Kontrollregel-DB);
• Publish-Targets und Cadence wählen;
• Schema Vereinbarung definieren (stable_id, label, valid_from, …);
• Rollen definieren: Steward, technischer Betreiber, Reader-Rollen für Publish Layer;
• direkte Nutzer-Writes auf Publish-Kopien verbieten;
• editierbare Lake-CSV als SoT verbieten;
• Katalog + Lineage für Kontrollregel- und Publish-Objekte verdrahten;
• INLINE-/Datei-Quellen migrieren und Duplikate löschen;
• Backup-, Migrations- und Access-Review-Cadence setzen;
• für C5 Access-Design vor Produktivstart abschließen;
• Placement Decision Record schreiben;
• erstes Post-Move-Review planen.

Artefakt

Erstellen Sie einen Placement Decision Record (ADR-light) pro Steuerdaten-Familie.

Template-Abschnitte:

1. Title — z. B. Product hierarchy control placement;
2. Status — proposed / accepted / superseded;
3. Context — Links zu Risk Register, Classification Card, Consumers;
4. Decision — Maintain-Store, Publish-Targets, Maintenance-Kanal;
5. Consequences — was sich verbessert, was schwerer wird, Cost/Ops-Notizen;
6. Rejected alternatives — Lake-CSV-SoT, nur-Warehouse-Edit, INLINE belassen usw.;
7. Schema contract — Keys und Validity-Felder;
8. Security — besonders für Berechtigung-Klasse;
9. Owners and review date.

Kurz halten. Ziel ist eine dauerhafte Entscheidung, kein Whitepaper.

Tools

Nutzen Sie RDBMS-Migrations für Control-DB-Schema. Nutzen Sie Steward-UI oder validierten Intake aus Teil 3. Nutzen Sie Orchestrierung zum Publishen von Snapshots. Nutzen Sie dbt oder Warehouse-Jobs für Distribution-Modelle. Nutzen Sie Katalog-Sync für beide Schichten. Nutzen Sie Access-Review-Tooling für C5. Bevorzugen Sie ein Control-DB-Muster pro Organisation, um einen Zoo von One-off-SQLite-Dateien zu vermeiden.

Ressourcen

Bestehende Lookup-Schemas, IAM-Muster, Warehouse-Dim-Konventionen, Lake Landing Zones (nur als Publish-Targets) und frühere ADRs für Master Data.

Schwester-Stories: Steuerdaten klassifizieren, bevor man sie verschiebt, Excel-Schatten-BI und Kennzahlen-Drift, Fachliche Logik außerhalb der BI-Apps halten, Serien-Hubs Building a Modern Data Warehouse, BI-Governance-Entscheidungen, Catalog Deep Dive.