Combinación de datos de diferentes orígenes

Combinación de datos de diferentes orígenes

La fusión de datos es el proceso de combinar flujos heterogéneos (DAB de productos, CRM, proveedores de pagos, registros de eventos, registros de terceros) en entidades integrales y vitrinas consistentes. El objetivo es obtener un «disco de oro» (Golden Record) y cortes consistentes para análisis, ML y casos operativos.

1) Escenarios y objetivos estándar

360 ° en esencia: cliente/jugador, dispositivo, instrumento de pago, merchant.
Consolidación de transacciones: múltiples PSP/taquillas → un solo registro con idempotencia obligatoria.
Normalización de eventos: web/mobile/backend logs → un solo diccionario de eventos.
Enriquecimiento: manuales externos (geo, FX, AML/sanciones, fuentes de marketing).
Métricas unificadas: negociación de monedas/temporizadores, esquemas y codificaciones.

2) Contratos de fuentes y esquemas

• Esquema: campos, tipos, nulidad, clave (s), dominios de valores.
• Semántica: lo que significa cada campo (diccionarios).
• SLA: frescura/frecuencia, latencia máxima y fuera de orden.
• Evolución: política de cambio de esquemas (backward/forward), deprecation.
• Calidad: singularidad de las claves, rangos válidos, integridad referencial.

3) Identificación: claves y asignación (enlace de registro)

3. 1. Identificadores duros

Claves naturales: 'user _ id', 'transaction _ id', 'device _ id', 'iban'.
Claves proxy: e-mail/teléfono (con normalización: registro, espacios, códigos de país).
Sustitutos: 'surrogate _ id' en tablas hub en ausencia de clave universal.

3. 2. Reglas de asignación blanda

Determinista: la coincidencia exacta de un e-mail + RD normalizado; «hogar «/» amb »teléfono → E.164.
Probabilística (phazzie): Jaro-Winkler/Levenshtein para nombre/dirección, TF-IDF/embeddings para cadenas, «bloqueo» (blocking) sobre hashes/prefijos gruesos para aceleración.
Aproximaciones gráficas: entidades como nodos, coincidencias como costillas; clustering componente de conectividad.
Estrategia «step-up»: de reglas estrictas a suaves con rugido manual «en la frontera».

3. 3. Reglas de consolidación (survivorship)

Prioridad de la fuente: «Registro KYC> CRM> registros» cuando hay un conflicto de valores.
Frescura: gana una marca de tiempo más nueva (ajustada a la validez).
Llenado: Prefer non-NULL; combinación de direcciones/etiquetas mediante la combinación de conjuntos.
Auditoría: mantenga el «rastro de la solución» - qué se ha sobrescrito y por qué.

4) Deduplicación y MDM

Capa MDM (Master Data Management): tablas de «entidades maestras» + enlaces «istochnik→master».
Registro de oro: registro agregado con el campo 'confidence '/fuente de la verdad.
Historial: SCD-tipo 2 para atributos que dependen del tiempo (dirección, estado KYC).
Identidades: tablas de merge (merge map) con fechas de «fusión «/« fusión ».

5) Flujos de cambio: CDC, atrasados y duplicados

CDC (Change Data Capture): события `insert/update/delete` + `source_lsn`/offset.
Eventos atrasados: marcas de agua (watermarks) y ventanas de espera (grace period), almacenamiento de actualizaciones tardías para ajustes.
Out-of-order: ordenar por clave y tiempo, compensando los apdates.
Duplicados: claves idempotentes ('event _ id', 'idempotency _ key'), dedoop en la ventana.
Exactly-once: sings/stor transaccional, 'MERGE' con lógica determinista.

6) Temporizaciones, monedas y calendario

Tiempo: almacenar en UTC + cortes localizados; almacenar explícitamente 'ingested _ at' y 'event _ time'.
Monedas: almacenar «moneda cruda» y 'base _ ccy' normalizada con el tipo de cambio en la fecha de la operación.
Calendarios: tablas de días festivos/laborables por región para comparaciones honestas.

7) Pseudo-SQL para la fusión (upsert/merge)

7. 1. Transacciones (registro idempotente)

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. «Registro de oro» del usuario (prioridad de fuente + frescura)

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) Calidad y pruebas

Pruebas de esquema: campos obligatorios, tipos, dominios.
Pruebas de lógica: la singularidad de la clave, la ausencia de duplicados, no hay «retroceso en el tiempo».
Conciliaciones (reconciliation): sumas por fuente vs escaparate final; discrepancias → tickets.
Perfilando: distribuciones, fracción NULL, «colas largas».
Métricas de fusión: asignaciones precision/recall, fracción "CONFLICT',% de registros con confidence ≥ umbral.

9) Observabilidad y SLO

Frescura SLO: vitrinas de corte ≤ N minutos/horas; monitoreo de retrasos y retroceso.
Alertas: aumento de duplicados, estallido de conflictos, caída de claves de coverage.
Logs lineage: de qué fuente tomaron el campo, cuándo y por quién se sobrescribió.
Runibuki: escenarios de incidentes (lotes atrasados, tormenta de los CDC, FX incorrecta).

10) Seguridad, privacidad, cumplimiento

PII: seudonimización, hash ID, enmascaramiento en BI.
RLS/CLS: acceso por roles y líneas; exportación - con tokens y fecha de caducidad.
Vida útil de los datos: horarios de almacenamiento; el derecho de destitución (DSAR) y el "legal hold'.
Anti-conexión (re-identificación): reglas para minimizar los joyines de tablas sensibles.

11) Organización de modelos y datos

Capas: 'raw' (tal cual) → 'staging' (limpieza/normalización) → 'core' (entidades maestras, hecho/medida) → 'marts' (escaparates bajo analítica/ML).
SCD: tipo 2 para atributos, tipo 1 para corregir errores; explícitamente 'valid _ from/valid _ to'.
Feature Store: las funciones de transformación son idénticas en línea/fuera de línea; corrección punto-en-tiempo.

12) Patrones de implementación

ELT con capa semántica: la lógica de fusión se describe declarativamente (reglas, prioridades, claves).
Stream + microbatch: para escaparates near-real-time - microbatches 1-15 min con watermarks.
Graph-linkage: un hub gráfico separado para la identificación compleja (dispositivos, mapas, direcciones).
Validación paso a paso: nuevas reglas de enlace para incluir en modo shadow, recoger métricas de precisión.

13) Lista de verificación antes de la liberación del esquema de fusión

• Se han firmado contratos de fuentes; diagramas y diccionarios de campo acordados
• Se han definido las claves/reglas de enlace; hay una estrategia de deduplicación
• Se establecen las reglas de supervivencia y las prioridades de origen; El registro de auditoría está habilitado
• CDC/idempotencia/procesamiento de datos tardíos implementados
• Las monedas/zonas de tiempo/calendario se normalizan
• Pruebas de calidad y de conciliación personalizadas; hay dashboards de la observabilidad
• Los SLO de frescura y disponibilidad están fijos; alertas y runibooks listos
• PII/accesos/almacenamiento cumplen con los requisitos de cumplimiento
• Documentación: pasaporte de entidad, esquema de enlace, consultas de ejemplo

14) Pasaporte «disco de oro» (plantilla)

Esencia: 'USER _ GOLDEN'

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

• 'email': normalización + prioridad 'KYC> CRM> LOGS'
• 'phone': normalización de la E.164, división por verificación
• `name`: Jaro-Winkler ≥ 0. 92, fallback - fuente «KYC»
• 'address': objeto compuesto; combinación + prioridad de frescura
• Historial: SCD2 ('valid _ from/valid _ to')
• Lineage: lista de referencia de campos donantes
• Calidad: coverage≥98%, dublikaty≤0. 3%
• SLO: frescura ≤ 1 h, disponibilidad ≥ 99. 9%
• Propietarios: Plataforma de datos, KYC/AML
• Riesgos: colisiones de nombres, teléfonos «familiares», dispositivos compartidos

15) Resultados y recomendaciones

La fusión no es solo «JOIN por clave», sino un esquema: contratos de origen → identificación y dedoup → prioridades y «registro de oro» → CDC y atrasados en → calidad y observabilidad → seguridad e historial de cambios.
Construya reglas de manera transparente, mantenga la auditoría de cada solución, soporte SCD y exactly-once. Así que los datos de decenas de fuentes se convierten en escaparates confiables y métricas sostenibles para el producto, análisis y ML.