GH GambleHub

Origem e caminho de dados

1) O que é o Data Lineage

O Data Lineage é um «histórico de vida» de dados, desde o local de nascimento (origem) passando por transformações e transferências até vitrines, relatórios e modelos. A linha responde às perguntas:
  • De onde vêm os números do relatório?
  • Quais tabelas/campos afetarão a alteração do padrão?
  • Porque é que o KPI mudou ontem às 21h?
  • Quais dados foram incluídos em um modelo específico e uma versão do ML?

Para iGaming, isso é crítico devido à regulação, relatórios financeiros (GGR/NET), antifrode, KYC/AML, jogo responsável e alta velocidade de alterações alimentares.

2) Níveis e granularidade da réja

1. Linha de negócios - ligação entre métricas e termos de negócios (de glossário) com vitrines/fórmulas.
2. Régua técnica (tabela) - ligações entre tabelas/jobs/pacotes de transformação.
3. Coluna (field/column-level) - que coluna de origem forma uma coluna de destino com regras.
4. Runtime-régua (operacional) - tempos, volumes, versões de código/circuito, artefatos de hash.
5. End-to-end é um caminho de passagem desde o provedor/PSP/CRM até o relatório/dashbord/modelo.
6. Cross-domain/Mesh - ligações entre produtos de domínio de dados contratados.

3) Valor-chave

Confiança e auditoria: Explicabilidade de relatórios e modelos, investigação rápida de incidentes.
Análise de impactos: mudanças seguras de padrão/lógica, previsibilidade de lançamentos.
Velocidade da linha, os novos analistas e engenheiros compreendem mais rapidamente a paisagem.
Conformidade: rastreabilidade do PII, Legal Hold, relatórios aos reguladores.
Otimização de custos: detecção de piplins mortos e vitrines duplicadas.

4) Objetos e artefatos

Entidades do gráfico: Fonte (provedor de jogos, PSP, CRM), Topic/Stream, Raw/Staging, Bronze/Silver/Gold, DWH, ML-fici, modelo BI, Dashboard.
Ligações: transformações (SQL/ELT), jobs (Airflow/DBT/...), modelos (versão), contratos (Avro/Proto/JSON Schema).
Atributos: proprietário, domínio, classificação, versão de esquema, controle de qualidade, frescor, SLO/SLI.

5) Fontes da verdade para a régua

Estático: parsing SQL/configs (dbt, ETL) → construindo dependências.
Dinâmico/Runtime: coleta de metadados durante a execução (operador no orquestrador, query logs).
Evento: lineage-ivents ao publicar/ler mensagens no pneu (Kafka/Pulsar), validação de contratos.
Manual (mínimo): descrição de uma lógica empresarial complexa que não é recuperada automaticamente.

6) Régua e Data Contracts

O contrato fixa o esquema, a semântica e a SLA.
A verificação de compatibilidade (semver) e a idempotação são obrigatórias.
A linha armazena um link para o contrato/versão e o fato de ter sido testado (CI/CD + runtime).

7) Régua em iGaming: exemplos de domínio

Eventos de jogo → unidades RTP, volatilidade, retenção, vitrine "Game Performance Gold'.
Pagamentos/conclusões/charjbacks → relatórios GGR/NET, antifrod.
KYC/AML → estatais, verificações, alertas → vitrines e relatórios.
Resolvível Gaming → limites/auto-exclusão → mapeamento de riscos e desencadeadores de intervenções.
Marketing/CRM → campanhas, bônus, saques → influência na LTV/ARPU.

8) Visualização do gráfico

Recomendações:
  • Dois modos: mapa da paisagem (macro) e faixa de passagem (micro) do campo para o campo.
  • Filtros: domínio, proprietário, classificação (PII), ambiente (pró/estágio), tempo.
  • Overlay: frescura, volume, erros DQ, versões de circuitos.
  • Ação rápida "Mostrar dependentes", "Quem consome esta coluna? ", "Caminho até dashbord KPI".

9) Análise e gerenciamento de alterações

Antes de alterar o padrão/lógica, execute o what-if: quais jobs/vitrines/dashboards/modelos afetará.
Geração automática de tíquetes para donos de artefatos viciados.
Pattern dual-write/blue-green para vitrines: v2 é preenchido paralelamente, comparando métricas, alternando.
Backfill playbooks: como e o que detetar dados históricos, como verificar consistência.

10) Régua e qualidade de dados (DQ)

Vincule as regras de DQ aos nós/campos do gráfico: validade, exclusividade, coerência, pontualidade.
Em caso de violações, mostre «segmentos vermelhos» nos caminhos e levante alertas para os proprietários.
Guarde a história dos incidentes DQ e sua influência no KPI.

11) Régua para ML/AI

Traçabilidade: datse → feures → training code → model (versão) → inference.
Capture as comitas, as opções de treinamento, as versões de quadro, os dados de validação.
A linha ajuda a investigar a deriva, regredir as métricas e reproduzir os resultados.

12) Régua e privacidade/complacência

Marquem PII/campos financeiros, países, lei (GDPR/local), base de processamento.
Assinale os nós onde você aplica camuflagem/pseudonimização/anonimato.
Para DSAR/Right to be forgotten, treme em que vitrines/bacapes o sujeito está presente.

13) Métricas (SLO/SLI) para régua

Coverage:% tabelas/campos com régua de coluna.
Freshness SLI: proporção de nós que se encaixam no SLA de atualização.
DQ pass-rate: proporção de verificações bem sucedidas em caminhos críticos.
MTTD/MTTR para incidentes de dados.
Mudar lead time: tempo médio de negociação e lançamento seguro do esquema.
Dead assets: proporção de vitrines não recuperadas/se.

14) Ferramentas (categorias)

Catalog/Glossary/Lineage: um único gráfico de metadados, importação de SQL/orquestradores/pneus.
Orquestração: coleta de metadados runtime, status de tarefas, SLA.
Schema Registry/Contracts: Verificações de compatibilidade, políticas de versão.
DQ/Observabilidade: regras, anomalias, frescuras, volumes.
Sec/Access: marcas PII, RBAC/ABAC, auditoria.
ML Registry: versão de modelos, artefatos e datasets.

15) Modelos (pronto para uso)

15. 1 Passaporte do site da linha

Nome/Domínio/Ambiente: Dono/Steward:
  • Classificação: Public/Internal/Confidential/Restricted (PII)
  • Origem/Ingressos: tabelas/topics + versões de contratos
  • Transformação: SQL/pois/repo + comit
  • Saídas/Consumidores: vitrines/dashboards/modelos
Regras DQ/SLO:
  • Sinais de observabilidade: frescor, volume, anomalias
Dependências de caminho crítico para KPI:
  • Histórico de incidentes - referências a tíquetes/pós-mortem

15. 2 Cartão de comunicação (column-level)

Do campo: schema. table. col (tipo, nullable)

No campo schema. table. col (tipo, nullable)

Regra de transformação: expressão/função/dicionário

Contexto de qualidade: verificações, faixas, arbitragens

15. 3 Playbook investigação do incidente

1. Definir KPI/dashboard afetado → 2) Seguir caminho para cima (Upstream) até a origem →

2. Verificar o frescor/volume/DQ em cada nó → 4) Encontrar a última alteração de código/padrão →

3. Comparar prod/stage/ontem → 6) Marcar fixação e backfill → 7) Pós-mortem e regra para o futuro.

16) Processos e integração

On-mudança: Cada merge em um repo que muda o padrão/SQL, executa o cruzamento de régua e a análise de impactos.
On-run: Cada um dos metadados bem-sucedidos/reprovados escreve os metadados runtime no conde.
Access-hooks: As solicitações de acesso mostram o caminho para o PII e os proprietários responsáveis.
Rituais Governance: revisão semanal de caminhos críticos, relatório mensal de SLO.

17) Mapa de trânsito de implementação

0-30 dias (MVP)

1. Definir KPI/dashboards críticos e seus caminhos end-to-end.
2. Conectar parsing SQL/jobs para régua de tabela.
3. Obter um passaporte de nó/comunicação e métricas mínimas de frescura.
4. Descrever marcas PII em caminhos-chave (KYC, pagamentos).

60-90 dias

1. Ir para column-level para as vitrines top.
2. Integrar metadados runtime do orquestrador (tempo, volume, estatais).
3. Ligar as regras DQ ao grafo, ligar as alertas.
4. Visualização: filtros por domínios/proprietários/PII, overlay de frescura.

3-6 meses

1. Contratos e registro de esquema no pneu de evento (fidas de jogo/pagamento).
2. Faixa completa de linha ML (dannyye→fichi→model→inferens).
3. A análise de impacto na CI → tíquetes automáticos para os proprietários das dependências.
4. Revestimento column-level ≥70% das vitrines ativas; relatórios SLO.

18) Pattern e anti-pattern

Pattern:
  • Graph-first: um único gráfico de metadados como «bússola» de alterações.
  • Linha Contract-aware: conexão com versões de circuitos e resultados de validação.
  • Observabilidade overlay: frescura/volume/DQ acima do grafo.
  • Produt-thinking: Proprietários de domínios publicam «produtos de dados» certificados.
Anti-pattern:
  • «Imagem por imagem», sem recolha automática ou apoio.
  • Meind maps manuais em vez de parsing e verdade runtime.
  • Não há detalhe de coluna em caminhos críticos do KPI.
  • Linha sem conexão com acessibilidade/PII e processos DSAR/Legal Hold.

19) Folhas de cheque prático

Antes de editar dados

  • Contrato atualizado, verificação de compatibilidade superada
  • Análise de dependências de impacto concluída
  • v2-vitrine coletada paralelamente, comparando métricas
  • Plano de backfill e retrocesso documentado

Revisão semanal

  • As vias críticas são verdes por frescor
  • Não há «órfãos» por causa das vitrines/vitrines
  • Incidentes DQ encerrados e documentados
  • Revestimento column-level> limite de destino

Resultado

A linha transforma os fluxos caóticos de dados em um mapa controlado da área, que mostra de onde vem, quem responde, quais são os riscos e como mudar de forma segura. Para iGaming é uma base de confiança em KPI, velocidade de experimentação e complacência madura.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.