Fusione dei dati da diverse origini

Fusione di dati da diverse origini

La fusione dei dati è un processo di combinazione di flussi eterogenei (database di prodotti, CRM, provider di pagamenti, loghi di eventi, registri di terze parti) in entità olistiche e vetrine concorsuali. L'obiettivo è di ottenere «Golden Record» e tagli concordati per analisti, ML e valigette operative.

1) Script e obiettivi tipici

360 ° in sostanza: client/giocatore, dispositivo, strumento di pagamento, merchant.
Consolidamento delle transazioni: più PSP/caselle → un unico registro con idipotenza obbligatoria.
La normalizzazione degli eventi: Web/Mobile/Backend-Logi → un unico dizionario di eventi.
Arricchimento: guide esterne (geo, FX, AML/sanzioni, fonti di marketing).
Singole metriche: allineamento valute/timesone, schemi e codifiche.

2) Contratti di origine e schemi

• Schema: campi, tipi, nullità, chiave (e), domini dei valori.
• Semantica: che significa ogni campo (dizionari).
• SLA: freschezza/frequenza, ritardo massimo e out-of-order.
• Evoluzione: criteri di modifica degli schemi (backward/forward), deprecation.
• Qualità: unicità delle chiavi, intervalli validi, integrità arbitrale.

3) Identificazione chiave e mappatura (record linkage)

3. 1. Identificatori rigidi

Chiavi naturali: «user _ id», «communication _ id», «device _ id», «ban».
Chiavi proxy: e-mail/telefono (con normalizzazione: maiuscole, spazi, codici di paese).
Surrogati: «surrogate _ id» nelle tabelle hab, se non c'è una chiave universale.

3. 2. Regole di mappatura morbide

Determinati: corrispondenza esatta e-mail normalizzata + DR; "casa "/" mob" telefono "E.164.
Probabili: Jaro-Winkler/Levenshttein per nome/indirizzo, TF-IDF/embedding per righe, Blocking per hash/prefissi per accelerare.
Approcci grafici: entità come nodi, corrispondenze come nervature; clustering componente connettività.
La strategia «step-up» è da regole rigide a regole morbide con «al confine».

3. 3. Regole di consolidamento (survorship)

La priorità dell'origine è «Registro di sistema di KYC> CRM> login» quando c'è un conflitto di valori.
Freschezza: un'etichetta temporale più recente vince (con correzione di veridicità).
Riempimento: prefer no-NULL; Unire indirizzi/tag combinando molteplici.
Controllo: mantieni la traccia della soluzione - cosa è stata sovrascritta e perché.

4) Deduplicazione e MDM

Livello MDM (Master Data Management) - Tabelle Entità Master + Relazioni istochnik→master.
La Golden Record è una registrazione aggregata con il campo «confidence »/fonte di verità.
Cronologia: Tipo SCD 2 per gli attributi che dipendono dal tempo (indirizzo, stato KYC).
Identità: tabelle merge (merge map) con date di fusione/accensione.

5) Flussi di cambiamento: CDC, ritardi e duplicati

CDC (Change Data Capture): события `insert/update/delete` + `source_lsn`/offset.
Eventi in ritardo: etichette ad acqua (watermarks) e finestre di attesa (grace period), archiviazione di update tardivi per le regolazioni.
Out-of-order - Ordina per chiave e ora per compensare gli update.
Duplicati: chiavi idempotenti ('event _ id', 'idempotency _ key'), deduplicazione nella finestra.
Exactly-once: singolo/store transazionale, 'MERGE', con logica determinata.

6) Timeson, valute e calendario

Tempo - Memorizzare in UTC + tagli localizzati; memorizzare esplicitamente «ingested _ at» e «event _ time».
Valute: conservare la valuta cruda e la base _ ccy normalizzata con il tasso di cambio alla data dell'operazione.
Calendari: tabelle di festività/giorni lavorativi per regione per confronti onesti.

7) Pseudo-SQL per la fusione (upsert/merge)

7. 1. Transazioni (registro Idempotent)

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. Voce d'oro dell'utente (priorità sorgente + freschezza)

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à e test

Test di schema: campi, tipi, domini obbligatori.
Test logici: unicità della chiave, assenza di duplicati, nessun ritorno nel tempo.
Scorciatoie - Le somme per origine vs sono la vetrina totale; Le discrepanze sono →.
Profilazione: distribuzione, quota NULL, lunghe code.
Le metriche di fusione sono precisione/recall di mappatura, quota «CONFLICT»,% di record con confidence di soglia.

9) Osservabilità e SLO

SLO di freschezza: vetrine ≤ N minuti/ore; monitoraggio dei ritardi e backlog.
L'aumento dei duplicati, l'aumento dei conflitti, la caduta delle chiavi di coverage.
Logi lineage - Da quale origine è stato prelevato il campo quando e da chi è stato sovrascritto.
Runibuki: scenari di incidenti (partite in ritardo, tempeste CDC, FX infedele).

10) Sicurezza, privacy, compilazione

PII: alias, hash ID, occultamento in BI.
RLS/CLS: accesso a ruoli e righe esportazione - con token e data di scadenza.
Durata dei dati: grafica dello storage Diritto di eliminazione (DSAR) e «legale hold».
Anti-connessione (re-identità) - Regole per ridurre al minimo i gioielli delle tabelle sensibili.

11) Organizzazione di modelli e dati

I livelli sono «raw» (com'è) «staging» (pulizia/normalizzazione) «core» (entità master, fatto/misura) «marts» (vetrine di analisi/ml).
SCD: tipo 2 per gli attributi, tipo 1 per la correzione degli errori esplicitamente «valid _ from/valid _ to».
Feature Store: le funzioni di trasformazione sono identiche online/offline; point-in-time è corretto.

12) Modelli di implementazione

ELT con livello semantico: la logica di fusione è descritta dichiaratamente (regole, priorità, chiavi).
Strame + microbiatch: per le vetrine near-real-time - Microbiatchi 1-15 min con watermarks.
Graph-linkage: un singolo grafico hab per l'identificazione complessa (device, mappe, indirizzi).
Convalida di step - Le nuove regole di linkage includono in modalità shadow e raccolgono metriche di precisione.

13) Foglio di assegno prima del lancio del tracciato di fusione

• I contratti delle fonti sono stati firmati; diagrammi e dizionari di campo coerenti
• Chiave/regole di linkage definite; una strategia di deduplicazione
• Le regole e le priorità di origine sono state impostate. controllo-login abilitato
• CDC/idampotenza/elaborazione dati tardivi implementati
• Valute/timeson/calendario normalizzato
• I test di qualità e i controlli sono stati configurati; dashboard di osservabilità
• SLO di freschezza e disponibilità sono registrati; alert e runibuki pronti
• PII/disponibilità/storage soddisfano i requisiti della compilazione
• Documentazione passaporto entità, schema lineage, richieste di esempio

14) Passaporto «record d'oro» (modello)

Entità: «USER _ GOLDEN»

Chiave: 'user _ master _ id' (surrogate), magping'source _ user _ id [] '

• 'email': normalizzazione + priorità 'KYC> CRM> LOGS'
• «phone»: normalizzazione E.164, split di verifica
• `name`: Jaro-Winkler ≥ 0. 92, fallback - fonte «KYC»
• «address» è un oggetto composto; unione + priorità di freschezza
• Cronologia: SCD2 ('valid _ from/valid _ to')
• Lineage: elenco dei campi donatori di riferimento
• Qualità: coverage≥98%, dublikaty≤0. 3%
• Freschezza di 1 ora, disponibilità di 99. 9%
• Proprietari: Data Platform, KYC/AML
• Rischi: conflitti di nomi, telefoni «familiari», shared-devices

15) Risultati e raccomandazioni

La fusione non è solo «JOIN chiave», ma un tracciato: i contratti di origine, l'identificazione e il dedotto, le priorità e la registrazione d'oro del CDC e i ritardatari, la qualità e l'osservabilità della sicurezza e la cronologia dei cambiamenti.
Creare regole in modo trasparente, memorizzare il controllo di ogni soluzione, supportare SCD ed exactly-once. Così i dati provenienti da decine di fonti si trasformano in vetrine affidabili e metriche sostenibili per il prodotto, analisti e ML.