GH GambleHub

Armazéns de dados

1) Atribuição e papel DWH em iGaming

DWH é a camada central de consolidação e servinagem de dados para relatórios, analistas, complens e ML. Ele fornece:
  • Definições de métricas (GGR/NGR, ARPU, Retenção, Churn).
  • Relatórios reaproveitáveis para reguladores e steakholders internos.
  • Vitrines rápidas para BI/painéis operacionais e fontes para modelos.
  • Controle de qualidade, lineage e segurança ao nível da plataforma.

2) Opções arquitetônicas

2. 1 Classic DWH

ETL → DWH → BI.
Os benefícios são modelos controlados, forte consistência.
Contras: downloads caros, backfill complexo, flexibilidade limitada.

2. 2 Lakehouse DWH

Bronze/Silver/Gold em tabelas ACID (Delta/Iceberg/Hudi) + motor SQL/MPP.
Os benefícios são um único storage, time-travel, simples reprocessing.
Contras: exige disciplina de camadas e DQ, orquestração madura.

2. 3 Híbrido

Lakehouse como «fonte da verdade» (Bronze/Silver), DWH-Março em MPP (ClickHouse/Pinot/Druid/Cloud DWH) para leitura de alta velocidade.
Vantagens: equilíbrio de custo e desempenho, vitrines flexíveis.
Contras: suporte duplo para circuitos e patins, preciso de sincronização.

Recomendação: para iGaming - Lakehouse + DWH-março (híbrido). Bronze/Silver - Normalizam, Gold/Real-time marts - atendem a cargas de leitura.

3) Simulação de dados

3. 1 Estrela e Flocos de Neve

Os factos da tabela são estreitos, os eventos são 'fact _ bets', 'fact _ payouts', 'fact _ payments'.
Medidas: 'dim _ users' (SCD), 'dim _ games', 'dim _ providers', 'dim _ markets'.
O floco de neve é apropriado em Silver (normalização) e a estrela em Gold (leitura).

3. 2 Data Vault 2. 0 (núcleo de integração)

Hubs (chaves de negócios), Links (relacionamentos), Satélites (contexto/história).
Aplicar no Silver para integrações de longo prazo de provedores/PSP.

3. 3 SCD I/II/III

SCD II para RG/KYC/canais e atributos de jogo (RTP/volatilidade).
Espaçamento rigoroso 'valid _ from/valid _ to', join-s corretos no tempo.

4) Download: ETL/ELT, CDC e encartes

Abordagem ELT: download no Silver → transformação em DWH.
CDC: Debezium/logo-replicação do OLTP; Os maus são idimpotentes.
Encartes: por água do tempo ('updated _ at> max _ loaded _ ts') e/ou hash-delt.
Backfill/Reprocessing: time-travel, faixas, quotas, dry-run comparações.

MERGE (exemplo):
sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) Camada semântica e métricas

Metrics Store/Semantic Layer: fórmulas unificadas GGR/NGR/Conversion/LTV.
Versionização de métricas e computação «as-of» para reprodução.
Acordos: nomes de métricas, unidades de medição, divisas (base EUR) e 'fx _ fonte'.

6) Vitrines e Serrinha

Vitrines Gold: denormalizado, SLA pronto (por exemplo, até às 06:00) .
Assinaturas operacionais: ClickHouse/Pinot/Druid para painéis de 1 a 5 minutos.
Exportar CSV/JSON/PDF + hash; pacotes imutáveis (WORM) para reguladores.

Exemplo do GGR Daily:
sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

7) Qualidade dos dados (DQ) e contratos

Schema-first: JSON/Avro registry + testes de compatibilidade (consumer-driven).
DQ-как-код: completeness/validity/uniqueness/FK/range/temporal.
Políticas de reação: critical → fail + DLQ; major/menor → marca e relatório.
Observabilidade DQ: dashboards Freshness/Completeness/Validity, vórtice de registros perdidos.

8) Segurança, privacidade e residência

Minimização PII: usuários via pseudo-ID; muppings separados.
RLS/CLS: acesso por voz/pós-Holbtzo por papéis e jurisdições.
Criptografia: TLS in-transit; at-rest - KMS/CMK rotativo.
Data Residency: diretórios e chaves individuais para EEA/UK/BR; proibição de join's cruzados sem fundamento.
DSAR/PTBF: projeções computáveis e edições seletivas; Legal Hold para artefatos relatórios.

9) Desempenho e custo (Costa Engenharia)

Particionamento: por data/mercado/tenante; clusterização/Z-order por 'market', 'provider _ id', 'game _ id', 'user _ pseudo _ id'.
Formatos: Parquet + estatísticas e compressão; OPTIMIZE/VACUUM programado.
Materialização: unidades estáveis e tabelas summary; Evite «gordo» join's para voar.
Quotas/Chargeback: orçamentos para pedidos pesados/réplicas; relatórios de costa/query, de custo/GB.
Tiered storage: hot/warm/cold; nítidos SLA de recuperação.

10) Observabilidade e controle

Métricas de pipas: duração, volumes, retais, lajes, resistência a falhas.
Métricas DWH: tempo de resposta/competição/sucesso em dinheiro/custo.
Lineage: grafo desde fontes até relatórios; Análise de impact nas alterações.
SLO: Freshness Silver p95 ≤ 15 мин; Gold daily - pronto até às 06:00; Validity ≥ 99. 9%; Completeness ≥ 99. 5%; disponibilidade ≥ 99. 9%.

11) Multiplicidade e isolamento de domínio

Divisão por schema/banco/catalog por tenante/mercado.
Quotas e resource groups; limitação de «vizinhos barulhentos».
Políticas de exportação/importação entre tenentes, contratos normalizados.

12) Registro de dados e documentação

Data Catalog: owner, SLA, esquema, exemplos, regras DQ, lineage.
Métricas/dashboards: cartões com fórmulas e responsáveis.
Mudar Jobs: versões de lógica, migração, influência.

13) Processos e RACI

R (Resolvível): Data Engineering (modelos Silver/Gold, DAG 'i), Data Platford (Infra, Registry, DQ).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed): BI, Produto, Marketing, Operações.

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

MVP (4-6 semanas):

1. Lakehouse Bronze/Silver (tabelas ACID), CDC/encartes para Payments/Gamplay.

2. As primeiras vitrines Gold (GGR Daily), SLA até as 06:00.

3. DQ-como-código (10-15 regras) + dashboards Freshness/Completeness.

4. Catálogo de dados e camada semântica básica de métricas.

Fase 2 (6-12 semanas):
  • SCD II для users/games/providers; extensão de domínios.
  • Assinaturas operacionais (ClickHouse/Pinot) para painéis reais-time/near-real-time.
  • Lineage/impacto-análise, DSAR/PHILBF procedimentos, regionalização (EEA/UK).
Fase 3 (12 + semanas):
  • Simulação automática de alterações (dry-run), réplicas e comparação de métricas.
  • Chargeback/quotas, Ensinamentos de DR. e time-travel recuperação.
  • Geração automática da documentação de vitrines e cartões de métricas.

15) Exemplos de modelos SQL

Fato das apostas (Silver, 3NF):
sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);
Conexão com SCD II (obter status RG no momento da aposta):
sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);
Controle da totalidade dos mercados:
sql
SELECT market, DATE(event_time) d, COUNT() n
FROM silver. fact_bets
GROUP BY market, DATE(event_time)
HAVING n = 0;

16) Folha de cheque antes de vender

  • Esquemas e contratos no registro, testes de compatibilidade são verdes.
  • CDC/encartes e procedimentos MERGE são idepotentes.
  • As vitrines gold têm SLA, as fórmulas de métricas são fixadas.
  • As regras DQ estão ativas (critical → fail + DLQ), os dashboards Freshness/Completeness.
  • RBAC/ABAC, criptografia, residência por região, registros de acesso.
  • Lineage/impacto estão incluídos; time-travel/backup/DR. testados.
  • Valor sob controle: partituras, clusterização, materialização, quotas.

17) Anti-pattern e riscos

«Um DWH gordo sem camadas»: mistura de dados crus e relatórios → caos e correções caras.
Full reload diariamente sem necessidade: use encartes/CDC.
Gold sem dono e fórmulas: falta de uma versão unificada da verdade → controvérsia e regressão.
PII em camadas analíticas: mantenha os muppings separados, CLS/RLS.
Falta de DQ/lineage: não há comprovação para reguladores/auditorias.
Custo descontrolado: sem partituras/otimizações/quotas.

18) Glossário (breve)

DWH - Armazenamento de dados para consolidação e analistas.
Lakehouse - data lake + tabelas ACID e SQL.
CDC - Capturar alterações do OLTP.
SCD - Dimensões que mudam lentamente (I/II/III).
A vitrine Gold é um relatório/apresentação pronto para o consumo.
O Semantic Layer é uma única definição de métricas e atributos.

19) Resultado

O DWH moderno para iGaming não é uma «grande tabela», mas uma plataforma controlada: camadas Bronze/Silver/Gold, contratos rigorosos e DQ, métricas e lineage unificados, privacidade e residência, produtividade e economia. Construindo o híbrido Lakehouse + DWH-Março, você terá uma tomada de decisões rápida e verificável, pronta para auditoria, escala e novos mercados.

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.