GH GambleHub

Análise Stream vs Batch

1) Essência curta

Stream - processamento contínuo de eventos em segundos: antifrod/AML, desencadeadores RG, alertas SLA, painéis operacionais.
Batch - Reexaminação periódica com reprodutividade total: relatórios regulatórios (GGR/NGR), finswercs, datasets ML.

Orientações: Stream p95 e2e 0. 5-5 c, Batch D + 1 até 06:00 (lock.) .

2) Matriz de seleção (TL; DR)

CritérioStreamBatch
Reações SLAsegundos/minutosrelógio/dia
Totalidade (completeness)alta, mas possível correção latemuito alta, controlada D + 1
Reprodutividade «as-of»mais difícil (replay)mais simples (time-travel/snapshots)
Custo por unidadecaminho mais caro onlinemais barato por volume
Tarefas típicasAML/RG alerts, SRE, real-time vitrinesrelatórios, acréscimos, ML off-line
Histórico (SCD)restritoTem muita gente
Regulador/WORMpor Gold-transbordadornativo (Gold/D + 1)

Regra 80/20: tudo o que não requer reação <5 minutos - em Batch; o resto é em Stream, com validação noturna Batch.

3) Arquiteturas

3. 1 Lambda

Stream para online + Batch para consolidação. Além disso, flexibilidade. Menos duas lógicas.

3. 2 Kappa

Tudo como fluxos; Batch = «réplicas» através do logo. Além disso, um único código. Menos: complexidade de réplicas/custo.

3. 3 Lakehouse-Hybrid (recomendado)

Stream → rotas OLAP operacionais (minutos) e Bronze/Silver; O Batch reencontra o Gold (D + 1) e publica relatórios.

4) Dados e hora

Stream

Janelas: tumbling/hopping/sessions.
Watermarks: 2-5 min; late data é marcado e alcançado.
Stateful: CEP, Dedup, TTL.

Batch

Encartes/CDC: 'updated _ at', reprodução de logs.
SCD I/II/III: histórico de atributos.
Camadas diurnas/mensais para «as-of».

5) Pattern de aplicação em iGaming

AML/Antifrod: Stream (velocity/estruturação) + Batch croquis e malas.
Executivos Gaming: Stream controle de limites/auto-exclusão; Registros de relatório batch.
Operações/SRE: Stream alert SLA; Batch pós-análise de incidentes e tendências.
Produto/marketing: Stream personalização/missão; Côrtes batch/LTV.
Finanças/relatórios: Batch (Gold D + 1, pacotes WORM), Stream - painéis operacionais.

6) DQ, reprodutividade, réplicas

Stream DQ: validação de circuitos, deadup '(event _ id, fonte)', janela completeness, late-ratio, dup-rate; uma → crítica do DLQ.
Batch DQ: Exclusividade/FK/range/temporal, confecção com OLTP/provedores; crítica → fail job + relatório.

Reprodutividade:
  • Stream: réplicas de topics por faixa + deterministic transformação.
  • Batch: time-travel/versões da lógica ('logic _ version') + snipshots Gold.

7) Privacidade e residência

Stream: pseudônimo, camuflagem online, linhas de montagem regionais (EEA/UK/BR), temporizações para PII-lookups externos.
Batch: isolamento de muppings PII, RLS/CLS, DSAR/PTBF, Legal Hold, arquivos WORM.

8) Costa-engenharia

Stream: evitar chaves «quentes» (salting), limitar async lookups, estado TTL, pré-regulação.
Batch: particionamento/clusterização, compactação de small files, materialização de unidades estáveis, quotas/janelas de lançamento.

9) Exemplos

9. 1 Stream - Flink SQL (10-min velocity depósitos)

sql
SELECT user_id,
TUMBLE_START(event_time, INTERVAL '10' MINUTE) AS win_start,
COUNT() AS deposits_10m,
SUM(amount_base) AS sum_10m
FROM stream. payments
GROUP BY user_id, TUMBLE(event_time, INTERVAL '10' MINUTE);

9. 2 Stream - CEP (pseudo-código AML)

python if count_deposits(10MIN) >= 3 and sum_deposits(10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window):
emit_alert("AML_STRUCTURING", user_id, snapshot())

9. 3 Batch - MERGE (implemento Silver)

sql
MERGE INTO silver. payments s
USING stage. delta_payments d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

9. 4 Batch — Gold GGR (D+1)

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) event_date,
b. market, g. provider_id,
SUM(b. stake_base) stakes_eur,
SUM(p. amount_base) payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) 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;

10) Métricas e SLO

Stream (orientações)

p95 ingest→alert ≤ 2–5 c completeness окна ≥ 99. 5%

schema-errors ≤ 0. 1%

late-ratio ≤ 1%

disponibilidade ≥ 99. 9%

Batch (orientações)

Gold. daily está pronto até às 06:00.

completeness ≥ 99. 5%

validity ≥ 99. 9%

Incidente MTTR DQ ≤ 24-48 h

11) Testes e lançamentos

Contratos/circuitos: consumer-driven tests; back-compat CI.
Stream: regras de canário, lançamento escuro, simulador replay.
Batch: dry-run em amostras, comparação entre métricas, somatório de controle (reconciação).

12) Anti-pattern

Duplicação de lógica: diferentes cálculos de Stream e Batch sem alinhamento de fórmulas.
API externa sincronizada no caminho quente Stream sem cachê/temporizador.
Full reload «por precaução» em vez de encartes.
Falta de watermarks/late-política.
PII em camadas analíticas; nenhum CLS/RLS.
Vitrines gold que «mutam» retroativamente.

13) Híbrido recomendado (playbook)

1. Caminho de stream: ingest → pneu → Flink/Beam (watermarks, deadup, CEP) →

OLAP (ClickHouse/Pinot) para painéis de 1-5-min + Bronze/Silver (append).
2. Contorno batch: encartes/CDC → Silver normalização/SCD → Gold vitrines/relatórios diários (WORM).
3. Alinhamento: camada semântica unificada de métricas; cruzamento de Stream↔Batch nightly; discrepâncias> limiar → tíquetes.

14) RACI

R (Resolvível): Streaming Plate (Stream-infra), Data Engineering (Batch Modelos), Domain Analytics (Métricas/Regras), MLOs (Fichas/Substância Store).
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.

15) Mapa de trânsito

MVP (2-4 semanas):

1. Kafka/Redpanda + 2 topics críticos ('payments', 'auth').

2. Flink-jobs: watermark + deadup + 1 regra CEP (AML ou RG).

3. Vitrine OLAP 1-5 min + dashboard lag/late/dup.

4. Lakehouse Silver (ACID), primeiro Gold. ggr _ daily (D + 1 antes das 06:00).

Fase 2 (4-8 semanas):
  • Implementos/CDC por domínio, SCD II, camada semântica de métricas.
  • Processamento de fluxo DQ e nightly Stream↔Batch.
  • Regionalização (EEA/UK/BR), DSAR/PHILBF, Legal Hold.
Fase 3 (8-12 semanas):
  • Simulador de réplica, canary/A-B lançamentos de regras/métricas.
  • Costa-dashboards e quotas; tiered storage; Ensinamentos Dr.
  • Geração automática de documentação de vitrines/métricas e lineage.

16) Folha de cheque de implementação

  • Esquemas/contratos na Registry; back-compat testes são verdes.
  • Stream: watermarks/allowed-lateness, дедуп, DLQ; Painéis OLAP em venda.
  • Batch: encartes/CDC, SCD II, Gold D + 1 com exportação WORM.
  • Camada semântica unificada de métricas; cruzamento nightly Stream↔Batch.
  • DQ-dashboards Freshness/Completeness/Validity; alert lag/late/dup.
  • RBAC/ABAC, criptografia, residência; DSAR/RTBF/Legal Hold.
  • O custo está sob controle (custo/GB, custo/query, state size, réplicas são quentes).

17) Resultado

Stream e Batch não são concorrentes, são duas engrenagens de um mesmo motor. Stream reage «aqui e agora», Batch - a verdade verificável «de manhã». A abordagem híbrida Lakehouse, uma única camada de métricas e disciplina DQ/lineage permitem a construção de circuitos analíticos rápidos, reproduzíveis e completos, perfeitos em SLA e custo.

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.