GH GambleHub

Lagos de dados e agregação de fluxos

1) Destino e valor

Data Lake/Lakehouse é uma camada de apoio de armazenamento prolongado e leitura em larga escala onde:
  • Os fluxos de produtos/jogos/pagamentos aterrissam em Bronze «como estão».
  • Silver normaliza e enriquece, fornecendo chaves e qualidade alinhadas.
  • Gold - vitrines agregadas (incluindo real-/near-real-time) para BI, reguladores, antifrode/RG.

A agregação de fluxos para Lakehouse oferece baixo atraso nos relatórios, custo previsível, reprodutividade e forensagem.

2) Arquitetura de arbitragem

1. Ingest/Edge: HTTP/gRPC, OTel, batch endpoints → шина (Kafka/Redpanda).
2. Bronze (append-only): armazenamento de objetos + ACID tabelas (Delta/Iceberg/Hudi), partitações by data/market/tenant; armazenamento do payload original.
3. Stream Compute: Flink/Spark/Beam - Máquinas de janelas, CEP, Deadup, online-lookups.
4. Silver (clean/conform): normalização de moedas/temporizão, FK/guias, SCD para medição.
5. Serving/OLAP: ClickHouse/Pinot/Druid - unidades materializadas de minutos/segundos para painéis.
6. Gold (serve): vitrines diurnas/relógios, cortes regulatórios, pacotes de exportação imutáveis (WORM).
7. Caminhos de controle: Schema Registry, DQ-de-forma, lineage, diretórios, segredos/KMS, RBAC/ABAC.

3) Contratos e esquemas

Schema-first: JSON/Avro/Protobuf; campos obrigatórios: 'event _ time (UTC)', 'event _ id', 'trace _ id', 'user _ pseudo _ id', 'market', 'schema _ versão'.
Evolução: back-compatível → adicionar nullable; breaking → '/v2 '+ dupla gravação.
Catálogo: descrição de domínio, proprietário, SLA recente, regras DQ, lineage.

4) Pousar fluxos para o lago

Exactly-once no fundo: at-least-once publicação + idumpotente (MERGE/upsert por 'event _ id').
Deadup: stateful em strip + exclusividade em Silver.
Compactação de arquivos: small files → OTIMIZE/VACUUM regulares para leitura e custo.
Time-travel: inclui depuração, réplicas e auditoria.

Exemplo de Iceberg Particionamento (DDL-Ideia):
sql
CREATE TABLE bronze. payment_events (
event_id STRING, user_pseudo_id STRING, currency STRING,
amount DECIMAL(18,2), market STRING, event_time TIMESTAMP, payload STRING
)
PARTITIONED BY (days(event_time), market);

5) Agregação de fluxo: janelas e watermarks

Janelas:
  • Tumbling - fixos (por exemplo, 1 min/5 min) para painéis estáveis.
  • Hopping - Sobrepor (passo
  • A Sessions é uma ruptura comportamental por inatividade.
  • Watermarks: controle de late data (normalmente de 2 a 5 minutos), regras de pré-emissão/correção.
Flink SQL - depósitos de 1 minuto de mercado:
sql
SELECT market,
TUMBLE_START(event_time, INTERVAL '1' MINUTE) AS ts_min,
COUNT() AS deposits_1m,
SUM(amount_base) AS sum_1m
FROM silver. payments
GROUP BY market, TUMBLE(event_time, INTERVAL '1' MINUTE);

6) Materialização das unidades

Motor OLAP (ClickHouse/Pinot/Druid): armazena unidades de minutos/segundos para dashboards e analistas operacionais.
Lakehouse Gold: armazena cortes diários/horários para relatórios e reprodutividade.

ClickHouse - materializante view (GGR de um minuto):
sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream. game_events
GROUP BY ts_min, market, provider_id;
Gold - Corte diurno (Lakehouse):
sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(event_time) AS event_date,
market, provider_id,
SUM(stake_base) AS stakes_eur,
SUM(payout_base) AS payouts_eur,
SUM(stake_base) - SUM(payout_base) AS ggr_eur
FROM silver. fact_game_financials
GROUP BY 1,2,3;

7) Silver: normalização e concordância

Hora e moeda: 'event _ time (UTC)', 'amount _ base', 'fx _ rate _ used', 'fx _ fonte'.
Chaves/guias: 'user _ pseudo _ id', 'game _ id', 'provider _ id', 'market'.
SCD II: histórico de medições (users/games/providers/RG/KYC).
Regras DQ: exclusividade das chaves, guias, faixas de quantia, validação temporária.

8) Registro de unidades e definições «corretas»

Semantic Layer: fórmulas unificadas GGR/NGR, apostas/ganhos, conversão, ARPU, latency p95.
Versionização de métricas: 'metric _ version' e 'as-of' do cálculo.
Cartões de doutor owner, fórmula, fontes, SLA pronto.

9) Exactly-once/idempotação e ordem

Pneu: at-least-once + particionamento (ordem local).
Processamento: Deadup por 'event _ id' (TTL 24-72h), operadores CER/janelas ajustadas.
Sink: empresas transaccionais ou idempotent upsert/merge.
Outbox/Inbox: publicação de eventos de domínio do OLTP com garantia.

10) Late data e ajustes

Allowed lateness: 2-5 min para vitrines operacionais; cruzamentos diários para a Gold.
Correções: Pré-emissão em OLAP e adutora Gold (idempotent).
As bandeiras são 'late = true', 'correção _ of = <event _ id>' para a auditoria.

11) Observabilidade e DQ

SLI/SLO (referências):
  • p95 ingest→1 -min de vitrine ≤ 2-5 c; Gold daily está pronto antes das 06:00.
  • Completeness ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
  • Métricas de pipas: lag/throughput/busy time/state size, late-ratio, dup-rate.
  • DQ-dashboards: Freshness/Completeness/Validity, vórtice de perdas, cartão de chaves quentes.
  • Lineage: caminho de Bronze a Gold/exportação; Análise de impact nas alterações.

12) Privacidade, residência, segurança

Minimização PII: pseudônimo, mapping protegido separado.
Residency: EEA/UK/BR - diretórios individuais e chaves de criptografia; proibição de join's cruzados sem fundamento.
Criptografia: TLS in-transit; KMS/CMK at-rest; assinaturas de exportação + WORM no regulador.
DSAR/PTBF/Legal Hold: edição seletiva, congelamento de remoções, acessibilidade auditada.

13) Desempenho e custo

Particionamento: por data/mercado/tenante; clusterização/Z-order para atributos frequentemente filtrados.
Compactação: eliminação de small files, OTIMIZE/VACUUM regular.
Materialização: minutos/segundos - em OLAP; 24 horas/relógio - em Gold.
Armazenamento Tiered: hot/warm/cold, SLA restauração, chargeback por comandos (custo/GB, vale/query).
Pré-regulação/sketches: HyperLogLog/approx-distinct onde for aceitável.

14) Exemplos (fatias)

Flink CEP - Estruturação de depósitos (10 min):
python if count_deposits(window=10MIN) >= 3 \
and sum_deposits(window=10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window_events):
emit_alert("AML_STRUCTURING", user_id, snapshot())
SQL - Deadup quando carregado no Silver:
sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time) rn
FROM bronze. payment_events p
) WHERE rn = 1;
Iceberg/Delta - MERGE idumpotente:
sql
MERGE INTO silver. fact_bets s
USING stage. fact_bets_delta d
ON s. bet_id = d. bet_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

15) Processos e RACI

R (Responsible):
  • Data Plataforma (Lakehouse/catálogo/ACID, compactação),
  • Streaming (unidades/CEP/dedup),
  • Domain Analytics (métricas/Gold).
  • A (Accountable): Head of Data/CDO.
  • C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), SRE (SLO/стоимость), Security.
  • I (Informed): BI/Produto/Marketing/Operações.

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

MVP (3-5 semanas):

1. Lakehouse Bronze/Silver (tabelas ACID), ingest de Kafka, diagramas de registro.

2. Unidades estrim básicas (1-5 min) na OLAP; vitrine Gold. ggr _ daily (D + 1 antes das 06:00).

3. DQ-como-código para Payments/Gamplay, dashboard Freshness/Completeness.

4. Compactuação/OPTIMIZE, métricas e alerts lag/late/dup mínimos.

Fase 2 (5-10 semanas):
  • Extensão Silver (SCD II para users/games/providers), lineage e análise de impacto.
  • Lookups asinhrônicos (RG/KYC/ASN/BIN), gerenciamento de regulações late.
  • Camada semântica de métricas, regulamento de exportação (WORM/assinaturas).
Fase 3 (10-16 semanas):
  • Multi-região, DR./replay-simulador, janelas auto-tuning e watermarks.
  • Costa-dashboard, chargeback/quotas, armazenamento tiered e arquivamento.
  • Geração automática da documentação de vitrines e cartões de métricas.

17) Folha de cheque antes de vender

  • Esquemas e contratos no registro; back-compat testes são verdes.
  • Incluído deadup, watermark/allowed lateness, DLQ.
  • Compactação/OPTIMIZE/VACUUM são configurados como programado.
  • SLO: p95 ingest→minute-view, Gold до 06:00; alert lag/late/dup/state size.
  • As regras DQ estão ativas; lineagem visível de Bronze a exportação.
  • RBAC/ABAC и KMS; Residência e DSAR/PTBF/Legal Hold testados.
  • Custo sob controle (custo/GB, custo/query, porção cold), limites para réplicas.

18) Anti-pattern e riscos

Mistura de dados crus e relatórios em uma tabela: quebra a representatividade.
Falta de compactação: explosão de small files → pedidos caros.
Cálculo FX «retroativo»: quebra o histórico e os relatórios.
Não há watermarks/late-política, «nadar» vitrines e alertas.
Full reload sem necessidade: use encartes/MERGE e ajustes.
PII em análise: Mantenha os muppings separados, inclua CLS/RLS.

19) Glossário (breve)

Lakehouse - data lake + tabelas ACID e SQL.
Bronze/Silver/Gold - camadas crus/normalizadas/servingo.
Watermark é o limite de preparação das janelas por event-time.
O MaterializView é uma vitrine pré-desenhada para leitura rápida.
Time-travel - leitura de versões históricas de tabelas.
WORM - armazenamento imutável de artefatos de exportação.

20) Total

Um lago de dados com uma agregação estrim correta é uma disciplina de camadas e contratos: Bronze «como é», Silver para normalização e qualidade, OLAP para painéis de minutos, Gold para relatórios reproduzidos. Gerenciando janelas e watermarks, dedução e compactação, privacidade e valor, você recebe vitrines rápidas, verificáveis e complicadas para o produto, a complacência e o gerenciamento operacional.

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.