GH GambleHub

Processamento de sinais em tempo real

1) Atribuição e valor de negócio

O fluxo real-time é necessário para reagir «aqui e agora»:
  • Antifrod/AML: Estruturação de depósitos, «mulilação», ataques velocity.
  • Resolvível Gaming (RG): excesso de limites, pattern de risco de comportamento.
  • Risco/Complaens: Screening de sanções para registro/transação online.
  • Personalização: desencadeadores de bónus/missões, campanhas.
  • Operações/SRE: degradação da SLA, escalas de erros, anomalias de métricas.

Metas-chave: atraso baixo (p95 0. 5-5 c), alta totalidade (≥99. 5%), resistência a picos.

2) Taxonomia de sinais

Transaccionais: 'payment. deposit/withdraw/chargeback`.
Jogos: 'game. bet/payout`, `game. session_start/stop`.
Autenticação: 'auth. login/failure ', mudança de dispositivos/geo.
Comportamentos: velocidade das apostas, aumento exponencial, atividade noturna.
Operação: 'api. latency`, `error. rate ', «tempestade» de reinício.

Cada tipo tem padrão, dono (domain owner), criticidade, SLO e regras «late data».

3) Arquitetura de referência real-time do circuito

1. Ingest e pneu: HTTP/gRPC → Edge → Kafka/Redpanda (particionamento por 'user _ id/tenant').
2. Streaming-движок: Flink/Spark Structured Streaming/Beam; operadoras estateful, CEP.
3. Enriquecimento on-line: tabelas lookup (Redis/Scylla/ClickHouse Read-Only), provedores (sanções/CUS).

4. Sinki:
  • Alert topics/kew (gestão de case, SOAR).
  • Fichestor online (compilação de modelos).
  • Vitrines gold strim (dashboards operacionais).
  • Armazenamento «quente» para analistas rápidos (ClickHouse/Pinot/Druid).
  • 5. Arquivo/forense: dobrável inalterável em Lake (Parquet, time-travel).
  • 6. Observabilidade: trailing/métricas/logs + lineage.

4) Janelas, watermarks e «late data»

Tipos de janelas:
  • Tumbling: janelas fixas (por exemplo, 1 min) - unidades simples.
  • Hopping: sobreposição (por exemplo, passo 30 c, janela 2 min) - métricas «suaves».
  • Separações de inatividade - análise comportamental.
  • Watermarks: limite de «conhecimento do tempo» para o event-time; aceitamos o atraso (allowed lateness, por exemplo, 2 min).
  • Estratégias tardias: pré-emissão de ajustes, refino «late = true», DLQ.

5) Operadoras e deduções stateful

Chave por 'user _ id', 'payment. account_id`, `device_id`.
Estado: somadores, contadores deslizantes, filtros bloom para idempotency.
Deadup: armazenamento '(event _ id, seen _ at)' no state/kv; TTL = 24-72 h.
Exactly-Once: transacções sink 'e (2-phase), operações upsert idumportantes.

6) Enriquecimento de fluxo

Lookup-joynes: limites RG, risco-screen do usuário, nível KYC, geo/ASN.
Chamadas asincrônicas: registro de sanções/provedores antifrod (async I/O, temporizadores e fallback).
Normalização das moedas/temporizão: unificação para UTC e moeda básica; fixar 'fx _ fonte'.

7) CEP: detecção de patters complexos

Exemplos de regras:
  • Estruturing: ≥3 de depósito de 10 min, cada porta de relatório <, total> X.
  • Device-switch: 3 dispositivos diferentes em 15 min + mudança IP/ASN.
  • RG-fatiguue: taxas totais de 1 hora> limite + perder ≥ Y.
  • Ops-storm: p95 latency> 2 x base, 5xx> 3% na janela de 5 minutos.

O CEP é conveniente para expressar no Flink CEP/SQL ou nas bibliotecas de modelos de evento.

8) Fici on-line e modelos

Função pipelines: contadores, velocity-métricas, «hora do último evento», share-of-wallet.
Coerência online/offline: uma base de dados de transformação; Testes de readaptação.
Mapeamento: modelo light (logit/GBDT) sincronizado; pesada - asincrona através da fila.
Controle da deriva: PSI/KS e alertas; «lançamentos escuros» para novos modelos.

9) Garantias de entrega e ordem

At-least-once no pneu + idempotidade na recepção.
A partilha por chave fornece ordem local.
Retrees & backpressure: Retraias exponenciais com jitter, controle automático de pressão.

10) SLO/SLI (recomendados)

IndicadorAlvo
p95 end-to-end latency (ingest → alert)≤ 2 c (creta.) , ≤ 5 c (necrito.)
Completeness por janela T≥ 99. 5%
Erros de esquema/validador≤ 0. 1% dos eventos
Proporção de eventos com trace _ id≥ 98%
Alert precisão/recall (alvos de domínio)≥ 0. 8 / ≥ 0. 7
Disponibilidade do serviço estrim≥ 99. 9%

11) Observabilidade real-time do circuito

Métricas de pipline: throughput, lag per partition, busy time, checkpoint duration.
Qualidade dos sinais: completeness, duplication rate, late ratio.
Dashboards: mapa térmico de lajes de topic, alert vórtice (sobytiye→pravilo→keys), mapa de chaves quentes.
Tracing: vincule o alert aos eventos originais (trace _ id).

12) Segurança e privacidade

Minimização PII: Tocinização de ID, camuflagem de campos sensíveis.
Geo-residency - linhas de montagem regionais (EEA/UK/BR).
Auditoria: logs de soluções imutáveis (quem, porquê), Legal Hold para malas.
Acesso: RBAC a regras/modelos, duplo controle de extração.

13) Custo e desempenho

Chaves quentes: redistribuição (key salting), composite keys.
Estado: TTL razoável, materialização incorporativa, sintonização RocksDB.
Janelas: tamanho ideal e alowed lateness; camadas de pré-agregação para fluxos «ruidosos».
Samplying: em fluxos não ritíticos e no nível de métricas (não em transações/compliance).

14) Exemplos (simplificado)

Flink SQL - Depósitos de estruturing (janela de 10 min, step 1 min):
sql
CREATE VIEW deposits AS
SELECT user_id, amount, ts
FROM kafka_deposits
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY ts
MEASURES
FIRST(A. ts) AS start_ts,
SUM(A. amount) AS total_amt,
COUNT() AS cnt
ONE ROW PER MATCH
AFTER MATCH SKIP PAST LAST ROW
PATTERN (A{3,})
WITHIN INTERVAL '10' MINUTE
) MR
WHERE total_amt > 500 AND cnt >= 3;
Pseudocode anti-velocidade em apostas:
python key = event. user_id window = sliding(minutes=5, step=30)   # hopping window count = state. counter(key, window)
sum_amt = state. sum(key, window)
if count > 30 or sum_amt > THRESH:
emit_alert("RG_VELOCITY", key, snapshot(state))
Deadup de event _ id (Kafka Streams):
java if (!kvStore.putIfAbsent(event. getId(), now())) {
forward(event); // unseen -> process
}

15) Processos e RACI

R (Resolvível): Streaming plataforma (infra, estado, lançamentos), Domain Analytics (regras/fichas).
A (Accountable): Head of Data/Risk/Compliance em seus domínios.
C (Consulted): DPO/Legal (PII/retenção), SRE (SLO/Incidentes), Arquitetura.
I (Informed): Produto/Suporte/Marketing.

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

MVP (2-4 semanas):

1. 2-3 sinais críticos (por exemplo, 'payment. deposit`, `auth. login`, `game. bet`).

2. Kafka + Flink, base e watermark; uma regra CEP para antifrode e outra para RG.

3. ClickHouse/Pinot para vitrines operacionais; dashboard lag/completeness.

4. Canal de incidente (webhook/Jira) e triage manual.

Fase 2 (4-8 semanas):
  • Fichestor online, mapeamento de modelos light; lookups asincrônicos (sanções/CUS).
  • Gerenciamento de regras como código, canários, regras A/B.
  • Regionalização e controlos PII, Legal Hold para malas.
Fase 3 (8-12 semanas):
  • Catálogo de sinais, geração automática de documentação, simulador «replay & what-if».
  • Liminares automáticos (Bayesian/quantile), métricas precisão/recall online.
  • Ensinamentos de DR., multi-region ativo-ativo, modelos de marceback por comandos.

17) Folha de cheque de qualidade antes de vender

  • Esquemas e contratos, validação em ingest.
  • As janelas, watermarks, allowed lateness + DLQ foram configuradas.
  • Deadup e idimpotentes sink 'i.
  • Métricas de lag/throughput/state size, alertas SLO.
  • Segurança: RBAC para regras/modelos, camuflagem PII.
  • Documentação: owner, SLO, exemplos, cartões de dependência.
  • Procedimentos rollback e botão freezer.

18) Erros frequentes e como evitá-los

Event-time: Use watermarks ou as métricas vão deslizar.
Sem dedução: os duplicados oferecerão alertas falsas → digite idempotency.
Chaves quentes - distorção de partituras → salting/resharding.
Janelas demasiado rígidas: perda de → tardias allowed lateness + corretivas de emissão.
Mistura PII: divida o torneamento e o fluxo analítico.
Sem simulador, teste as regras em «replay» antes de rodar.

19) Glossário (breve)

CEP - Complex Event Processing, detecção de pattern.
Watermark é um limite de tempo para a janela pronta.
Allowed Lateness - permissão de eventos atrasados.
O Stateful Operator é um operador resistente.
Função Store - Armazenamento de sinais on-line/offline para ML.

20) Total

Real-time processamento de sinais é uma linha de montagem controlada com esquemas claros, janelas e watermark 'ami, lógica stateful, enriquecimento online e SLO rigoroso. Seguindo essas práticas, você recebe detectores de risco rápidos e confiáveis, desencadeadores de personalização sustentáveis e dashboards operacionais que são escalados de forma econômica e completa.

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.