Zusammenführen von Daten aus verschiedenen Quellen

Zusammenführen von Daten aus verschiedenen Quellen

Datenfusion ist der Prozess der Zusammenführung heterogener Ströme (Produkt-DBs, CRMs, Zahlungsanbieter, Ereignisprotokolle, Register von Drittanbietern) zu ganzheitlichen Entitäten und konsistenten Vitrinen. Ziel ist es, einen „Golden Record“ und konsistente Schnitte für Analysen, MLs und operative Fälle zu erhalten.

1) Typische Szenarien und Ziele

360 ° im Wesentlichen: Kunde/Spieler, Gerät, Zahlungsinstrument, Merchant.
Transaktionskonsolidierung: Mehrere PSPs/Kassen → ein einziges Protokoll mit obligatorischer Idempotenz.
Ereignisnormalisierung: Web/Mobile/Backend-Protokolle → ein einheitliches Ereigniswörterbuch.
Bereicherung: externe Verzeichnisse (Geo, FX, AML/Sanktionen, Marketingquellen).
Einheitliche Metriken: Aushandlung von Währungen/Zeitzonen, Schemata und Kodierungen.

2) Quellverträge und Schemata

• Schema: Felder, Typen, Nullwert, Schlüssel (s), Wertdomänen.
• Semantik: was jedes Feld (Wörterbücher) bedeutet.
• SLA: Frische/Frequenz, maximale Latenz und Out-of-Order.
• Evolution: Politik der Änderung von Schemata (backward/forward), deprecation.
• Qualität: Einzigartigkeit der Schlüssel, zulässige Bereiche, referentielle Integrität.

3) Identifizierung: Schlüssel und Zuordnung (record linkage)

3. 1. Starre IDs

Natürliche Schlüssel: 'user _ id', 'transaction _ id', 'device _ id', 'iban'.
Proxy-Schlüssel: E-Mail/Telefon (mit Normalisierung: Register, Leerzeichen, Ländercodes).
Surrogate: 'surrogate _ id' in Hub-Tabellen, wenn kein Universalschlüssel vorhanden ist.

3. 2. Weiche Zuordnungsregeln

Deterministisch: genaue Übereinstimmung der normalisierten E-Mail + DR; „Haus „/“ Handy “Telefon → E.164.
Probabilistisch (Fuzzy): Jaro-Winkler/Levenshtein für Name/Adresse, TF-IDF/Embedding für Strings, „Lock“ (blocking) durch grobe Hashes/Präfixe zur Beschleunigung.
Graphansätze: Entitäten als Knoten, Übereinstimmungen als Kanten; Clustering der Konnektivitätskomponente.
Die „Step-up“ -Strategie: Von strengen zu weichen Regeln mit Handrevue „an der Grenze“.

3. 3. Konsolidierungsregeln (Survivorship)

Quellpriorität: "KYC-Registry> CRM> Logs' bei Wertekonflikten.
Frische: Der neuere Zeitstempel gewinnt (glaubwürdigkeitsbereinigt).
Füllung: prefer non-NULL; Zusammenführen von Adressen/Tags durch Zusammenführen von Mengen.
Audit: Behalten Sie den „Lösungsweg“ - was überschrieben wurde und warum.

4) Deduplizierung und MDM

MDM-Layer (Master Data Management): „Master Entity“ -Tabellen + „istochnik→master“ -Verknüpfungen.
Golden Record: Ein aggregierter Datensatz mit einem 'confidence' -Feld/einer Quelle der Wahrheit.
Historie: SCD-Typ 2 für zeitabhängige Attribute (Adresse, KYC-Status).
Identitäten: Merge-Map-Tabellen mit den Daten der „Fusion „/„ Verbreitung “.

5) Änderungsströme: CDC, Nachzügler und Duplikate

CDC (Change Data Capture): события `insert/update/delete` + `source_lsn`/offset.
Verspätete Ereignisse: Wasserzeichen (watermarks) und Wartefenster (grace period), Speicherung von späten Updates für Anpassungen.
Out-of-Order: Sortiert nach Schlüssel und Zeit, um Upgrades auszugleichen.
Duplikate: idempotente Schlüssel ('event _ id', 'idempotency _ key'), Dedup im Fenster.
Exactly-once: Transaktions-Singles/Store, 'MERGE' mit deterministischer Logik.

6) Zeitzonen, Währungen und Kalender

Zeit: Speichern Sie in UTC + lokalisierte Scheiben; explizit 'ingested _ at' und 'event _ time' speichern.
Währungen: Halten Sie „Rohwährung“ und normalisiert 'base _ ccy' mit dem Kurs am Datum der Transaktion.
Kalender: Feiertags-/Arbeitstagstabellen nach Region für ehrliche Vergleiche.

7) Pseudo-SQL für Merge (upsert/merge)

7. 1. Transaktionen (idempotentes Protokoll)

sql
MERGE INTO fact_transactions t
USING staging_transactions s
ON t. txn_id = s. txn_id
WHEN MATCHED AND s. updated_at > t. updated_at THEN
UPDATE SET amount = s. amount,
currency = s. currency,
status = s. status,
updated_at = s. updated_at
WHEN NOT MATCHED THEN
INSERT (txn_id, user_ext_id, amount, currency, status, event_time, updated_at)
VALUES (s. txn_id, s. user_ext_id, s. amount, s. currency, s. status, s. event_time, s. updated_at);

7. 2. „Goldener Eintrag“ des Benutzers (Quellpriorität + Frische)

sql
WITH ranked AS (
SELECT s. ext_user_id,
s. norm_email,
s. phone_e164,
s. addr_struct,
s. source,
s. updated_at,
ROW_NUMBER() OVER (
PARTITION BY s. ext_user_id
ORDER BY
CASE s. source
WHEN 'KYC' THEN 1 WHEN 'CRM' THEN 2 ELSE 3 END,
s. updated_at DESC
) AS rn
FROM staging_users s
)
MERGE INTO dim_user_golden g
USING ranked r
ON g. ext_user_id = r. ext_user_id
WHEN MATCHED AND r. rn = 1 THEN
UPDATE SET email = COALESCE(r. norm_email, g. email),
phone = COALESCE(r. phone_e164, g. phone),
address = COALESCE(r. addr_struct, g. address),
source_of_truth = r. source,
updated_at = r. updated_at
WHEN NOT MATCHED AND r. rn = 1 THEN
INSERT (ext_user_id, email, phone, address, source_of_truth, updated_at)
VALUES (r. ext_user_id, r. norm_email, r. phone_e164, r. addr_struct, r. source, r. updated_at);

8) Qualität und Prüfung

Schematests: Pflichtfelder, Typen, Domänen.
Logiktests: Einzigartigkeit des Schlüssels, keine Duplikate, kein „Zurück in die Zeit“.
Überleitungen (Reconciliation): Summen nach Quelle vs Schlussvitrine; Diskrepanzen → Tickets.
Profiling: Verteilungen, NULL-Anteil, „long tails“.
Merge Metriken: Precision/Recall Mappings, Anteil „CONFLICT“,% der Datensätze mit confidence ≥ Schwelle.

9) Beobachtbarkeit und SLO

SLO Frische: Schaufenster Lag ≤ N Minuten/Stunden; Überwachung von Verzögerungen und Backlog.
Alertas: das Wachstum von Duplikaten, der Anstieg von Konflikten, der Rückgang der Abdeckung von Schlüsseln.
Lineage-Protokolle: Aus welcher Quelle wurde das Feld wann und von wem überschrieben.
Runibuki: Szenarien von Vorfällen (verspätete Chargen, CDC-Sturm, falsche FX).

10) Sicherheit, Privatsphäre, Compliance

PII: Pseudonymisierung, ID-Hashing, Maskierung in BI.
RLS/CLS: Zugriff nach Rolle und Zeile; Export - mit Token und Ablaufdatum.
Lebensdauer der Daten: Speicherpläne; Recht auf Löschung (DSAR) und „legal hold“.
Anti-Join (Re-Identification): Regeln zur Minimierung der Joins empfindlicher Tabellen.

11) Organisation von Modellen und Daten

Schichten: 'raw' (wie es ist) → 'staging' (Reinigung/Normalisierung) → 'core' (master entities, fact/Dimensionen) → 'marts' (vitrinen unter analytica/ML).
SCD: Typ 2 für Attribute, Typ 1 für Fehlerkorrektur; explizit 'valid _ from/valid _ to'.
Feature Store: Transformationsfunktionen sind identisch online/offline; Point-in-Time-Korrektheit.

12) Implementierungsmuster

ELT mit semantischer Schicht: Die Fusionslogik wird deklarativ beschrieben (Regeln, Prioritäten, Schlüssel).
Stream + Microbatch: für Near-Real-Time Showcases - Microbatches 1-15 min mit Wasserzeichen.
Graph-linkage: ein separater Graph-Hub zur komplexen Identifikation (Geräte, Karten, Adressen).
Step-up-Validierung: Neue Linkage-Regeln im Shadow-Modus einbeziehen, Genauigkeitsmetriken sammeln.

13) Checkliste vor Freigabe des Merge Loops

• Die Quellverträge sind unterzeichnet; Schemata und Feldwörterbücher sind konsistent
• Verknüpfungsschlüssel/Regeln definiert; Es gibt eine Deduplizierungsstrategie
• Survivorship-Regeln und Quellenprioritäten festgelegt; Audit-Log aktiviert
• CDC/idempotency/späte Datenverarbeitung implementiert
• Währungen/Zeitzonen/Kalender normalisiert
• Qualitätstests und Abstimmungen werden angepasst; Dashboards der Beobachtbarkeit gibt es
• Die SLO für Frische und Verfügbarkeit sind festgelegt. Alertas und Runibuks sind bereit
• PII/Zugänge/Speicherung erfüllen Compliance-Anforderungen
• Dokumentation: Entity-Datenblatt, Lineage-Schema, Beispielabfragen

14) Pass „Golden Record“ (Vorlage)

Unternehmen: „USER _ GOLDEN“

Schlüssel: 'user _ master _ id' (surrogate), Mappings' source _ user _ id [] '

• „E-Mail“: Normalisierung + Priorität „KYC> CRM> LOGS“
• „phone“: Normalisierung der E.164, Split durch Verifizierung
• `name`: Jaro-Winkler ≥ 0. 92, fallback - Quelle „KYC“
• 'address': zusammengesetztes Objekt; Vereinigung + Frischepriorität
• Geschichte: SCD2 ('valid _ from/valid _ to')
• Lineage: Referenzliste der Spenderfelder
• Qualität: coverage≥98%, dublikaty≤0. 3%
• SLO: Frische ≤ 1 h, Verfügbarkeit ≥ 99. 9%
• Eigentümer: Data Platform, KYC/AML
• Risiken: Namenskollisionen, „Familientelefone“, geteilte Geräte

15) Ergebnisse und Empfehlungen

Die Fusion ist nicht nur ein „JOIN by Key“, sondern eine Kontur: Quellverträge → Identifikation und Dedup → Prioritäten und ein „Golden Record“ → CDC und die Nachzügler → Qualität und Beobachtbarkeit → Sicherheit und Änderungshistorie.
Erstellen Sie Regeln transparent, speichern Sie die Prüfung jeder Entscheidung, unterstützen Sie SCD und exactly-once. So werden Daten aus Dutzenden Quellen zu robusten Vitrinen und nachhaltigen Metriken für Produkt, Analytics und ML.