Herkunft der Daten

Herkunft der Daten (Lineage)

1) Was ist Lineage und warum wird es benötigt

Data Lineage ist ein formaler Datensatz „woher die Daten kamen, wie sie transformiert wurden, wo und von wem sie verwendet wurden“. Das Ergebnis ist ein orientierter Abhängigkeitsgraph mit Attributen (Zeit, Versionen, Besitzer, Transformationen, Zugriffsrichtlinien, Qualität), der das Datensystem erklärbar und auditierbar macht.

• Transparenz der Metriken (Finanzen, Produkt, Risiko): "Warum ist die Zahl X = 1.234? ».
• Schnelle Impact-Analyse von Änderungen (Schema/Job): „Was wird brechen, wenn“....
• Compliance und Audit (DSGVO/ISO/SOC): Nachweisbarer Feldweg.
• Beschleunigung von Onboarding und Reduzierung von Toil (Self-Service-Wissen).
• Qualitätsverbesserung: Gezielte Kontrollen, wo das Risiko höher ist.

2) Abdeckungsbereiche und Detaillierungsgrade

Streaming-Ebene (Pipeline/Job): Welche Jobs/Orchestratoren die Datasets hervorgebracht haben.
Dataset-Ebene (table/view/topic/file): Ein- → Ausgänge, Versionen/Snapshots.
Spaltenebene (column/feature-level) - Wie jedes Feld berechnet wird, aus welchen Quellen.
Verbrauchsschicht: BI-Berichte, APIs, ML-Modelle, Dashboards und Warnungen.

Für kritische Entitäten (Geld, Regulator) - Column-Level-Detaillierung ist obligatorisch.

3) Lineares Datenmodell: Schlüsseleinheiten

Dataset: `{urn, type, schema, owners, pii_class, retention, tags}`

Job/Task: `{urn, code_ref, version, runtime, schedule, owners}`

Run/Execution: `{run_id, job_urn, start/end, status, inputs[], outputs[], code_sha, infra}`

Feld:'{dataset _ urn, name, type, derivation}'(Ableitung - Ausdruck/AST/Operator).

Policy: `{dataset_urn/field, access_rules, masking, consent_scope}`

Quality Check: `{check_id, scope, rule, severity, result}`

4) Lineagequellen: aktive vs passive Montage

Aktiv (event-based): Wir instrumentieren Orchestratoren/Engines (Spark/DBT/SQL engines/Kafka) zur Ausgabe von „job started/finished, inputs/outputs, column-mapping“ -Ereignissen.

Vorteile: Genauigkeit, Relevanz, Minimierung von Post-Parsing.
Passiv (Inferenz): DAG 'und Parsim, SQL/DDL/Log-Abfragen, Verzeichnis-/Speicherprotokolle; Wir bauen Abhängigkeiten rückwirkend auf.

Vorteile: schnelle Abdeckung des Erbes; Nachteile: niedrigere Genauigkeit auf Spaltenebene.

In der Regel wird ein Hybrid verwendet: aktive Ereignisse, wo möglich, und passive Analyse als „Versicherungsnetz“.

5) Lösungsarchitektur (Benchmark)

Produzenten (Orchestratoren/Engines) → Ereignisbus lineage → Normalizer → Graphenspeicher → Index/Suche → UI/API/Alert → Export/Verzeichnis.

Events: vereinheitlicht (job/run/dataset/column-lineage), mit URN-IDs und semantischen Versionen.
Graphenspeicher: column-level graph (z.B. auf Basis eines Graphen-DB oder relational + inverted index).
UI: interaktive Visualisierung der kürzesten Wege, Impact/Root-Ursache, „Qualitätssignale“ an Rippen und Knoten.
Integrationen: Datenkatalog, Qualitätssystem (DQ), Zugriffssteuerung (ABAC), Audit (nur Append-Protokolle).

6) Kennungen und Versionierung

URN/Global ID für jeden Dataset/Joba/Feld: stabil, menschenlesbar, einschließlich Plattform/Neymspace/Name/Version.
Schemaversionen (SchemaVersion) und Codeversionen (Code SHA, Image Digest).
Time-Travel-Lineage: Reproduzierbarkeit von Untersuchungen.

7) Column-level lineage: wie man authentisch wird

SQL-Parsing mit AST-Konstruktion und Normalisierung von Alias/STE/Vruh.
Anmerkungen im Transformationscode (DBT-Tests, primitive Kommente, UDF-Metadaten).
Ereignisse aus Engines: Geben Sie die Ausdrücke "target. col = f(src. a, src. b)».
Semantische Regeln: UDFs/Aggregations-Ops werden als „lossy“ (mit Granularitätsverlust) oder „sensitive-preserving“ (überträgt PII-Tags) markiert.

8) Verknüpfung von Lineage mit Privatsphäre und Sicherheit

Privacy by Design: Feldbeschriftungen 'pii _ class', 'consent _ scope', 'retention'. Bei der Propagierung von Spalten werden Tags nach Regeln übertragen (z. B. "E-Mail → hash_email' bleibt PII-derived).
Tokenisierung PII: lineage speichert die Tatsache der Tokenisierung/Detokenisierung und Token-Service-Knoten; jede Entgiftung ist ein Ereignis mit Audit.
Verschlüsselung: Für AEAD/FPE-Felder erfasst die Linie den „Krypto-Status“ und den Schlüsselbereich (tenant/scope) - ohne die Schlüssel preiszugeben.
Audit und WORM: Lineageereignisse und Richtlinienänderungen werden in einem unveränderlichen Protokoll gespeichert (Append-only mit Hash-Ketten).

9) Datenqualität und SLO basierend auf Lineage

Schecks auf den Rippen: Frische (Frische), Vollständigkeit (Vollständigkeit), Einzigartigkeit/Schlüssel, Drift der Verteilungen.
SLO/SLI: „95% der Jobs, die die Phinotcount-Metriken liefern, sind ≤ 06:00 UTC abgeschlossen“.
Root-cause: graph + Ausführungszeiten geben eine schnelle Definition des „ersten gebrochenen Knotens“.

10) Impact Analyse und Change Management

Bei geplanter Änderung des Schemas/der Logik: in der nachgeschalteten Spalte (Downstream) - Liste der betroffenen API-Berichte/Modelle/Clients.
„Breaking changes“ -Richtlinie: obligatorische Benachrichtigung der Besitzer von Downstream-Artefakten, Grace-Periode, parallele Versionen ('v1 '/' v2') und „Sunset-date“ -Flag.
Automatische PR/Tickets mit Verbraucherliste und Migrationscheckliste.

11) Integration mit Orchestratoren und Engines

Orchestratoren: Vor/nach dem Job werden die Ereignisse' RunStarted/RunCompleted 'mit Inputs/Outputs ausgegeben.
SQL/ELT: Konnektoren zu den Engines (Warehouse, Lakehouse), um den eigentlichen Ausführungsplan und das Spaltenmapping zu erhalten.
Stream-processing: Lineage von Nachrichten (topic→topic, Key/Header), Avro/Protobuf-Schemata, Entwicklung von Schemata durch Registry.
ML: Lineage von Artikeln/Datasets, Modellversionen, Trainingsartefakten, Merkmalsquellen.

12) Modellierung von Etikettenverbreitungsregeln (Datenverträge)

Datensatzvertrag: Schema + Semantik der Felder (Schlüssel, PII, Aggregierbarkeit, Lizenzen/Rechtsgrundlagen, Retention).

• 'SELECT a, b FROM T' → die Markierungen'a, b 'übertragen.
• 'hash (email)' → das Label 'PII-derived (pseudonymized)' mit dem Verbot der Entgiftung.
• „SUM (amount)“ → Verlust der Individualität; Join's sind im Ergebnisfeld verboten.
• Verträge werden im CI validiert (Blocker bei Nichtkonformität) und Verstöße sind Ereignisse im Audit.

13) Leistung und Maßstab

Inkrementelle Injektion von Lineageereignissen; Deduplizierung nach'(run_id, job_urn)'.
Graphenspeicherung: Trennung von Hot Index (letzte 30-90 Tage) und Archiv; Schnappschüsse.
Pfadcaching für häufige Abfragen (kurze Wege zu „goldenen“ Metriken).
Sharding für Neymspaces/Mieter; Schutz vor „Monster-Knoten“ (Fan-Out-Beschränkung).

14) Visualisierung und UX

• Pfad zu metrisch: „woraus die Metrik zusammengesetzt ist“.
• Impact from source: „wer wird von der Änderung betroffen sein“.
• Feldlinie: „wie das Feld berechnet wurde“.
• Overlays: Jobstatus, Qualität, PII-Tags, Retentionen, Besitzer.
• Aktionen: Vertrag öffnen, Migrationsticket erstellen, Änderungsalarme abonnieren.

15) Sicherheit des Zugangs zum Graphen

ABAC: Die Sichtbarkeit von Knoten/Kanten ist auf Mieter/Rollen beschränkt.
Redaction: Ausblenden der Namen sensibler Felder (oder deren Pseudonymisierung) in der Benutzeroberfläche für ungeübte Rollen.
mTLS/OIDC für API; lineage-Ereignisse werden mit Service-Identitäten signiert.
WORM und Lesekontrolle: Auch das Lesen kritischer Graphensegmente wird protokolliert.

16) Betrieb: SLO, Überwachung, Warnungen

SLO des Graphen: Verzögerung des Auftretens des Ereignisses <5 min; Vollständigkeit der Beschichtung> 98% der kritischen Piplines; 100% der „Goldmetriken“ haben eine Spaltenlevel-Linie.
Alerts: Kettenbruch, Run ohne Abschlussereignisse, Inkonsistenz der Schemata, „verwaiste“ Datasets, Fan-Out/Cycle-Wachstum.
Berichte: Wöchentlicher „State of Lineage Coverage“, Top-10-Risikoknoten.

17) Datenschutz und Compliance (Bündel)

DSGVO/PbD: Speichern Sie die Grundlagen der Verarbeitung und der Retentionen als Tags; lineage ermöglicht eine schnelle DSAR-Pfadsuche und ein „Recht auf Löschung“ durch kaskadiertes Krypto-Löschen der entsprechenden Segmente.
Secret Management: Quellen für den Zugang zu Rohstoffen fallen nie als offene Credits in die Lineage; Nur der Verweis auf die Rolle/Richtlinie wird gespeichert.
Audit/unveränderliche Protokolle: Alle Lineage-Ereignisse sind signiert und im Append-only-Speicher verankert (siehe entsprechenden Artikel).

18) Checklisten

• Die URN-Konventionen für datasets/jobs/fields sind definiert.
• Die Ausgabe von Lineage-Ereignissen aus Orchestratoren und Engines ist enthalten.
• SQL/DDL Parser und Schema Normalizer arbeiten.
• Genehmigte Daten-Verträge und Regeln für die Verbreitung von PII/Retentionen.
• WORM-Ereignisprotokoll und Graph-Backups konfiguriert.
• BI/ML sind als Konsumenten der Lineage (Reports, Models, Fiches) verbunden.

• Abdeckung der Lineage für kritische Domains ≥ 98%, Column-Level für „Geld“ = 100%.
• Alerts für Brüche, „verwaiste“ Datasets, Schaltplandrift inklusive.
• Vierteljährliche Prüfung von PII-Labels und Verträgen.
• Dokumentenmanagement von Änderungen (Breaking) und Versand an Verbraucher.

19) Mini-Rezepte

json
{
"event": "RunCompleted",
"run": {
"id": "run_2025-10-31T14:20:00Z_42",
"job": "urn:job:etl:finance:close_books_v3",
"status": "SUCCESS",
"code_sha": "b3f9…",
"started_at": "2025-10-31T14:05:00Z",
"ended_at": "2025-10-31T14:19:52Z"
},
"inputs": [
"urn:dataset:lake:bank_txn_v2",
"urn:dataset:warehouse:fx_rates_d+1"
],
"outputs": [
"urn:dataset:warehouse:pnl_daily_v3"
],
"column_lineage": [
{
"output": "pnl_daily_v3. pnl_usd",
"expr": "SUM(txn. amount_local fx. rate)",
"inputs": ["bank_txn_v2. amount_local", "fx_rates_d+1. rate"],
"lossy": true
}
]
}

if input. field. pii in {email, phone, id} and transform in {hash, tokenize}:
output. field. pii = "pseudonymized"
elif transform in {aggregate, anonymize_k}:
output. field. pii = "anonymous"
else:
output. field. pii = input. field. pii

affected = downstream(urn:"urn:dataset:warehouse:users_v4", depth=4)
filter affected where kind in {"dashboard","model","api"} and owner not in {"team-exp"}

20) Häufige Fehler und wie man sie vermeidet

Lineage „nach Bild“ ohne formales Modell. Sie benötigen Ereignisse/Diagramme/URNs, sonst wird der Graph nicht skaliert.
Es gibt kein Spaltenniveau, wo „Geld“ ist. Ohne die Spaltenebene kann man die Berechnungen nicht erklären.
Unvollständige Ereignisse (ohne code_sha/versii Schemata). Reproduzierbarkeit ist nicht möglich.
Ignoriere die Privatsphäre. PII-Tags müssen mit den Feldern leben und getragen werden.
Eine große Grafik-DB ohne Sharding. Teilen Sie die Nijmspaces, speichern Sie die Schnappschüsse.
Blinder Glaube an die Parser. In umstrittenen Fällen - aktive Ereignisse aus den Motoren.

21) Runbook’и

Der Vorfall: Die Metrik „sprang“.

1. Öffnen Sie „Path to metric“ → überprüfen Sie die letzten „Run“ -Knoten auf dem Pfad.
2. Überprüfen Sie die Versionen des Codes/Schemas, den DQ-Status der Schecks auf den Kanten.
3. Wenn ein gebrochener Link gefunden wird - Erstellen Sie ein Ticket für den Besitzer, aktivieren Sie das temporäre „Halten“ der Metrikpublikation.
4. Nach dem Fix markieren Sie den RCA und verknüpfen ihn mit den Knoten des Graphen.

Ändern des Quellschemas.

1. Fordern Sie einen Impact Downstream an.
2. Senden Sie Benachrichtigungen an die Eigentümer, erstellen Sie PR's Migration.
3. Parallel'v _ next 'anheben, beide Versionen bis zum Sunset-Datum halten.
4. Schließen Sie'v _ prev', aktualisieren Sie Verträge und lineage-graph.

• «Privacy by Design (GDPR)»
• „Tokenisierung von PII-Daten“
• „Management von Geheimnissen“
• „Audit und unveränderliche Protokolle“
• „At Rest/In Transit Verschlüsselung“
• „Schlüsselmanagement und Rotation“