Streaming e análise de streaming

1) Destino e valor

• Antifrod/AML: detecção da estruturação de depósitos, ataques velocity, anomalias dos provedores.
• Resolvível Gaming (RG): excesso de limites, risco-pattern, auto-exclusão.
• Operações/SRE: degradação da SLA, aparições de erros, sinais iniciais de incidentes.
• Produto/marketing: eventos de personalização, missões/buscas, real-time segmentação.
• Relatórios near-real-time: vitrines GGR/NGR, painéis operacionais.

Características de destino: p95 end-to-end 0. 5-5 c, total ≥ 99. 5%, valor controlado.

2) Arquitetura de referência

1. Ingest/Edge

`/events/batch` (HTTP/2/3), gRPC, OTel Collector.
Validação de esquemas, anti-duplicação, geo-rotação.

2. Pneu de evento

Kafka/Redpanda (particionamento por 'user _ id/tenant/market').
Retenção 3-7 dias, compressão, DLQ/« quarentena »para mensagens« batidas ».

3. Streaming

Flink / Spark Structured Streaming / Beam.
Operadoras stateful, CEP, watermark, allowed lateness, dedução.
Enriquecimento (Redis/Scylla/ClickHouse-Lookup), asincrona I/O com temporizadores.

4. Cerving/Vitrines operacionais

ClickHouse/Pinot/Druid para agregação de minutos/segundos e dashboards.
A função Store (online) é um modelo de mapeamento.
Alert topics → SOAR/tiketing/webhooks.

5. Armazenamento a longo prazo (Lakehouse)

Bronze (raw), Silver (clean), Gold (serve) — Parquet + Delta/Iceberg/Hudi.
Réplicas/Batestes, time-travel.

6. Observabilidade

Métricas de pipinas, trailing (OTel), logs, lineage.

3) Esquemas e contratos

Schema-first: JSON/Avro/Protobuf + Registry, 'schema _ versão' em cada evento.
Evolução: back-compatível - novos campos nullable; breaking - '/v2 '+ publicação dupla.
Os campos obrigatórios são 'event _ time' (UTC), 'event _ id', 'trace _ id', 'user. pseudo_id`, `market`, `source`.

4) Janelas, watermarks e dados tardios

• Tumbling (fixo), Hopping (sobreposto), Sessão (inatividade).
• Watermark: limiar «conhecimento» por event-time; Por exemplo, 2-5 minutos.
• Late data: pré-emissão de ajuste, «late = true», DLQ em atraso.

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);

5) Agregações estateful e CEP

Chave: 'user _ id', 'device _ id', 'payment'. account_id`.
Estado: somas/contadores deslizantes, sessões, filtros bloom para dedução.
Pattern CEP: Estruturação (<limiar, ≥N vezes, janela T), device-switch, RG-fatiguue.

python if deposits.count(last=10MIN) >= 3 and deposits.sum(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, window_snapshot())

6) Exactly-Once, ordem e idempotação

O pneu: at-least-once + chaves de partilha fornecem ordem local.
Idempotidade: 'event _ id' + deadup-state (TTL 24-72 h).
Sink: Comitivas transaccionais (2-phase) ou upsert/merge-idempotação.
Outbox/Inbox: publicação garantida de eventos de domínio do OLTP.

7) Enriquecimento em tempo real

Lookup: Redis/Scylla (limites RG, status KYC, BIN→MCC, IP→Geo/ASN).
Chamadas asinhrônicas: API de sanção/REER com temporizadores e fallback («unknown»).
FX/temporzon: normalização de quantias e hora local do mercado ('fx _ fonte', 'tz').

8) Cerving e vitrine real-time

ClickHouse/Pinot/Druid: agregações por minutos/segundos, materializações views.
Gold stream: tabelas operacionais GGR/RG/AML, SLA para atraso ≤ 1-5 min.
API/GraphQL: baixa latência para dashboards e integrações externas.

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;

9) Observabilidade e SLO

• p95 ingest→alert ≤ 2 c (crítico), ≤ 5 c (resto).
• O Completeness janela T ≥ 99. 5%.
• Erros de padrão ≤ 0. 1%; O percentual de eventos com 'trace _ id' ≥ 98%.
• Disponibilidade do serviço estrim ≥ 99. 9%.

• Lances por partições/topics, operadoras de busy time, tamanho do estado.
• Vórtice «sobytiye→pravilo→keys», cartão de chaves quentes, late-ratio.
• Custo: custo/GB, custo/query, valor de checkpoint/réplicas.

10) Privacidade e complacência

Minimização PII: Identificação de ID, camuflagem de campos, toquenização PAN/IBAN.
Dados residenciais: linhas de montagem regionais (EEA/UK/BR), chaves de encriptação separadas.
Transações legais: DSAR/PTBF nas vitrines de downstream, Legal Hold para malas/relatórios.
Auditoria: logs de acesso, arquivos de solução imutáveis.

11) Economia e produtividade

Chaves e charding: evite chaves quentes (salting/composite key).
Estado: TTL razoável, snapshots, sintonização RocksDB/Backend state.
Pré-regulação: up-front reuse para os fluxos ruidosos.
Sampling: permitido em métricas não-ríticas (não em transações/compliance).
Chargeback: orçamentos para temas/jobs, quotas e alocação por comandos.

12) Streaming DQ (qualidade)

Validação de Insest (schema, enumes, size), deadup '(event _ id, fonte)'.
Em fluxo: completeness/dup-rate/late-ratio, controle de janelas (sem dupla contabilidade).
Políticas de reação: critical → DLQ + alert; major/menor → a marca e a limpeza subsequente.

yaml stream: payments rules:
- name: schema_valid type: schema severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: dedup_window type: unique keys: [event_id]
window_minutes: 1440

13) Segurança de acesso e controle release

RBAC/ABAC: papéis individuais para leitura de fluxo, alteração de regras/modelos.
Controle dual: Descarte regras e modelos através de «2 chaves».
Canary/A/B: lançamentos escuros de regras e modelos, controle de precisão/recall.
Segredos: KMS/CMK, rotação regular, proibição de segredos em logs.

14) Processos e RACI

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

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

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

2. Flink-jobs com watermark, dedup e uma regra CEP (AML ou RG).

3. ClickHouse/Pinot vitrine de 1-5 min, dashbords lag/completeness.

4. Canal de incidente (webhooks/jira), SLO básico e alertas.

• Enriquecimento online (Redis/Scylla), Função Store, lookups asinhrônicos.
• Gerenciamento de regras como código, lançamentos canários, A/B.
• Streaming DQ, regionalização das linhas de montagem, DSAR/PCBF procedimentos.

• Multi-região ativo-ativo, simulador de replay «what-if», controle automático de liminares.
• Vitrines Gold stream completas (GGR/RG/AML), relatórios near-real-time.
• Dashboards de valor, chargeback, ensinamentos de Dr.

16) Exemplos (fatias)

sql
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY event_time
MEASURES
FIRST(A.device_id) AS d1,
LAST(B.device_id) AS d2,
COUNT() AS cnt
PATTERN (A B+)
DEFINE
B AS B.device_id <> PREV(device_id) AND B.ip_asn <> PREV(ip_asn)
) MR

java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}

17) Folha de cheque antes de vender

• Circuitos e contratos em Registry, back-compat testes são verdes.
• Estão incluídos watermark/allowed lateness, dedup e DLQ.
• Configurados SLO e alertas (lag/late/dup/state size).
• Enriquecimento com caixas e temporizadores, fallback «unknown».
• RBAC/dual-controle para regras/modelos, todas as alterações são logadas.
• Documentação de regras, vitrines e runbook 'e réplica/reversão.

18) Erros frequentes e como evitá-los

Event-time: Sem watermarks, as métricas «nadam».
Não há dedups, alertas falsos e registos duplos.
Chaves quentes - distorção de partituras → salting/resharding.
API externa sincronizada no caminho quente: apenas async + dinheiro.
Valor descontrolado: Pré-regulação, TTL de fortuna, quotas, coque-dashboard.
Falta de simulador: saques sem «replay» causam regressão.

19) Glossário (breve)

CEP - Complex Event Processing (Pattern de Eventos).
Watermark é o limite de preparação das janelas por event-time.
Allowed Lateness - tolerância de eventos atrasados.
O Stateful Operator é um operador com estado de conservação.
Função Store - Sinais de servinga alinhados (online/offline).

20) Total

O streaming e o streaming são um sistema administrado, como contratos, janelas e watermarks, lógica estateful e CEP, enriquecimento e real-time vitrines, SLO e observabilidade, privacidade e custo sob controle. Seguindo as práticas descritas, a plataforma recebe detectores de risco confiáveis, painéis operacionais e personalização com latência e custos previsíveis.