Злиття даних з різних джерел

Злиття даних з різних джерел

Злиття даних - це процес об'єднання різнорідних потоків (БД продуктів, CRM, платіжні провайдери, логи подій, сторонні реєстри) в цілісні сутності і консистентні вітрини. Мета - отримати «золотий запис» (Golden Record) і узгоджені розрізи для аналітики, ML і операційних кейсів.

1) Типові сценарії та цілі

360 ° по суті: клієнт/гравець, пристрій, платіжний інструмент, мерчант.
Консолідація транзакцій: кілька PSP/кас → єдиний журнал з обов'язковою ідемпотентністю.
Нормалізація подій: веб/мобайл/бекенд-логи → єдиний словник подій.
Збагачення: зовнішні довідники (гео, FX, AML/санкції, маркетингові джерела).
Єдині метрики: узгодження валют/таймзон, схем і кодувань.

2) Контракти джерел і схеми

• Схема: поля, типи, нулабельність, ключ (і), домени значень.
• Семантика: що означає кожне поле (словники).
• SLA: свіжість/частота, максимальна затримка і out-of-order.
• Еволюція: політика зміни схем (backward/forward), deprecation.
• Якість: унікальність ключів, допустимі діапазони, референціальна цілісність.

3) Ідентифікація: ключі та зіставлення (record linkage)

3. 1. Жорсткі ідентифікатори

Природні ключі: `user_id`, `transaction_id`, `device_id`, `iban`.
Проксі-ключі: e-mail/телефон (з нормалізацією: регістр, прогалини, коди країн).
Сурогати: 'surrogate _ id'в хаб-таблицях при відсутності універсального ключа.

3. 2. М'які правила зіставлення

Детерміновані: точний збіг нормалізованого e-mail + ДР; «будинок «/» моб »телефон → E.164.
Імовірнісні (фаззі): Jaro-Winkler/Levenshtein для імені/адреси, TF-IDF/ембеддинги для рядків, «блокування» (blocking) за грубими хешами/префіксами для прискорення.
Графові підходи: сутності як вузли, збіги як ребра; кластеризація компонент зв'язності.
Стратегія «step-up»: від суворих до м'яких правил з ручною рев'ю «на кордоні».

3. 3. Правила консолідації (survivorship)

Пріоритет джерела: «KYC-реєстр> CRM> логи», коли є конфлікт значень.
Свіжість: більш нова мітка часу перемагає (з поправкою на достовірність).
Заповненість: prefer non-NULL; злиття адрес/тегів об'єднанням множин.
Аудит: зберігайте «слід рішення» - що перезаписали і чому.

4) Дедуплікація і MDM

MDM-слой (Master Data Management): таблиці «майстер-сутностей» + зв'язку «istochnik→master».
Golden Record: агрегована запис з полем «confidence »/джерелом правди.
Історія: SCD-тип 2 для атрибутів, що залежать від часу (адреса, статус KYC).
Ідентичності: таблиці мерджів (merge map) з датами «злиття «/« розплитування ».

5) Потоки змін: CDC, запізнілі та дублікати

CDC (Change Data Capture): події'insert/update/delete'+'source _ lsn '/offset.
Запізнілі події: водяні мітки (watermarks) і вікна очікування (grace period), зберігання пізніх апдейтів для коригувань.
Out-of-order: сортування за ключем і часом, що компенсують апдейти.
Дублікати: ідемпотентні ключі ('event _ id','idempotency _ key'), дедуп у вікні.
Exactly-once: транзакційні сингс/стор,'MERGE'з детермінованою логікою.

6) Таймзони, валюти і календар

Час: зберігати в UTC + локалізовані зрізи; явно зберігати'ingested _ at'і'event _ time'.
Валюти: зберігати «сиру валюту» і нормалізовану'base _ ccy'з курсом на дату операції.
Календарі: таблиці свят/робочих днів по регіонах для чесних порівнянь.

7) Псевдо-SQL для злиття (upsert/merge)

7. 1. Транзакції (ідемпотентний журнал)

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. «Золотий запис» користувача (пріоритет джерела + свіжість)

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) Якість і тестування

Схема-тести: обов'язкові поля, типи, домени.
Логіка-тести: унікальність ключа, відсутність дублікатів, немає «назад у часі».
Звірки (reconciliation): суми за джерелом vs підсумкова вітрина; розбіжності → тікети.
Профілювання: розподілу, частка NULL, «довгі хвости».
Метрики злиття: precision/recall зіставлення, частка «CONFLICT»,% записів з confidence ≥ порогу.

9) Спостережуваність і SLO

SLO свіжості: лаг вітрин ≤ N хвилин/годин; моніторинг затримок і backlog.
Алерти: зростання дублікатів, сплеск конфліктів, падіння coverage ключів.
Логи lineage: з якого джерела взяли поле, коли і ким перезаписано.
Рунібуки: сценарії інцидентів (спізнілі партії, шторму CDC, невірний FX).

10) Безпека, приватність, комплаєнс

PII: псевдонімізація, хешування ідентифікаторів, маскування в BI.
RLS/CLS: доступ за ролями та рядками; експорт - з токенами і терміном придатності.
Термін життя даних: графіки зберігання; право на видалення (DSAR) і «legal hold».
Анти-з'єднання (re-identification): правила мінімізації джойнів чутливих таблиць.

11) Організація моделей і даних

Шари: 'raw'( як є) →'staging'( очищення/нормалізація) →'core'( майстер-сутності, факт/вимірювання) →'marts'( вітрини під аналітику/ML).
SCD: тип 2 для атрибутів, тип 1 - для виправлення помилок; явні'valid _ from/valid _ to'.
Feature Store: функції перетворень ідентичні онлайн/офлайн; point-in-time коректність.

12) Патерни реалізації

ELT з семантичним шаром: логіка злиття описана декларативно (правила, пріоритети, ключі).
Стрім + мікробатч: для near-real-time вітрин - мікробатчі 1-15 хв з watermarks.
Graph-linkage: окремий граф-хаб для складної ідентифікації (девайси, карти, адреси).
Step-up валідація: нові правила linkage включати в shadow-режимі, збирати метрики точності.

13) Чек-лист перед релізом контуру злиття

• Контракти джерел підписані; схеми і словники полів узгоджені
• Визначено ключі/правила linkage; є стратегія дедуплікації
• Задані правила survivorship і пріоритети джерел; аудит-лог включено
• CDC/ідемпотентність/обробка пізніх даних реалізовані
• Валюти/таймзони/календар нормалізовані
• Тести якості та звірки налаштовані; дашборди спостережуваності є
• SLO свіжості і доступності зафіксовані; алерти і рунібуки готові
• PII/доступи/зберігання відповідають вимогам комплаєнсу
• Документація: паспорт сутності, схема lineage, приклади запитів

14) Паспорт «золотого запису» (шаблон)

Сутність: `USER_GOLDEN`

Ключ: 'user _ master _ id'( surrogate), меппінги'source _ user _ id []'

• `email`: нормалізація + пріоритет'KYC> CRM> LOGS '
• `phone`: нормалізація E.164, спліт за верифікацією
• `name`: Jaro-Winkler ≥ 0. 92, fallback - джерело «KYC»
• `address`: складений об'єкт; об'єднання + пріоритет свіжості
• Історія: SCD2 (`valid_from/valid_to`)
• Lineage: посилальний список полів-донорів
• Якість: coverage≥98%, dublikaty≤0. 3%
• SLO: свіжість ≤ 1 год, доступність ≥ 99. 9%
• Власники: Data Platform, KYC/AML
• Ризики: колізії імен, «сімейні» телефони, shared-devices

15) Підсумки та рекомендації

Злиття - це не тільки «JOIN по ключу», а контур: контракти джерел → ідентифікація і дедуп → пріоритети і «золотий запис» → CDC і запізнілі → якість і спостережуваність → безпеку і історія змін.
Будуйте правила прозоро, зберігайте аудит кожного рішення, підтримуйте SCD і exactly-once. Так дані з десятків джерел перетворюються в надійні вітрини і стійкі метрики для продукту, аналітики і ML.