Selbstheilende Daten

1) Definition und Ziele

Selbstheilende Daten sind ein Ansatz des Data Engineering, bei dem Fehler automatisch erkannt werden und Korrekturmaßnahmen (Reparatur, Neulieferung, Rollback, Rekonsolidierung, Neuindizierung) ohne menschliches Zutun oder mit minimalem Eingriff (Human-in-the-Loop für sensible Fälle) durchgeführt werden.
Ziele: Reduzierung der MTTR von Daten, Erhöhung des Vertrauens, Resistenz gegen Drift und Störungen, vorhersehbare Betriebskosten.

2) Typische Ausfälle, die behandelt werden müssen

Schemata und Verträge: inkompatible Änderungen, fehlende Spalten, typische Konflikte.
Qualität/Integrität: Duplikate, Lücken, Verstöße gegen die Eindeutigkeit/referentielle Integrität.
Zeit und Frische: Injizierungsverzögerungen, „Löcher“ in den Fenstern, nicht synchronisierte TZ/Locales.
IDs und Schlüssel: Wechsel des ID-Generators, Kollisionen, schwebende natürliche Schlüssel.
Reihenfolge der Ereignisse: verspätete Ereignisse, Nachbestellung, Neulieferung (at-least-once).
Speicher: Degradation von Partitionen, zerbrochene Dateien/Blöcke, Sharding-Verzerrung.
Rechte/Sicherheit: falsche Masken/Verschlüsselung, PII-Leaks bei Uploads.

3) Säulen der Selbstheilung

1. Datenverträge (Schemas + Regeln) mit automatischen Tests.
2. Idempotente Pipelines (Wiederanlauf ohne Doppeleffekte).
3. Journaling und Reproduzierbarkeit (raw/bronze unveränderlich, lineage).
4. Reparaturmechanismen (replay, backfill, compaction, merge-repair, rebuild).
5. Beobachtbarkeit und SLO (Frische, Vollständigkeit, Einzigartigkeit, Latenz).
6. Entscheidungsrichtlinien (wenn Auto-Fix, wenn wir eskalieren).

4) Verträge und Qualitätsprüfungen

Der Vertrag beschreibt: Schema, zulässige Bereiche, Eindeutigkeiten, RLS/Masking, SLA Frische.

yaml dataset: payments schema:
- name: txn_id; type: string; unique: true
- name: user_id; type: string; not_null: true
- name: amount; type: decimal(18,2); min: 0
- name: created_at; type: timestamp; tz: UTC freshness_sla: 15m constraints:
- "count(distinct txn_id) = count()"
- "pct_null(user_id) < 0. 1%"
privacy:
- mask: card_pan -> BIN6LAST4 actions_on_violation:
- auto_quarantine_partition
- backfill_missing_window
- notify_owner_and_open_ticket

Die Tests werden bei jedem Schritt durchgeführt: Injizieren → Staging → Schaufenster. Ein Regelverstoß aktiviert die Auto-Reparatur (siehe unten) und/oder Quarantäne.

5) Idempotenz und Determinismus

Upsert/Merge durch stabile Schlüssel (SCD2 für Historie, SCD1 für Slices).
Deterministische Transformationen: Ein Eingang → ein Ausgang bei gleichen Parametern.
Versionskontrolle: Notieren Sie die Code-/Diagramm-/Layer-Version und die Datenbeschriftung (Wasserzeichen).
Idempotent sink: Aufnahme über staging + atomic swap/rename.
Exactly-once im Sinne von: acceptable „at-least-once“ transport + idempotent receiver.

6) Auto-Reparatur-Mechanismen (Reparatur-Toolkit)

Replay/Backfill: Neulieferung außerhalb des Fensters't ∈ [T0, T1] 'aus dem unveränderlichen Log (raw).
Reconciliation: Vergleich von Aggregaten/Schlüsseln zwischen Schichten (raw ↔ curated ↔ marts) und zwischen Systemen (Quelle ↔ DWH).
Deduplication: window-dedup nach Schlüssel (txn_id, event_id) + Entfernungsheuristik (fuzzy für „schmutzige“ Schlüssel).
Compaction: Verlagerung kleiner Dateien in große Parties (Parkett/ORC), Neuindexierung.
Merge-repair: bei Datensatzkonflikten Prädikate der Priorität (nach Quelle/Zeit/Version).
Rebuild der Indizes/Materialisierungen: Neuberechnung der Aggregate/cube/roll-up.
Quarantine/Shadow: Verdächtige Parteien werden isoliert; Verbraucher lesen einen „sauberen“ Zweig.
Schema-Mediation: automatischer Projektionswähler (Defaultfüllung, berechenbare Spalten) bei kleineren Änderungen.

7) Speicherschutz und Integrität

Scheckbeträge und Blockvalidierung (CRC, Parität).
Quorum-Speicher (RAFT/Paxos-kompatible Systeme, quorum reads/writes).
Löschcodierung (erasure coding) für kostengünstige Redundanz.
Objektversionierung (object store versioning, undelete).
Atomic commit в Lakehouse (transaction log, ACID-таблицы: Delta/Iceberg/Hudi).

8) Die Reihenfolge der Ereignisse und die „schmutzige Realität“

Verspätete Ereignisse: Halten Sie die Latenz-Fenster, verwenden Sie die Wasserzeichen 'und; Neuberechnung der Fenster.
Neulieferung: dedup durch globale' event _ id', idempotency-keys Tabellen.
Offset-Zeit: TZ-Normalisierung, Speicherung von 'ingested _ at' und 'event _ time'.
Out-of-Order: event_time-basierte Aggregate mit Wasserzeichen-Anpassung.

9) Entscheidungslogik (Policy Engine)

Die Regel lautet: „Welche Anomalie → welche Aktion → welche Schwellen → wer ist der Besitzer“.

yaml policy: payments_freshness detect: freshness_delay > 15m auto_actions:
- trigger: backfill(last_60m)
- if: gap_persisted > 30m then: quarantine_partition(date=today, hour=current_hour)
escalate:
- if: gap_persisted > 60m -> page_oncall:data guardrails:
- do_not_expose_unverified_to_marts

10) Beobachtbarkeit und SLO für Daten

• Frische (Freshness) der Vitrine ≤ 15 Min.
• Vollständigkeit> 99. 5% für Schlüsselfelder.
• Uniqueness: Duplikate <0. 01%.
• Berechnungslatenz: p95 <5 min.
• Reparaturstabilität: MTTR-Daten <30 min.

Metriken und Alerts: Exposed in Prometheus/Grafana; Erstellen Sie einen priorisierten Feed mit Datenvorfällen.

11) Wiederkonsolidierung und Abstimmungen (Praktiken)

Abgleich der Aggregate: 'count/sum/min/max' zwischen den Schichten/Systemen am Schiebefenster.
Schlüsselüberleitung: symmetrische Differenz der Mengen 'Δ = (A\B) ∪ (B\A)'.
Periodischer „Audit-Job“: Vergleich mit der Quelle, Stichprobenprüfung am Primus.
Zahlungen/Finanzen: Doppeleintrag (Double-Entry), Tagecut-off-Abstimmungen, Anpassungsprotokoll.

12) Schaltungsmanagement und Evolution

SemVer für Schemas: MAJOR (bricht )/MINOR (fügt hinzu )/PATCH (korrigiert).
Verträge in CI/CD: schema-diff, Interoperabilität, Autogenerierung von Migrationen.
Backfill-Haken: bei MINOR Defaults/berechenbare Felder hinzufügen, Schaufenster neu berechnen.
Flexible Projektionen: Leser lesen Teilmengen von Spalten; Wir verbieten „SELECT“.

13) Sicherheit, Privatsphäre, Compliance

RLS/CLS: Zeilen-/Spaltenfilter, insbesondere in Reparaturzweigen und Exporten.
PII-Masking: deterministisch (Tokenisierung) für eine nachhaltige Deduplizierung.
Zugriffs-/Exportprüfung: Wer hat gesehen, was exportiert wurde, wohin er gesendet hat.
DSAR/Retention: automatische Löschung/Anonymisierung in Reparaturprozessen; Pullbacks berücksichtigen rechtliche Anforderungen.

14) Kosten und Leistung

Cost-aware backfill: Begrenzung der Fensterbreite (z.B. gleitende 3-7 Tage).
Materialisierungen und Caches: Neuberechnung nur veränderter Parteien (incremental).
Priorisierung: erst kritische Schaufenster (Finanzen, Risiken), dann analytisch.
Off-peak Reparaturen: Nachtfenster/niedrige Priorität im Planer.

15) Prüfung und Simulation von Vorfällen

Chaos-Data-Testing: Zerbrechen Sie Parts/Schemas absichtlich auf einem Stage.
Gefälschte Verzögerungen: Simulieren Sie Auslassungen von Schlachten, Out-of-Order, Duplikaten.
Goldene Daten: Benchmarks für den Abgleich nach der Reparatur.
GameDays: Regelmäßiges Teamtraining auf Runbooks.

16) Antipatterns

„Unsichtbare“ Korrekturen: Stille Korrekturen ohne Prüfung und Berichterstattung.
Unprotokollierte Backfill's: keine Quelle der Wahrheit/Version der Formeln.
Schwere Live-Anfragen an OLTP während der Reparatur: Sie beenden prod.
SELECT in Consumers: bricht bei jeder MINOR-Änderung.
Einziger Deduplizierungsschlüssel: keine Fallback-Schlüssel/Hash-Signaturen.

17) Umsetzungsfahrplan

1. Discovery: kritische Sets/Metriken, Risiken, Eigentümer; Abhängigkeitszuordnung.
2. Verträge und Tests: Formalisierung der Regelungen in der CI; Glossar veröffentlichen.
3. Idempotenz: Umschreiben der wichtigsten Pipelines auf upsert/merge, atomic sink.
4. Raw-Journal und Lineage: unveränderliche Ebene, vollständige Metadaten, Wasserzeichen 'und.
5. Reparatur-Mechaniker: backfill/replay, dedup, compaction, quarantine; policy engine.
6. Beobachtbarkeit und SLO: Qualität Dashboards, Alerts, Priority Tape.

7. Chaos-Daten und Training: regelmäßige Übungen + runbook'i

8. Kostenoptimierung: inkrementelle Neuberechnungen, Fensterpriorisierung.

18) Checkliste vor Veröffentlichung

• Datenverträge und Qualitätsprüfungen decken kritische Sätze ab.
• Piplines sind idempotent; Es gibt Atomic Commit und Rollbacks.
• Backfill/Replay und Quarantine eingerichtet, Eskalationsrichtlinien vorgegeben.
• Freshness/Completeness/Uniqueness/Latency Metriken und Alerts in der Produktion.
• Auditing von Revisionen/Reparaturen enthalten; Versionen von Formeln und Vitrinen werden gespeichert.
• DSAR/Retention werden bei Reparaturen und Rollbacks eingehalten.
• Es gibt ein runbook 'und, Übungen durchgeführt, MTTR-Ziel fixiert.
• Die Kosten für Backfill's sind durch Budgetgarden begrenzt.

19) Beispiele für Auto-Aktivitäten (Vorlagen)

„Frischefehler Vitrine X“ → backfill (last_2h) → wenn nicht in etwa 30 Minuten → quarantine + on-call-Seite.
„Splash Duplicate txn_id“ → eine strenge dedup + Abgleich mit der Quelle → einen Bericht über die Ursachen.
Die „MINOR-Änderung des Schemas“ → ein berechenbares Default-Feld → Rebuild-Aggregate erzeugen.
Der „Verlust von Parteien“ → aus dem versionierten Objekt wiederhergestellt werden → Verifizierung mit einem Scheckbetrag.

Fazit: Selbstheilende Daten sind nicht ein einziges „Reparaturskript“, sondern eine Systemarchitektur: formale Verträge, idempotente Pipelines, zuverlässiges Logging, automatisierte Reparaturmechaniken und transparente Beobachtbarkeit mit strengen SLOs. Ein solches System repariert sich nicht nur selbst, sondern verwandelt Vorfälle in überschaubare Ereignisse mit nachvollziehbaren Kosten und Wiederherstellungszeiten.