Fusion de données provenant de différentes sources

Fusion de données provenant de différentes sources

La fusion de données est un processus de fusion de flux hétérogènes (OBD de produits, CRM, fournisseurs de paiement, logs d'événements, registres tiers) en entités holistiques et en vitrines cohérentes. L'objectif est d'obtenir un « disque d'or » (Golden Record) et des coupes cohérentes pour les analyses, ML et les cas opérationnels.

1) Scénarios et objectifs types

360 ° par essence : client/joueur, appareil, instrument de paiement, merchant.
Consolidation des transactions : plusieurs PSP/caisses → un seul journal avec une idempotence obligatoire.
Normalisation des événements : Web/mobile/backend logs → un seul dictionnaire d'événements.
Enrichissement : guides externes (géo, FX, AML/sanctions, sources marketing).
Métriques uniques : harmonisation des monnaies/temporisations, schémas et encodages.

2) Contrats et schémas de sources

• Schéma : champs, types, nullité, clé (s), domaines de valeurs.
• Sémantique : ce que signifie chaque champ (dictionnaires).
• SLA : fraîcheur/fréquence, latence maximale et out-of-order.
• Evolution : Politique de changement de schéma (backward/forward), deprecation.
• Qualité : unicité des clés, fourchettes admissibles, intégrité référentielle.

3) Identification : clés et mappage (linkage record)

3. 1. Identificateurs rigides

Clés naturelles : 'user _ id', 'transaction _ id', 'device _ id', 'iban'.
Clés proxy : e-mail/téléphone (avec normalisation : registre, espaces, codes de pays).
Substituts : 'surrogate _ id'dans les tables hab. s'il n'y a pas de clé universelle.

3. 2. Règles de mappage souples

Déterminisme : coïncidence exacte de l'e-mail normalisé + DR ; « maison « / » mob »téléphone → E.164.
Probabilités (faiszi) : Jaro-Winkler/Levenshtein pour le nom/l'adresse, TF-IDF/embeddings pour les lignes, « verrouillage » (blocking) par des hachages/préfixes bruts pour accélérer.
Approches graphiques : entités comme nœuds, coïncidences comme côtes ; regroupement du composant de connectivité.
Stratégie « step-up » : des règles strictes aux règles douces avec la rhubarbe manuelle « à la frontière ».

3. 3. Règles de consolidation

Priorité source : « KYC-registry> CRM> logs » lorsqu'il y a conflit de valeurs.
Fraîcheur : une marque de temps plus récente est gagnante (corrigée de la validité).
Remplissage : prefer non-NULL ; fusion d'adresses/balises par fusion d'ensembles.
Audit : gardez la « trace de la solution » - ce qui a été écrasé et pourquoi.

4) Déduplication et MDM

Couche MDM (Master Data Management) : Tables d'entités maîtres + liens istochnik→master.
Golden Record : enregistrement agrégé avec le champ « confiance »/source de vérité.
Historique : Type SCD 2 pour les attributs dépendant du temps (adresse, statut KYC).
Identités : tableaux de Merge Map avec dates de « fusion « /« dilution ».

5) Flux de changement : CDC, retard et doublons

CDC (Change Data Capture): события `insert/update/delete` + `source_lsn`/offset.
Événements tardifs : marques d'eau (watermarks) et fenêtres d'attente (grace period), stockage des updates tardives pour les ajustements.
Out-of-order : tri par clé et par temps, compensant les updates.
Duplicata : clés idempotent ('event _ id', 'idempotency _ key'), dédup dans la fenêtre.
Exactly-once : transactionnel sings/store, 'MERGE' avec une logique déterministe.

6) Temps, devises et calendrier

Temps : stocker dans UTC + tranches localisées ; stocker explicitement 'ingested _ at' et 'event _ time'.
Devises : gardez la « monnaie brute » et normalisé 'base _ ccy' avec le taux de change à la date de l'opération.
Calendriers : tableaux des jours fériés/jours ouvrables par région pour des comparaisons honnêtes.

7) Pseudo-SQL pour la fusion (upsert/merge)

7. 1. Transactions (journal 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. Enregistrement en or de l'utilisateur (priorité source + fraîcheur)

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é et tests

Schéma-test : champs obligatoires, types, domaines.
Logique-test : l'unicité de la clé, l'absence de doublons, pas de retour dans le temps.
Rapprochements (reconciliation) : montants par source vs vitrine finale ; divergences → tiquets.
Profilage : distributions, part NULL, « queues longues ».
Métriques de fusion : mappage precision/recall, proportion « CONFLICT », % d'entrées avec confiance ≥ seuil.

9) Observabilité et SLO

SLO de fraîcheur : vitrine lag ≤ N minutes/heures ; suivi des retards et backlog.
Alert : augmentation des doublons, flambée des conflits, chute des clés de couverture.
Logs lineage : De quelle source le champ a-t-il été pris, quand et par qui il a été écrasé.
Runibooks : scénarios d'incidents (lots tardifs, tempête CDC, faux FX).

10) Sécurité, vie privée, conformité

PII : pseudonymisation, hachage des identifiants, masquage en BI.
RLS/CLS : accès par rôle et par ligne ; exportation - avec tokens et date d'expiration.
Durée de vie des données : graphiques de stockage ; droit d'effacement (DSAR) et "legal hold'.
Anti-connexion (re-identification) : règles de minimisation des joyaux des tables sensibles.

11) Organisation des modèles et des données

Couches : 'raw' (en l'état) → 'staging' (nettoyage/normalisation) → 'core' (entité maître, fait/mesure) → 'marts' (vitrines sous analytique/ML).
SCD : type 2 pour les attributs, type 1 pour la correction des erreurs ; les 'valid _ from/valid _ to'explicites.
Feature Store : les fonctions de conversion sont identiques en ligne/hors ligne ; point-in-time est correct.

12) Modèles de réalisation

ELT avec couche sémantique : la logique de fusion est décrite de manière déclarative (règles, priorités, clés).
Stream + microbatch : pour les vitrines near-real-time - microbatches 1-15 min avec watermarks.
Graphe-linkage : graphe-habe séparé pour une identification complexe (devis, cartes, adresses).
Validation step-up : les nouvelles règles de linkage sont incluses dans le mode shadow, collectez des métriques de précision.

13) Chèque avant la sortie du circuit de fusion

• Les contrats sources ont été signés ; schémas et dictionnaires de champs harmonisés
• Les clés/règles de linkage ont été définies ; il y a une stratégie de déduplication
• Les règles de survie et les priorités des sources sont définies ; audit-logs inclus
• CDC/idempotence/traitement des données tardives mis en œuvre
• Devises/temporisations/calendrier normalisés
• Les tests de qualité et de rapprochement sont personnalisés ; les dashboards de l'observabilité sont là
• SLO de fraîcheur et de disponibilité est fixé ; alertes et runibooks prêts
• Les PII/accès/stockage répondent aux exigences de la conformité
• Documentation : passeport d'entité, schéma de lignage, exemples de demandes

14) Passeport « disque d'or » (modèle)

Entité : 'USER _ GOLDEN'

Clé : 'user _ master _ id' (surrogate), mappings 'source _ user _ id []'

• 'Email ': normalisation + priorité' KYC> CRM> LOGS'
• 'Phone ': normalisation des E.164, split sur la vérification
• `name`: Jaro-Winkler ≥ 0. 92, fallback - source « KYC »
• 'address ': objet composite ; unification + priorité à la fraîcheur
• Historique : SCD2 ('valid _ from/valid _ to')
• Lineage : liste de référence des champs donneurs
• Qualité : coverage≥98 %, dublikaty≤0. 3%
• SLO : fraîcheur ≤ 1h, disponibilité ≥ 99. 9%
• Propriétaires : Data Platform, KYC/AML
• Risques : conflits de noms, téléphones « familiaux », appareils partagés

15) Résultats et recommandations

La fusion est non seulement "JOIN selon la clé", et le contour : les contrats des sources → l'identification et дедуп → les priorités et "l'inscription d'or" → CDC étant en retard → la qualité et la perceptibilité → la sécurité et l'histoire des changements.
Construisez les règles de manière transparente, conservez l'audit de chaque solution, prenez en charge SCD et exactly-once. C'est ainsi que les données provenant de dizaines de sources se transforment en vitrines fiables et en métriques durables pour le produit, l'analyse et le ML.