Datenintegrität

1) Was ist Datenintegrität

Datenintegrität ist eine Sammlung von Eigenschaften und Kontrollen, die sicherstellen, dass Daten über den gesamten Lebenszyklus hinweg korrekt, konsistent und konsistent sind: von Quellen und Transformationen bis hin zu Schaufenstern, APIs und Exporten. Das Ziel ist, dass die gleiche Aussage beim Wiederholen die gleiche Antwort gibt und alle Änderungen rückverfolgbar und überprüfbar sind.

2) Arten von Integrität und wo sie leben

Entity: Eindeutige Primärschlüssel, keine Duplikate.
Referenz (Referential): Korrekte FK-Verknüpfungen; Fehlen von „hängenden“ Links.
Domäne (Domain) - Gültige Bereiche und Formate (Typ, Länge, Verzeichnisse).
Geschäftsregeln: Invarianten des Fachgebiets (Saldo ≥ 0, Summe der Buchungen = 0 usw.).
Temporal: Monotonie und Konsistenz der Zeitstempel, korrekte Zeitzonen.
Zugriffsrichtlinien: RLS/CLS verletzt nicht die logische Konsistenz der sichtbaren Daten.

3) Datenverträge und Schemata (Quelle der Wahrheit)

Wir stellen formale Verträge für Sets und Events; sie am Eingang und nach jeder Transformation anwenden.

yaml dataset: payments primary_key: txn_id foreign_keys:
- fk: user_id -> users.user_id 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: currency, type: string, in: [USD,EUR,TRY,UAH]}
- {name: event_time, type: timestamp, tz: UTC}
dq_rules:
- "duplicates(txn_id)=0"
- "ref_integrity(user_id, users.user_id)=true"
- "sum(amount) >= 0"
evolution:
semver: [MAJOR, MINOR, PATCH]
breaking_changes_require: approval:data-governance

4) Transaktionsgarantien und Insellage

ACID für OLTP: Atomarität, Konsistenz, Isolierung, Haltbarkeit.
Isolationsstufen: Read Committed/Repeatable Read/Serializable - Wählen Sie unter dem Risiko „schmutziger „/einzigartiger/Phantomlesungen.
OLAP und Lakehouse: atomare Commits von Tabellen (Transaktionsprotokoll), idempotent sink und schema-evolution mit Kompatibilitätskontrolle.
Konsistenz von KPI-Formeln: Semantische Ebene → eine Wahrheit für Berichte und APIs.

5) Verteilte Systeme: Ordnung, Wiederholungen, Idempotenz

Reihenfolge der Ereignisse: verwenden Sie' event _ time'+ 'ingested _ at', Wasserzeichen und Latenz Toleranz; Aggregate basierend auf der Ereigniszeit.
Re-Delivery (at-least-once): global 'event _ id', Tabellen idempotency keys, upsert/merge nach stabilem Schlüssel.
Out-of-Order: Neuberechnung von Fenstern, Verzögerungsstrategie, Entschädigung.
Exactly-once im Sinne von: Transport kann at-least-once sein, Empfänger ist idempotent.

6) Integritätsvalidierung (DQ) auf jeder Schicht

• Freshness/Completeness/Uniqueness/Valid Values/Referential Integrity.
• Anomalien: Ausbrüche von Duplikaten, Zeitlücken, abrupte Verschiebungen von Verteilungen.
• Kontrolle der KPI-Formeln: Versionierung der Berechnungen und Tests auf Übereinstimmung der Ergebnisse (goldene Sätze).
• Exportkontrolle: Verbot der Ausgabe von Sets mit Verstößen (Quarantine).

yaml expect_column_values_to_be_unique: {column: txn_id}
expect_column_values_to_not_be_null: {column: user_id}
expect_column_values_to_be_in_set: {column: currency, value_set: [USD,EUR,TRY,UAH]}

7) Finanzielle und operative Integrität

Double-entry (doppelter Eintrag): Lastschrift/Gutschrift in der Bilanz; Zusammenfassungen in cut-off.
Endgültige Invarianten: Auszahlungsbetrag = Betrag der Abschreibungen + Gebühren + Anpassungen.
Betriebliche Invarianten: SLA/Guardrail-Metriken brechen keine Geschäftsregeln (z.B. Auto-Reparatur erzeugt keine Duplikate).

8) Lineage, Audit und Reproduzierbarkeit

Linie: von der Quelle bis zu den Schaukästen/fich; Sichtbarkeit von Transformationen und Eigentümern.
Audit-Trails: Wer hat was, wann und warum geändert; Versionen von Schemas/Formeln/Jobs.
Snepshots/Checkpoints: Fähigkeit, vergangene Berichte neu zu berechnen und zu bestätigen.
Repro: Dieselbe Abfrage auf demselben Slice → dasselbe Ergebnis (Versionen und Ebenen).

9) Sicherheit und Privatsphäre ohne Verlust der Integrität

RLS/CLS: Zeilen-/Spaltenfilter dürfen Invarianten nicht verletzen (z.B. muss die Summe aus dem sichtbaren Sample mit der deklarierten übereinstimmen).
Maskierung/Tokenisierung: deterministische Strategien, um die Dedup- und referentielle Integrität zu erhalten.
Verschlüsselung: im Kanal und „auf der Festplatte“ nach der Komprimierung; Schlüsselverwaltung und Zugriffsprüfung.
DSAR/Retention: Löschung/Anonymisierung bricht die Konnektivität nicht (Kaskadenrichtlinie).

10) Self-Service und Reparaturautomatik

Quarantine: Isolierung von verdächtigen Parteien/Schlachten; Verbraucher sind ein „sauberer“ Zweig.
Replay/Backfill: Wiederholung eines Fensters aus einem unveränderlichen Raw-Log.
Reconcile: Schichten und Systeme (raw↔curated↔marts; istochnik↔DWH).
Dedup/Compaction/Rebuild: Systemverfahren zur Reparatur von Indizes/Aggregaten.
Policy-as-Code: „Welche Anomalie → welche Aktion → Schwellenwerte → Eskalation“.

11) Modellierungs- und Speicherpraktiken

Stabile Schlüssel: Surrogat PK (UUID/ULID), unveränderliche natürliche Schlüssel in Verzeichnissen.
Normalizatsiya↔denormalizatsiya: FK-Verbindungen in Quellen, denormalisierte Vitrinen mit Versionskontrolle der Logik.
SCD1/SCD2: Verwaltete Historie für Messungen.
Sortieren/Clustern: Verbessert RLE/Zone-Maps und vereinfacht Abstimmungen.
Hashes und Prüfsummen: Prüfung der Integrität von Dateien/Parties.

12) Integrität in der Zeit und in der Berichterstattung

Formelversionen: Der Bericht für Januar 2025 sollte die Formel für Version X sein.
Cut-off und „Periodenschluss“: Einfrieren von Schaufenstern und Archivscheiben.
Late arriving facts: Mechanik der Dosierung und Neuberechnung mit Versionsstempel des Berichts.
Überschreibungen dokumentieren: Manuelle Anpassungen - nur mit Audit.

13) Integrationen und APIs

API-Vertrag: Schemata, Typen, Pflichtfelder, Fehlercodes; Versionierung (v1/v2).
Validierung am Eingang: reject schlechte payload's, nicht „reparieren in der Stille“.
Idempotente POST: Schlüssel der Idempotenz, Wiederholung sicher.
Export in Dateien: Konsistenz von Parties, Hashes, Signaturen.

14) Antipatterns

SELECT in Prod Requests und Views - bricht mit MINOR Evolution.
FK „in Worten“: keine echte Linkprüfung.
Stille Datenkorrekturen ohne Prüfung und Berichterstattung.
TZ und Zeitformate in einem Satz mischen.
Überschreibungen von KPIs durch „Stifte“ ohne Versionen und Protokolle.
Der einzige Deduplizierungsschlüssel ohne redundante Strategien.
Löschen über DSAR ohne Kaskadenprüfung von Links.

15) Fahrplan für die Umsetzung

1. Inventar & Kritikalität: Set/Event-Karte, Besitzer, Risiken, Invarianten.
2. Verträge und Schemata: Formalisierung von Typen/Einschränkungen/FK, CI-Kompatibilitätsprüfungen.
3. DQ in der Pipeline: Freshness/Completeness/Uniqueness/RI, Quarantine, Alerts.
4. Transaktionsbasis: atomic-sink, upsert/merge, SCD-history, Versionierbarkeit der Formeln.
5. Lineage und Audit: Verzeichnis, Trace, Change-Logs, Access-Logs.
6. Reparaturrichtlinien: replay/backfill/dedup/reconcile als Code; runbook’и и SLO MTTR-data.
7. Sicherheit/priv: RLS/CLS, Masking, Verschlüsselung, DSAR-Prozesse.
8. Reporting: Cut-off, Freeze-Slices, KPI Versionierung.

16) Checkliste vor der Veröffentlichung des Sets/Showcase

• PK/FK und Domänenbeschränkungen sind festgelegt und bestehen die Tests.
• Die Versionierung von Schemata/Formeln ist enthalten; schema-diff grün.
• DQ-Regeln (Frische/Vollständigkeit/Einzigartigkeit/Bereiche/RI) grün.
• Idempotente Einträge: upsert/merge, Schlüssel der Idempotenz (für Ereignisse).
• Zeit: 'event _ time' und 'ingested _ at', TZ = UTC; Richtlinie late data.
• Lineage und Audit sind sichtbar; enthalten sind Quarantine und Alerts.
• RLS/CLS/Masking verletzt Invarianten und RI nicht.
• DSAR/Retention getestet; cut-off/Archiv ist fertig.

17) Mini-Vorlagen

SQL: Überprüfen der referenziellen Integrität

sql select count() as orphans from fact_payments f left join dim_users u on f.user_id = u.user_id where u.user_id is null;
-- ожидаем orphans = 0

Richtlinie quarantine/repair (Pseudo-YAML)

yaml policy: payments_integrity detect:
- rule: duplicates(txn_id) > 0
- rule: ref_integrity(user_id, users.user_id) = false auto_actions:
- quarantine_partition: {date: today}
- trigger_replay: {window: "last_2h"}
escalate_if:
- condition: violations_persist>30m page: "oncall-data"

SCD2 zur Messung

sql
-- dim_user_status (SCD2)
user_id, status, valid_from, valid_to, is_current

18) Ergebnis

Datenintegrität ist keine Einzelprüfung, sondern ein durchgängiges System von Garantien: formale Verträge und Beschränkungen, transaktionale und verteilte Invarianten, Validierung und Automatisierung von Reparaturen, Lineage und Audit, Privatsphäre und Rechte. Wenn diese Elemente zusammenarbeiten, werden Daten zu einer zuverlässigen Grundlage für Entscheidungen, und Vorfälle werden selten, kurz und vorhersehbar.