Îmbinarea datelor din diferite surse

Fuzionarea datelor din diferite surse

Fuzionarea datelor este procesul de combinare a fluxurilor eterogene (baze de date de produse, CRM, furnizori de plăți, jurnale de evenimente, registre terțe) în entități holistice și storefronturi consistente. Scopul este de a obține o înregistrare de aur și reduceri consistente pentru analize, ML și cazuri operaționale.

1) Scenarii și obiective tipice

360 ° în esență: client/jucător, dispozitiv, instrument de plată, comerciant.
Consolidarea tranzacțiilor: mai multe PSP-uri/case de marcat → un singur jurnal cu idempotență obligatorie.
Normalizarea evenimentelor: jurnale web/mobile/backend → un singur dicționar de evenimente.
Îmbogățire: directoare externe (geo, FX, AML/sancțiuni, surse de marketing).
Valori unificate: coordonarea valutelor/zonelor orare, scheme și codificări.

2) Contractele și schemele sursă

• Schema: domenii, tipuri, nullability, chei (e), domenii de valoare.
• Semantica: ce înseamnă fiecare domeniu (dicționar).
• SLA: prospețime/frecvență, latență maximă și out-of-order.
• Evoluție: politica de schimbare a schemei (înapoi/înainte), depresie.
• Calitate: unicitatea cheilor, intervale acceptabile, integritate referențială.

3) Identificare: chei și cartografiere (legătură de înregistrare)

3. 1. Hard ID-uri

Chei naturale: 'user _ id',' transaction _ id', 'device _ id',' iban '.
Chei proxy: e-mail/telefon (normalizat: caz, spații, coduri de țară).
Surrogates: 'surogate _ id' în mesele hub în absența unei chei universale.

3. 2. Reguli de potrivire soft

Deterministic: potrivirea exactă a e-mailului normalizat + DR; „acasă „/” mobil „telefon → E.164.
Probabilistic (fuzzy): Jaro-Winkler/Levenshtein pentru nume/adresă, TF-IDF/încorporări pentru șiruri, „blocare” (blocare) prin hashes grosier/prefixe pentru accelerare.
Abordări grafice: entități ca noduri, coincidențe ca muchii; componente de conectivitate clustering.
Strategia de intensificare: de la reguli stricte la reguli soft cu revizuire manuală „la frontieră”.

3. 3. Reguli de consolidare (supraviețuire)

Prioritatea sursei este „registrul KYC> CRM> jurnalele” atunci când există un conflict de valori.
Prospețime: Câștigurile mai noi ale marcajului temporal (ajustate pentru valabilitate).
Plinătatea: preferați non-NULL; îmbinarea adreselor/etichetelor prin combinarea seturilor.
Audit: Păstrați „traseul soluției” - ceea ce a fost suprascris și de ce.

4) Deduplicarea și MDM

MDM layer (Master Data Management): tabele master entitate + relații istochnik→master.
Golden Record: înregistrare agregată cu câmpul „încredere ”/sursa adevărului.
Istoric: Tipul SCD 2 pentru atribute dependente de timp (adresa, starea KYC).
Identități: Îmbinați tabelele de hărți cu datele „îmbinare „/” vărsare „.

5) Schimbarea fluxurilor: CDC, latecomers și duplicate

CDC (Change Data Capture): события 'insert/update/delete' + 'source _ lsn'/offset.
Evenimente târzii: filigrane și perioada de grație, stocarea actualizărilor târzii pentru ajustări.
Out-of-order: sortare după cheie și timp, compensarea actualizărilor.
Duplicate: chei idempotente ('event _ id',' idempotency _ key '), dedup în fereastră.
Exact o dată: single-uri tranzacționale/magazin, „MERGE” cu logica deterministă.

6) Fusuri orare, valute și calendar

Timp: stocați în felii localizate UTC +; în mod explicit store 'ingested _ at' and 'event _ time'.
Valute: Stocați „moneda brută” și normalizați „base _ ccy” cu rata la data tranzacției.
Calendare: Mese de vacanță/zi de lucru pe regiuni pentru comparații echitabile.

7) Pseudo-SQL pentru îmbinare (upsert/fuziune)

7. 1. Tranzacții (jurnal 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. Utilizator „înregistrare de aur” (prioritate sursă + prospețime)

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) Calitate și testare

Schema de testare: câmpuri, tipuri, domenii obligatorii.
Teste logice: unicitatea cheii, absența duplicatelor, fără „înapoi în timp”.
Reconcilieri: sume după sursă vs vitrină finală; discrepanţe → bilete.
Profilare: distribuții, fracție NULL, „cozi lungi”.
Măsurători de îmbinare: mapări de precizie/rechemare,% din înregistrări cu prag de ≥ de încredere.

9) Observabilitate și SLO

Prospețime SLO: decalaj fereastră ≤ N minute/ore; întârziere monitorizare și backlogging.
Alerte: o creștere a duplicatelor, o creștere a conflictelor, o scădere a cheilor de acoperire.
Jurnalele de linie: din care sursă a fost luat câmpul, când și de către cine a fost suprascris.
Runybooks: Scenarii incidente (loturi târzii, furtuni CDC, FX incorecte).

10) Securitate, confidențialitate, conformitate

Aliasing, ID hashing, mascare în BI.
RLS/CLS: acces pe roluri și rânduri; export - cu jetoane și data expirării.
Durata de viață a datelor: programe de stocare; dreptul de a elimina (DSAR) și „dețin legal”.
Re-identificare: reguli pentru minimizarea unirii tabelelor sensibile.

11) Organizarea modelului și a datelor

Straturi: 'raw' (așa cum este) → 'staging' (curățare/normalizare) → 'core' (entități principale, fapte/măsurători) → 'marts' (vitrine pentru analytics/ML).
SCD: tipul 2 pentru atribute, tipul 1 pentru corectarea erorilor; explicit 'valid _ from/valid _ to'.
Feature Store: funcțiile de transformare sunt identice online/offline; corectitudinea punctuală.

12) Modele de implementare

ELT cu strat semantic: logica de îmbinare este descrisă declarativ (reguli, priorități, chei).
Stream + microbatch: pentru display-uri aproape în timp real - microbatch-uri 1-15 min cu filigrane.
Graph-linkage: un hub separat pentru identificarea complexă (dispozitive, hărți, adrese).
Validarea treptată: includeți noi reguli de legătură în modul umbră, colectați măsurători de precizie.

13) Lista de verificare Pre-Merge Loop Release

• Contractele sursă semnate; schemele și dicționarele de câmp sunt consecvente
• cheile de legătură/regulile definite; are o strategie de eliminare a duplicatelor
• Regulile de supraviețuire și prioritățile sursei sunt stabilite; audit-log activat
• CDC/idempotency/tardive data processing implementat
• Valute/Fusuri orare/Calendar Normalizat
• Testele de calitate și reconcilierile sunt stabilite; sunt disponibile tablouri de bord de observabilitate
• Prospețimea și disponibilitatea SLO sunt fixe; alerte și runibooks sunt gata
• PII/access/storage compatibil
• Documentație: Pașaportul entității, schema de descendență, cererile de eșantionare

14) Pașaportul „înregistrării de aur” (șablon)

Entitate: 'USER _ GOLDEN'

Cheie: 'user _ master _ id' (surogat), mappings' source _ user _ id []'

• 'email': normalizare + prioritate 'KYC> CRM> LOGS'
• „telefon”: normalizare E.164, divizare verificare
• 'name': Jaro-Winkler ≥ 0. 92, rezervă - sursă KYC
• „adresă”: obiect compus; prioritate uniune + prospețime
• Istoric: SCD2 ('valid _ from/valid _ to')
• Descendență: lista de referință a câmpului donator
• Calitate: coverage≥98%, dublikaty≤0. 3%
• SLO: prospețime ≤ 1 oră, disponibilitate ≥ 99. 9%
• Proprietari: Platforma de date, KYC/AML
• Riscuri: coliziuni de nume, telefoane „de familie”, dispozitive partajate

15) Rezumat și recomandări

Fuziunea nu este doar un „JOIN by key”, ci o schiță: contractele sursă identificarea și dedicarea priorităților și o „înregistrare de aur” a CDC și calitatea și observabilitatea siguranța și schimbarea istoricului.
Construiți reguli transparent, păstrați un audit al fiecărei soluții, sprijiniți SCD și exact o dată. Acesta este modul în care datele din zeci de surse se transformă în storefronturi fiabile și valori durabile pentru produs, analiză și ML.