Data Lake e DWH para cassinos: circuitos, downloads SLA

Texto completo do artigo

💡 18+. Material técnico para plataformas/operadoras, estúdios e equipes de análise. Não um apelo para o jogo. A plataforma inclui PAM/carteira/caixa/bônus/RG, sob provedores - RGS/live/jackpots/integração de pagamento.

1) Porquê os cassinos Data Lake e DWH

Relatórios e complicações: descarregamentos regulatórios (GGR/NGR, KYC/AML, RG), auditoria do dinheiro.

Produto/marketing: LTV/retenção, segmentação, A/B, recomendações.

Operações: monitoramento de provedores, PSP, jogos SLA ao vivo e bilheteria.

Soluções de dados: vitrines rápidas (DWH) sobre armazenamento de longo prazo barato (Lake).

Resultado: Lake armazena camadas cruas e limpas, DWH fornece consultas rápidas e modelos controlados.

2) Arquitetura arbitral (lakehouse)


Sources (OLTP, Kafka, Webhooks, CDC)
│
├─Bronze (raw, append-only; Parquet/Delta/Iceberg)
│   ingestion_time, source_metadata, no schema changes in place
├─Silver (cleaned, conformed; dedup, PII masking, SCD2)
│   business keys, constraints, quality checks
└─Gold (marts; star/snowflake; cube tables, aggregates)
└─DWH/Query Engines (Snowflake/BigQuery/Trino/Spark SQL)

Форматы: Delta Lake / Apache Iceberg / Hudi (ACID в lake, time travel, MERGE).

Arquivos: Parquet + ZSTD/Snappy, meta de £128-512 MB; compactuação de «arquivos pequenos».

Catálogo: Hive/Unity/Iceberg Catalog; zonas 'bronze/silver/gold' em baquetes per region/tenant.

3) Esquemas de domínio (conceituado)

3. 1 Carteira/contabilidade

`wallet_entry`: `entry_id`, `account_id`, `direction (debit	credit)`, `amount_minor`, `currency`, `reason`, `reference_id`, `occurred_at`, `region`, `tenant_id`, `trace_id`, `idempotency_key`.
Invariante: faturamento = saldo (através de snapshot + mudança jobs).

3. 2 Apostas/Setlent (RGS/live)

`bet`: `bet_id`, `round_id`, `player_id`, `game_id`, `stake_minor`, `currency`, `placed_at`, `brand/region`, `provider_id`, `in_bonus`.

`settlement`: `settlement_id`, `bet_id`, `round_id`, `win_minor`, `settled_at`, `jackpot_hit`, `bonus_state`.

3. 3 Pagamentos (caixa/PSP/cripto)

`payment_intent`: `intent_id`, `player_id`, `method`, `status`, `amount`, `currency`, `psp`, `created_at`.

'capture/refund/chargeback': tabelas individuais com referências a 'intent _ id', 'psp _ ref', códigos de causa.

Крипто: `txid`, `network`, `confirmations`, `finalized_at`.

3. 4 Bónus/vaivém/jackpots

`bonus_grant`, `bonus_progress (wager)`, `jackpot_contribution`, `jackpot_payout`.

3. 5 Guias e medidas

'dim _ player' (pseudo-ID, geo, canais, estatais RG - sem PII no analista), 'dim _ game', 'dim _ provider', 'dim _ psp', 'dim _ brand', 'dim _ region', medidas de calendário.

Chaves e compatibilidade: os modelos Silver/Gold incluem chaves de negócios estáveis ('bet _ id', 'round _ id', 'payout _ id', 'intent _ id') e uma semântica de eventos 'idempotados'.

4) Fluxos de download: estêncil + microbiatchi

Streaming (Kafka/Pulsar → Bronze): eventos OLTP e webhooks, outbox/CDC, garantias «pelo menos uma vez» com dedução no Silver.

CDC (Debezium/logs de replicação): altera tabelas OLTP (wallet/payments) → Bronze.

Microbiatchi: relatórios PSP/bancos/castody (SFTP/API) → Bronze Raw Files → normalização.

MERGE em Silver: Dedupo por 'idempotency _ key/event _ id', eliminação de atrasados ('watermark'), SCD2 nas medidas.

5) downloads SLA e janela de atraso (watermarks)

5. 1 SLA típicos (orientações)

Wallet/ledger events: Bronze ≤ 1-2 min, Silver ≤ 5-10 min, Gold marts ≤ 15 min

Bets/senslents: Bronze ≤ 1-2 min, Silver ≤ 10 min, Gold ≤ 30 min.

Payments (PSP webhooks): Bronze ≤ 5 min, Silver ≤ 15 min, Gold ≤ 30-60 min

Cripto finalidade: depende da rede; vitrines com lag N de confirmação.

Relatórios diários PSP/bancos: T + 1 até 09:00 locais da região.

5. 2 Janelas de atraso

Watermark na hora do evento ('occurred _ at') + tolerância:

carteira/aposta: 24-48 horas, pagamentos/PSP: 72 horas (há webhooks retráteis), cripto, até 24 horas para raras raras.
Eventos recentes reprocess: recontagem de vitrines Gold (MERGE), registro de correções.

5. 3 Comunicação SLA

O catálogo de dados contém atributos SLA: 'freshness _ target', 'freshness _ status', 'exposed _ lag _ p95', 'watermark'.

Dashboards de frescura com alertas de violação.

6) Qualidade dos dados (DQ) e contratos

Data Contracts para cada tema: esquemas Avro/JSON, semver, campos obrigatórios, invariantes de negócios (por exemplo, 'win _ menor ≥ 0', 'currency ∈ ISO-4217').

Verificações DQ Silver: unicidade das chaves, integridade arbitral, verificação de equilíbrio (comprovação da carteira), validade dos códigos PSP/causas, faixas de datas.

Severity: 'ERRO' (bloqueador), 'WARN' (marcador), 'INFO'.

Monitoring:% violações, causas top, tíquetes automáticos.

Sampling & replay: armazene Bronze crus para refino.

7) PII, residência e segurança

A vitrine PII está separada dos analistas em Silver/Gold - pseudônimo, camuflagem/hashtag, tocenização.

Data residency: EU/UK/BR, etc. - baquetes/diretórios individuais; Não há leitura cruzada regional sem consentimento ou proxy.

Доступ: RBAC/ABAC (Lake/DWH), row-level security по `tenant/brand/region`.

Criptografia: at-rest (KMS) e in-transit, chaves per region/brand, auditoria do WORM de acesso e alterações de políticas.

Direito de esquecimento: mecanismo de localização de dados de jogo sem remoção de registros financeiros (de identificação).

8) Modelagem de vitrines Gold (estrela)

8. 1 Factos-tabela

'fact _ bets' (aposta e setlent por linha/ou duas tabelas), 'fact _ wallet _ entries', 'fact _ payments' (depósitos/cachês/devoluções), 'fact _ bônus _ wager', 'fact _ jackpot'.

8. 2 Medidas

`dim_date/time`, `dim_player` (pseudonymous), `dim_game`, `dim_provider`, `dim_psp`, `dim_brand`, `dim_region`, `dim_currency`.

8. 3 Métricas e cálculos

GGR/NGR, retenção/frequência, RTP (por jogo/provedor/região), conversão de depósito, setle lag, sucess-rate PSP, cut-per-sucess, FX-PnL, jackpot solvence/payouts.

9) Desempenho e custo

Particionamento por 'occurred _ data' + 'region/tenant', às vezes 'game _ id' para os equipamentos Gold.

Clusterização/Z-Order: por 'player _ id', 'game _ id', 'psp', 'currency'.

Compactação e vácuo: programados por 'OPTIMIZE/COMPACT', removendo versões pendentes (considerando os retoques legais).

Cash: result-cachê/warehouse cachê, materializante views para painéis quentes.

Índices em DWH: cluster/segmentação (Snowflake clustering keys, BigQuery partition + cluster).

Custo: Bronze frio em armazenamento de objetos, equipamentos Gold/março quentes em DWH; auto-estacionamento/auto-skale.

10) Régua, diretórios e documentação

Data Catalog (OpenMetadata/Amundsen/Collibra): descrição de tabelas, proprietário, SLA, campos PII, políticas de acesso.

Régua: desde a origem (evento/CDC) até a vitrine e relatório; visibilidade das dependências para alterações seguras.

Changelog circuitos: semver e registro de decolagens; testes de compatibilidade em CI piplins.

11) Reconciliação (compilação de dados)

Diariamente:

'wallet _ entry' ↔ balanços finais (acumulação de ≡), pagamentos: relatórios PSP/bancos ↔ 'fact _ payments', cripto: 'txid/network' ↔ 'fact' payments'.
Категории: `match`, `timing`, `missing_source`, `missing_platform`, `amount_mismatch`.
Alertas: «mismatch»> limiar; aging não acertados> N dias.

12) Tabelas SLA de instâncias (exemplo)

Domínio	Bronze (ingest)	Silver (limpar)	Gold (março)	Eventos tardios (watermark)
Wallet	≤2 minas	≤10 minas	≤15 minas	48 h
Bets/Settlements	≤2 minas	≤10 minas	≤30 minas	48 h
Payments (PSP)	≤5 minas	≤15 minas	≤60 minas	72 h
Crypto	realtime→finalnost	≤15 minas	≤60 minas	24 h
Reports (T+1)	06:00–08:00	≤09:00	≤10:00	7 d

13) Pipinas: de onde coletamos

Ingestion: Kafka Connect/Debezium, serviços de ingestão na nuvem, SFTP pullers.

ETL/ELT: Spark/DBT/Trino/Beam/Flink (Silver de streaming), Airflow/Argo para orquestra.

Qualidade: Great Exportações/Deeqab/dbt testes.

Monitoramento: OpenTelemetry + métricas Lake/DWH (freshness delay, job latency, cost).

Acidentes e repetição: reprocess de Bronze, chaves de dedução, piplines versionadas.

14) Folhas de cheque

Arquitetura e segurança

Formato Lakehouse (Delta/Iceberg/Hudi) com ACID e time travel.
Separação 'bronze/silver/gold', outbox/CDC como as principais fontes.
Isolamento PII, Tocenização, RLS por 'tenant/brand/region'.
Residência no nível de baquetes/diretórios, chaves/segredos per region.
Auditoria WORM de alterações em esquemas/políticas/regras de acesso.

Qualidade e SLA

Data Contracts e diagramas semver; testes de compatibilidade.
Watermarks e reprocess, vitrines incorporadas MERGE.
Dashboards de frescura e alertas SLA; owner em cada tabela.
Reconciliação por carteira/pagamento/cripto.

Produtividade e custo

Particionamento e clusterização; compactuação de «arquivos pequenos».
Vitrines materializadas sob relatórios-chave.
Scale automático/auto-arquivamento, política de retencagem e arquivos.

15) Bandeiras vermelhas (anti-pattern)

BI e relatórios regulatórios atingem diretamente o OLTP.

Bronze «reescreve» e perde dados crus.

Sem watermarks, eventos recentes são «cortados».

Não há dedução por 'idempotency _ key '/' event _ id' → uma dupla no Gold.

PII e dinheiro de diferentes regiões são armazenados juntos sem RLS e residência.

Os circuitos mudam «silenciosamente» (sem semver/contratos), quebrando as vitrines.

Milhões de pequenos arquivos de parcelamento sem compactuação → pedidos caros.

Não há SLA/dashboards de frescura; «surpresas» no relatório trimestral.

16) Conclusão

O Data Lake + DWH no iGaming não é apenas um armazém, mas um ecossistema controlado, como circuitos e contratos normalizados, ACID-lakehouse, SLA de frescura e janelas de atraso, qualidade e linha, segurança PII e residência. Adicione a reconciação e a economia na partilha/compactação - e você terá as bases para relatórios, soluções de alimentos e escalonamento de negócios sem migração noturna ou «Excel manual».