GH GambleHub

Arquitetura de fluxo de dados

1) Atribuição e princípios

Metas: fornecer dados corretos, pontuais e completos para analistas, relatórios, antifrode, personalização e ML.

Princípios:
  • Data as a Produt: proprietários claros, contratos, SLO e versioning.
  • Schema-first: esquemas obrigatórios; Evolução de acordo com as regras.
  • Private-by-Design: Minimizar PII, apelidar, gerenciar acesso.
  • Observabilidade-by-Default: traçados, métricas, lineagem, perfis de qualidade.
  • Costa-aware: tiered-armazenamento, semente de eventos ruidosos, compressão.

2) Paisagem de fontes e eventos

Transacções: depósitos/conclusões, taxas/pagamentos, bónus, chargeback.
Usuários: sessões, cliques, conversões, limites RG, status KYC.
Operacionais: logs de aplicativos, métricas de desempenho, alertas.
Provedores PSP/KYC/sanções/estúdios de jogos (agregadores).
Diretórios de jogos, guias de países/moedas, tarifas/impostos.

Tipificação de eventos (exemplo):
json
{
"event_time":"2025-10-31T19:20:11Z",
"event_type":"payment. deposit",
"schema_version":"1. 3. 0",
"user":{"id":"U-123","country":"EE","age_band":"18-24"},
"payment":{"amount":200. 00,"currency":"EUR","method":"card","psp_ref":"PSP-222"},
"ctx":{"ip":"198. 51. 100. 10","session_id":"s-2233","trace_id":"f4c2..."}
}

3) Arquitetura de referência (high-level)

1. Camada Ingest

Passarelas (HTTP/gRPC), conectores CDC (de OLTP), filas/pneus (Kafka/Redpanda), coletores de telemetria.
Validação, normalização, edição PII na entrada, contracto enforcement.

2. Camada de streaming

Streaming de streaming (Flink/Spark Estrutured Streaming/Beam) com dedução, watermark, unidades de status.
Fã-out em armazéns e serviços online (fichestor, antifrode).

3. Camada Batch

Orquestração (Airflow/Dagster), downloads incorporados, battes e retroprocessadores, tipos SCD.

4. Armazenamento (Lakehouse)

Bronze: eventos crus (append-only, imutável).
Silver: tabelas limpas, com qualidade e dedução.
Gold: vitrines/assinaturas sob maletas específicas (BI/regulador/ML).
Formatos de tabela com ACID (Delta/Iceberg/Hudi), espalhados por camadas quentes/quentes/frias.

5. Serving e acesso

BI/SQL (Trino/Presto/DuckDB), camada semântica (metrics layer), API/GraphQL, Função Store para coerência online/offline.

6. Governance e Segurança

Diretório/linedge, regras DQ, motor político de acesso (RBAC/ABAC), camuflagem/Tocenization, arquivo WORM para relatórios.

4) Contratos e esquemas

Contratos de dados: OpenAPI/AsyncAPI/JSON Schema/Avro.
Evolução: versões semânticas; backward-compatível alterações - adição de campos nullable; breaking - apenas com '/v2 'e duplo registro para o período de migração.
Registros: Schema Registry, catálogo de domínios (Payments, Gamplay, Marketing).

5) Patrões de integração

CDC (Mudança Data Capture): de OLTP para pneu (Debezium), particionamento por chave de domínio.
Outbox/Inbox: entrega garantida de eventos de lógica de domínio.
Exactly-Once/Effectively-Once: transações no estato, idumpotentes sink 'e, chaves de dedução.
Late Data & Watermarks: processamento de eventos atrasados; janelas com allowed lateness.
Reprocessing: Pipinas Idumpotentes, time-travel, correções snapshot.

6) Modelo Lakehouse: bronze/silver/gold

Bronze (raw):
  • Partições de tempo (event _ data) e mercado (jurisdicção).
  • Apenas adicionar; armazenamento do payload original para forensica.
Silver (clean):
  • Tipos normalizados, guias, dedução por '(event _ id, event _ time)'.
  • Verificação FK, normalização de moedas/timeson, enriquecimento.
Gold (serve):
  • Vitrines denormalizadas (GGR, RG, LTV, tabelas de grupo).
  • SLA para atualização, unidades sob BI e relatórios.

7) Qualidade de dados (Data Quality)

Regras: validação de esquema, faixas, exclusividade, abrangência, integralidade referencial.
Perfil: distribuição, radicalidade, «deriva» de sinais.
Monitoramento: p50/p95 atraso de pipline, drop-rate, error budet.
Degradation policy: Folback automático (último snapshot), alertas e testes de métricas T.

Exemplo de contrato DQ (YAML):
yaml table: silver. payments rules:
- name: amount_positive type: range column: amount min: 0. 01
- name: currency_valid type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: unique_tx type: unique columns: [transaction_id]
slo:
freshness_minutes: 15 completeness_percent: 99. 5

8) Privacidade e complacência

PII Minimização e camuflagem: armazenar pseudo-ID, separar o look-up dos muppings.
Regionalização: baquetes/diretórios geo-locais (EEA/UK/BR), «data residency».
Transações legais: DSAR/PTBF (projeções computáveis e edições seletivas), Legal Hold, arquivos de relatórios imutáveis.
Loging de acesso: auditoria de leitura de tabelas sensíveis, break-glass e JIT.

9) Observabilidade e controle

Linedge: rastreamento automático das dependências entre a origem e a vitrine.
Métricas de Pipline: throughput, lag, failure-rate, cost/GB, cost/query.
Traçado (OTtel): 'trace _ id' dos aplicativos é inserido em eventos → construindo um caminho de consulta completo.
Alerts: orçamentos SLO, anomalias de frescura/volume/radicalidade.

10) Acesso e modelo de segurança

Categorias de dados: público/internacional/confidential/restricted.
Políticas: row/column-level security; camuflagem dinâmica (PAN/BAN/email).
Gerenciamento de chaves: KMS/CMK, criptografia at-rest/in-transit, rotação.
Segregação de responsabilidades: papéis separados de prod/analista/admin/revólver.

11) Data Mesh e abordagem de alimentos

Домены: Payments, Gameplay, Marketing, Risk, Compliance.
Data Product: proprietário, SLA recente, dicionário de campos, testes, versões, métrica de consumo.
Contratos entre domínios: versionáveis, compatibilidade backward, testes de consumo (consumer-driven).

12) Fichestor e fluxo ML

Função registry: descrição de sinais, fontes, transformações, SLO.
Coerência online/offline: um código de transformação, atraso na materialização online ≤ 200-500 ms.
Monitoramento à deriva: PSI/KS, auto e reversão de modelos, controle PII.
Registro de experiências: metadados, versões, reproducibilidade, mapas-modelo.

13) Finmodelagem e faturamento

Particionamento e Z-order/Cluster por predicado frequente.
Armazenamento frio e TTL para tabelas não utilizadas, VACUUM.
Materialize views apenas sob patterns de solicitação sustentáveis.
Quotas e orçamentos para jobs pesados; chargeback por comandos.

14) Topologia regional e multi-tenente

Multi-region ativo: replicação de tópicos e tabelas, perímetros pipeline independentes.
Failover/DR.: Alvo RPO/RTO, metadados do orquestrador, verificação de recuperação.
Multi-tenência: isolamento de diretórios/chaves/quotas, marcação de tenant _ id.

15) Processos e RACI (em resumo)

R: Data Platford (armazenamento, armazenamento, orquestração), Data Engineering (transformações).
A: Head of Data / Chief Data Officer.
C: Compliance/Legal/DPO, Arquitetura, SRE.
I: BI/Analista, Produto, Marketing, Finanças.

16) SLO/SLI para fluxos

Frescura (freshness): p95 atraso Silver ≤ 15 min, Gold (daily) pronto ≤ 06:00 lock. do tempo.
Abrangência: ≥ 99. 5% dos eventos por janela T.
Veracidade: erro-rate de verificação DQ <0. 5% do volume.
Disponibilidade de Serving: ≥ 99. 9% para BI/Função API.

17) Modelos de tabela e particionamento

sql
-- Bronze: Deposit events
CREATE TABLE bronze. payment_deposits (
event_time TIMESTAMP,
event_id STRING,
user_pseudo_id STRING,
amount DECIMAL(18,2),
currency STRING,
psp_ref STRING,
payload VARIANT
)
PARTITION BY DATE(event_time)
CLUSTER BY (currency);

-- Silver: normalized model
CREATE TABLE silver. payments AS
SELECT event_id,
CAST(event_time AS TIMESTAMP) AS ts,
user_pseudo_id,
amount,
currency,
psp_ref
FROM bronze. payment_deposits
QUALIFY ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY ts) = 1;

18) Orquestra e DevX

Infra-as-Código: Repositórios de pipinas, testes, ciúmes, GitOps.
Data Contracts CI: Linters de circuito, testes DQ antes do deploy.
Backfill-quadro: Retroprocessadores seguros com limitação de R/W e idempotency.
Diretórios e modelos: geradores de pipline (cookie-cutter), best-pratices.

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

MVP (4-6 semanas):

1. Pneu de evento + ingest de 2 a 3 fontes-chave (CDC OLTP, API).

2. Lakehouse Bronze/Silver, formato com ACID, catálogo e regras DQ básicas.

3. 1-2 Vitrines Gold (GGR diário e vórtice de conversão).

4. Métricas de lag/completeness, lineage básico, RBAC e camuflagem PII.

Fase 2 (6-12 semanas):
  • Unidades de streaming (p95 latency ≤ 5 min), Função Store, vitrines RG/AML.
  • Camada semântica de métricas, SLA para relatórios; As cabeçalhas.
  • Regionalização (EEA/UK), DSAR/PHILBF procedimentos, Legal Hold para artefatos.
Fase 3 (12 + semanas):
  • Data Mesh: domínios de alimentos, consumer-driven controls.
  • Operações ML com monitoramento à deriva, acordo automático online/offline.
  • Simulações automáticas de alteração de padrão (impact analysis) e «what-if» em termos de custo.

20) Erros frequentes e como evitá-los

Payload crus's sem padrão: implementar schema-first, maiúsculas e validação CI.
Sem dedução: chaves de evento e idempotent-sink no Silver.
Misturar PII com analíticos: separar os muppings e mascarar os campos.
Gold sem dono: atribuir owner, SLO e métricas de consumo.
Não há estratégia reprocessing: time-travel, versionização da lógica, controle de «dupla contabilidade».
Valor descontrolado: partituras, compressão, TTL, observabilidade do valor.

21) Glossário (breve)

CDC - Capturar alterações do OLTP.
Outbox - Publicamos eventos de domínio transacionalmente.
Watermark - uma estimativa da totalidade do fluxo para as janelas.
Lakehouse - data lake + tabelas ACID.
O Data Product é uma unidade de dados com proprietário e SLO.
A função Store é uma distribuição coerente de sinais ML.

22) Resultado

A arquitetura de fluxo de dados é um sistema de acordo controlado, como contratos claros, observabilidade, segurança e custo sob controle. Seguindo os patterns descritos (schema-first, bronze/silver/gold, CDC + Outbox, DQ e lineage, privacidade-by-design), a plataforma fornece de forma segura o negócio, a complacência e o ML com dados de qualidade com SLO previsível e um custo de posse compreensível.

Contact

Entrar em contacto

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

Telegram
@Gamble_GC
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.