Łączenie danych z różnych źródeł

Łączenie danych z różnych źródeł

Łączenie danych to proces łączenia heterogenicznych przepływów (baz danych produktów, CRM, dostawców płatności, dzienników zdarzeń, rejestrów stron trzecich) do podmiotów holistycznych i spójnych sklepów. Celem jest uzyskanie Złotego Rekordu i konsekwentnych cięć dla analityki, ML i przypadków operacyjnych.

1) Typowe scenariusze i cele

360 ° w istocie: klient/gracz, urządzenie, instrument płatniczy, handlowiec.
Konsolidacja transakcji: wiele PSP/kas → pojedynczy dziennik z obowiązkową idempotencją.
Normalizacja zdarzeń: web/mobile/backend logs → pojedynczy słownik zdarzeń.
Wzbogacanie: katalogi zewnętrzne (geo, FX, AML/sankcje, źródła marketingowe).
Ujednolicone wskaźniki: koordynacja walut/stref czasowych, schematów i kodów.

2) Umowy i systemy źródłowe

• Schemat: pola, typy, nieważność, klucz (y), domeny wartości.
• Semantyka: co oznacza każde pole (słownik).
• SLA: świeżość/częstotliwość, maksymalna opóźnienie i nieporządek.
• Ewolucja: polityka zmiany systemu (do tyłu/do przodu), depresja.
• Jakość: wyjątkowość kluczy, dopuszczalne zakresy, integralność odniesienia.

3) Identyfikacja: klucze i mapowanie (rekord linkage)

3. 1. Twarde identyfikatory

Klucze naturalne: 'user _ id',' transaction _ id', 'device _ id',' iban '.
Klucze proxy: e-mail/telefon (znormalizowany: sprawa, spacje, kody krajów).
Surogaty: "surogate _ id' w stołach piasty w przypadku braku uniwersalnego klucza.

3. 2. Miękkie zasady dopasowywania

Deterministyczne: dokładne dopasowanie znormalizowanej poczty elektronicznej + DR; "dom'/" telefon komórkowy" → E.164.
Probabilistic (fuzzy): Jaro-Winkler/Levenshtein dla nazwy/adresu, TF-IDF/osadzenia dla ciągów, „blokowanie” (blokowanie) przez grube hashes/prefiksy do przyspieszenia.
Podejścia wykresowe: podmioty jako węzły, zbieżności jako krawędzie; komponenty łącznościowe klastrujące.
Strategia przyspieszenia: od surowych do miękkich przepisów z ręcznym przeglądem „na granicy”.

3. 3. Zasady konsolidacji (przetrwanie)

Priorytetem źródła jest "KYC registry> CRM> logs', gdy istnieje konflikt wartości.
Świeżość: Nowszy znacznik czasu wygrywa (dostosowany do ważności).
Pełność: wolą non-NULL; łączenie adresów/znaczników poprzez łączenie zestawów.
Audyt: Zachować „szlak rozwiązania” - co zostało nadpisane i dlaczego.

4) Deduplikacja i MDM

MDM layer (Master Data Management): master entity tables + istochnik → master relationships.
Złoty rekord: zagregowany rekord z polem/źródłem prawdy „pewność siebie”.
Historia: SCD typ 2 dla atrybutów zależnych od czasu (adres, status KYC).
Tożsamości: Scalić tabele map z datami „merge „/” spill „.

5) Przepływy zmian: CDC, latecomers i duplikaty

CDC (Change Data Capture): сова тий 'insert/update/delete' + 'source _ lsn'/offset.
Późne wydarzenia: znaki wodne i okres łaski, przechowywanie późnych aktualizacji do regulacji.
Out-of-order: sortowanie według klucza i czasu, kompensowanie aktualizacji.
Duplikaty: idempotent keys ('event _ id',' idempotence _ key '), dedup w oknie.
Dokładnie raz: pojedyncze/sklep transakcyjny, 'MERGE' z logiką deterministyczną.

6) Strefy czasowe, waluty i kalendarz

Czas: przechowywać w UTC + zlokalizowane plasterki; explicitly store 'ingested _ at' i 'event _ time'.
Waluty: Przechowywać „surową walutę” i znormalizowane 'base _ ccy' z kursem w dniu transakcji.
Kalendarze: tabele wakacyjne/dni robocze według regionów dla uczciwych porównań.

7) Pseudo-SQL dla połączenia (upsert/merge)

7. 1. Transakcje (idempotent journal)

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. Użytkownik „złoty rekord” (priorytet źródłowy + świeżość)

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) Jakość i badania

Schemat testowy: wymagane pola, typy, domeny.
Testy logiczne: wyjątkowość klucza, brak duplikatów, brak „back in time”.
Uzgodnienia: kwoty według źródła vs final showcase; rozbieżności → bilety.
Profilowanie: dystrybucje, frakcja NULL, „długie ogony”.
Mierniki łączenia: mapowanie precyzyjne/przypomnienie,% rekordów z progiem ufności ≥.

9) Obserwowalność i SLO

świeżość SLO: opóźnienie okna ≤ N minut/godziny; opóźnienie monitorowania i opóźnienia.
Alerty: wzrost liczby duplikatów, wzrost konfliktów, spadek kluczy zasięgu.
Logi Lineage: z którego źródła pole zostało pobrane, kiedy i przez kogo zostało nadpisane.
Runybooks: Scenariusze incydentów (późne partie, burze CDC, nieprawidłowe FX).

10) Bezpieczeństwo, prywatność, zgodność

PII: aliasing, identyfikacja, maskowanie w BI.
RLS/CLS: dostęp według ról i wierszy; eksport - z żetonami i datą wygaśnięcia.
Czas trwania danych: harmonogram przechowywania; prawo do usunięcia (DSAR) i „posiadania prawnego”.
Ponowna identyfikacja: zasady minimalizowania łączenia wrażliwych stołów.

11) Model i organizacja danych

Warstwy: „surowe” (jak jest) → „ustawianie” (czyszczenie/normalizacja) → „rdzeń” (jednostki główne, fakty/pomiary) → „marts” (prezentacje dla analityki/ML).
SCD: typ 2 dla atrybutów, typ 1 dla korekty błędów; explicit 'valid _ from/valid _ to'.
Funkcja Sklep: funkcje transformacji są identyczne online/offline; poprawność punktu w czasie.

12) Schematy wdrażania

ELT z warstwą semantyczną: logika połączenia jest opisywana deklaracyjnie (zasady, priorytety, klucze).
Strumień + mikrobatch: dla wyświetlaczy w czasie zbliżonym do rzeczywistego - mikrobaty 1-15 min ze znakami wodnymi.
Wykres-powiązanie: oddzielny węzeł graficzny służący do identyfikacji złożonej (urządzenia, mapy, adresy).
Walidacja Step-Up: włączenie nowych zasad łączenia w trybie cienia, zbieranie mierników dokładności.

13) Lista kontrolna przed połączeniem pętli

• Podpisane umowy źródłowe; schematy i słowniki polowe są spójne
• zdefiniowane klucze/zasady powiązań; posiada strategię deduplikacji
• Określono zasady przetrwania i priorytety źródłowe; włączony dziennik audytu
• CDC/idempotence/late data processing implemented
• Waluty/Timezones/Kalendarz znormalizowany
• Ustanawia się testy jakości i uzgodnienia; dostępne są deski rozdzielcze z możliwością obserwacji
• Świeżość i dostępność SLO są stałe; alerty i broszury są gotowe
• PII/dostęp/składowanie zgodne
• Dokumentacja: paszport podmiotu, schemat lineage, wnioski o próbę

14) Paszport „złotej płyty” (szablon)

Podmiot: „UŻYTKOWNIK _ GOLDEN”

Klucz: 'user _ master _ id' (surogate), mappings' source _ user _ id [] '

• „e-mail”: normalizacja + priorytet „KYC> CRM> LOGS”
• „telefon”: normalizacja E.164, podział weryfikacji
• „nazwa”: Jaro-Winkler ≥ 0. 92, fallback - źródło KYC
• „address”: obiekt złożony; priorytet unii + świeżości
• Historia: SCD2 ('valid _ from/valid _ to')
• Rodowód: lista referencyjna pola dawcy
• Jakość: zasięg ≥ 98%, dublikaty ≤ 0. 3%
• SLO: świeżość ≤ 1 godzina, dostępność ≥ 99. 9%
• Właściciele: Platforma danych, KYC/AML
• Ryzyko: kolizje nazw, telefony „rodzinne”, urządzenia współdzielone

15) Streszczenie i zalecenia

Połączenie jest nie tylko „JOIN by key”, ale zarys: kontrakty źródłowe → identyfikacja i dedup → priorytety i „złoty rekord” CDC → i późno → jakość i obserwowalność → bezpieczeństwo i historia zmian.
Budować zasady w sposób przejrzysty, zachować audyt każdego rozwiązania, wsparcie SCD i dokładnie raz. W ten sposób dane z kilkudziesięciu źródeł przekształcają się w niezawodne sklepy i zrównoważone mierniki produktu, analityki i ML.