Fusão de dados de diferentes fontes

Fusão de dados de diferentes fontes

A fusão de dados é um processo de combinação de fluxos heterogéneos (BB de produtos, CRM, provedores de pagamentos, logs de eventos, registros de terceiros) em entidades integrais e vitrines consistentes. O objetivo é obter uma gravação de ouro (Golden Record) e cortes acordados para analistas, ML e malas operacionais.

1) Cenários e objetivos típicos

360 ° em essência: cliente/jogador, dispositivo, ferramenta de pagamento, merchant.
Consolidação de transações: Várias PSP/caixa → um único registro com idumpotência obrigatória.
Normalizar eventos: Web/mobile/backend logs → um único dicionário de eventos.
Enriquecimento: guias externos (geo, FX, AML/sanções, fontes de marketing).
Uma mesma métrica: alinhamento de moedas/temporizações, diagramas e codificações.

2) Contratos de fontes e esquema

• Padrão: campos, tipos, zero, chave (e), domínios de valores.
• Semântica: o que significa cada campo (dicionários).
• SLA: frescura/frequência, atraso máximo e out-of-order.
• Evolução: política de alteração de esquema (backward/forward), deprecation.
• Qualidade: exclusividade das chaves, faixas válidas, integridade arbitral.

3) Identificação: chaves e mapeamento (record linkage)

3. 1. Identificadores rígidos

As chaves naturais são 'user _ id', 'direction _ id', 'device _ id', 'iban'.
Chave proxy: e-mail/telefone (com normalização: maiúsculas, espaços, códigos de país).
Substitutos: 'surrogate _ id' em tabelas hab sem chave universal.

3. 2. Regras de mapeamento suaves

Determinados: correspondência exata de e-mail normalizado + DR; «casa «/» mob »telefone → E.164.
Prováveis (phaszi): Jaro-Winkler/Levenshttein para nome/endereço, TF-IDF/embeddings para linhas, «bloqueio» (blocking) para hash/prefixo bruto para acelerar.
Abordagens gráficas: entidades como nós, correspondências como costelas; clusterização do componente de conectividade.
Estratégia «step-up»: de regras rígidas a regras suaves, com «no limite».

3. 3. Regras de consolidação (survivorship)

A prioridade de origem é «Registro KYC> CRM> logs» quando há conflito de valores.
Frescura: marca de tempo mais nova vencendo (ajustado para a veracidade).
Preenchimento: prefer não-NULL; fusão de endereços/marcas com a combinação de múltiplos.
Auditoria: mantenha o rasto da solução - o que foi substituído e porquê.

4) Deduplicação e MDM

Camada MDM (Master Data Management): tabelas de entidades mestre + laços istochnik→master.
Golden Record: gravação agregada com campo 'confidence '/origem da verdade.
Histórico: Tipo SCD 2 para atributos que dependem do tempo (endereço, status KYC).
Identidades: tabelas de murge (merge map) com datas de fusão/divulgação.

5) Fluxos de alterações: CDC, atrasados e duplicados

CDC (Change Data Capture): события `insert/update/delete` + `source_lsn`/offset.
Eventos atrasados: marcas de água (watermarks) e janelas de espera (grace period), armazenamento de updates tardios para ajustes.
Out-of-order: arrumação por chave e tempo que compensam updates.
Duplicações: chaves idempotentes ('event _ id', 'idempotency _ key'), deadup na janela.
Exactly-once: sings/store transacionados, 'MERGE' com uma lógica definida.

6) Temporizões, moedas e calendário

Tempo: armazenar em UTC + cortes localizados; armazenar claramente 'ingested _ at' e 'event _ time'.
Moedas: armazenar «moeda crua» e «base _ cky» normalizado com taxa de câmbio na data da operação.
Calendários: tabelas de feriados/dias úteis por região para comparações honestas.

7) Pseudo-SQL para fusão (upsert/merge)

7. 1. Transações (registro idumpotente)

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. «Gravação de ouro» do usuário (prioridade fonte + frescor)

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) Qualidade e testes

Testes de padrão: campos obrigatórios, tipos, domínios.
Testes de lógica, exclusividade da chave, falta de duplicação, não há «volta no tempo».
Comprimidos (reconciação): somas por fonte vs vitrine final; divergências → tíquetes.
Perfil: distribuição, proporção NULL, caudas longas.
Métricas de fusão: precisão/recall de mapeamento, proporção de «CONFLICT»,% de registros com confidence ≥ limiar.

9) Observabilidade e SLO

SLO frescura: vitrines ≤ N minutos/relógio; monitoramento de atrasos e backlog.
Alerts: Duplicação crescente, conflito, queda de chave coverage.
Logi lineage: de que origem foi tirado o campo, quando e quem foi substituído.
Runibuki: cenários de incidentes (lotes atrasados, tempestade CDC, FX errado).

10) Segurança, privacidade, complacência

PII: pseudônimo, hasteamento de identificadores, disfarce em BI.
RLS/CLS: acesso por papéis e linhas; exportação - com tocadores e validade.
Tempo de vida dos dados: gráficos de armazenamento; direito de remoção (DSAR) e «legal hold».
Anti-conexão (re-identidade): regras para minimizar os joyons de tabelas sensíveis.

11) Organização de modelos e dados

Camadas: 'raw' (como é) → 'staging' (limpeza/normalização) → 'core' (essências mestre, fato/medida) → 'mart' (vitrines sob análise/ML).
SCD: tipo 2 para atributos, tipo 1 para corrigir erros; explícitos 'valid _ from/valid _ to'.
Função Store: as funções de transformação são idênticas online/offline; point-in-time correto.

12) Pattern de implementação

ELT com camada semântica: lógica de fusão descrita declaradamente (regras, prioridades, chaves).
Strim + microatch: Para vitrines near-real-time - microbiatchi 1-15 min com watermarks.
Graph-linkage: um grafo-hab separado para uma identificação complexa (slides, mapas, endereços).
Validação de step: novas regras de linkage incluem no modo shadow, coletando métricas de precisão.

13) Folha de cheque antes do lançamento do circuito de fusão

• Os contratos das fontes foram assinados; diagramas e dicionários de campos alinhados
• Chave/regras linkage definidas; há uma estratégia de dedução
• As regras de survivorship e as prioridades de origem foram definidas; auditoria-logos incluída
• CDC/idimpotência/processamento de dados tardios implementados
• Divisas/temporizões/calendário normalizados
• Testes de qualidade e verificação configurados; dashboards de observabilidade
• SLO de frescura e disponibilidade são registrados; alerts e runibuki prontos
• PII/acessibilidade/armazenamento correspondem aos requisitos da complacência
• Documentação: passaporte da entidade, esquema lineage, exemplos de solicitação

14) Passaporte «gravação de ouro» (modelo)

Entidade: 'USER _ GOLDEN'

Chave: 'user _ master _ id' (surrogate), mappings 'fonte _ user _ id []'

• 'email': normalização + prioridade 'KYC> CRM> LOGs'
• 'phone': normalização do E.164, slit de verificação
• `name`: Jaro-Winkler ≥ 0. 92, fallback - origem «KYC»
• 'address': objeto composto; combinação + prioridade de frescura
• Histórico: SCD2 ('valid _ from/valid _ to')
• Lineage: lista de campos de doador de referência
• Qualidade: coverage≥98%, dublikaty≤0. 3%
• SLO: frescura ≤ 1h, disponibilidade ≥ 99. 9%
• Proprietários: Data Platford, KYC/AML
• Riscos: conflitos de nomes, telefones «família», shared-devices

15) Resultados e recomendações

A fusão não é apenas «JOIN por chave», mas sim um caminho: contratos de fontes → identificação e deadfair → prioridades e «gravação de ouro» → CDC e atrasados → qualidade e observabilidade → segurança e histórico de mudanças.
Construa as regras de forma transparente, mantenha a auditoria de cada decisão, suporte a SCD e exactly-once. Assim, os dados de dezenas de fontes são transformados em vitrines confiáveis e métricas sustentáveis para o produto, analistas e ML.