Analista em tempo real

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

• AML/Antifrod: Estruturação de depósitos, ataques velocity, transações de risco.
• Resolvível Gaming (RG): excesso de limites, pattern de risco, auto-exclusão.
• SRE/Operações: Detecção precoce de degradações SLA, picos de erro, superaquecimento de clusters.
• Produto e marketing: desencadeadores de personalização, missões/buscas, real-time segmentação.
• Relatórios operacionais: near-real-time GGR/NGR, dashboards de salas/provedores.

Orientações de destino: p95 end-to-end 0. 5–5 с, completeness ≥ 99. 5%, disponibilidade ≥ 99. 9%.

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. O pneu de eventos é Kafka/Redpanda (particionização por 'user _ id/tenant/market', DLQ, retensh 3-7 dias).
3. Processamento de streaming - Flink/Spark Estrutured Streaming/Beam: operadoras de status, CEP, watermarks, allowed lateness, deadup.
4. Enriquecimento online - Redis/Scylla/ClickHouse lookups (limites RG, KYC, BIN→MCC, IP→Geo/ASN), chamadas asinhrônicas com temporizadores e fallback.
5. Serving - ClickHouse/Pinot/Druid (vitrines operacionais de 1 a 5 minutos), Função Store (sinais online), webhooks/tiketing/SOAR.
6. Lakehouse - Bronze/Silver/Gold para consolidação a longo prazo, replica e solda.
7. Observabilidade - métricas de pipline, trailing (OTel), logs, lineage e cus-dashboard.

3) Sinais e taxonomia

Pagamentos: 'payment. deposit/withdraw/chargeback`.
Jogos: 'game. bet/payout ', sessões.
Autenticação e comportamento: 'auth. login/failure`, device-switch, velocity.
Operacionais: latency, error-rate, reiniciar substrato, saturation.
Compilação de sanções, bandeiras RG, eventos DSAR.

Cada tipo tem dono (domain owner), esquema, SLO de frescura e política de late data.

4) Janelas, watermarks e late data

Janelas: tumbling (fix.) , hopping (sobreposição), sessão (inatividade).
Watermark: limite «conhecimento de tempo» (normalmente 2-5 min).
Eventos atrasados: pré-emissão de ajustes, bandeira 'late = true', DLQ em atraso forte.

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) CEP e agregação stateful

Chave: 'user _ id', 'device _ id', 'payment'. account_id`.
Estado: Contadores/somas deslizantes, filtros bloom para Dedup, TTL.
Pattern CEP: estruturing (<limiar, ≥N vezes, pela janela T), device-switch, RG-fatiguue.

python if cnt_deposits(last=10MIN) >= 3 and sum_deposits(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, snapshot())

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

At-least-once entrega em pneu + deadup por 'event _ id' em processamento (TTL 24-72 h).
Ordem: Particionamento de chave (ordem local garantida).
Sink: empresas transaccionais (2-phase) ou idempotent upsert/merge.
Outbox/Inbox: publicação transacional de eventos de domínio do OLTP.

7) Enriquecimento online e Função Store

Lookup: RG-limites, KYC-states, BIN→MCC, IP→Geo/ASN, mercados/impostos, FX no momento do evento.
Chamadas asinhrônicas: API de sanções/RER com temporizações; quando o erro é 'unknown' + retrai/dinheiro.
Função Store: concordância online/offline; uma base de transformações de código.

8) Vitrines real-time e serving

ClickHouse/Pinot/Druid: máquinas de segundos/minutos, materializações views, SLA para atraso de 1 a 5 minutos

API/GraphQL: Baixa latência para dashboards/widgets.
Alerts: webhooks/jira/SOAR com contexto enriquecido (trace _ id, last events).

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) Métricas, SLI/SLO e dashboards

• p95 ingest→alert ≤ 2 c (regras críticas), ≤ 5 c (outras).
• O Completeness janela T ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Disponibilidade do serviço estrim ≥ 99. 9%; late-ratio ≤ 1%.

• Liga de partições/topics; busy time operadoras; tamanho do estado.
• Vórtice «sobytiye→pravilo→keys», precisão/recall por domínio.
• Tela de calor late/completeness; cartão de chaves quentes.

10) Streaming DQ (qualidade)

Avaliações de Ingest: schema/enams/size-limits, anti-duplos.
Em fluxo: completeness/dup-rate/late-ratio, correção das janelas (sem duplicidade de contagem).
Políticas de reação: critical → DLQ + pager; major/menor → formatação + relatório.

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

11) Privacidade, segurança e residência

Minimização PII: identificação de ID, camuflagem de campos sensíveis, tocenização PAN/IBAN.
Data residency: linhas de montagem regionais (EEA/UK/BR), chaves KMS separadas.
DSAR/PTBF: edições seletivas nas vitrines de downstream; Legal Hold para malas/relatórios.
Auditoria: logs de acessibilidade/alteração de regras imutáveis, registro de lançamentos.

12) Economia e produtividade

Charding/chaves: evite chaves quentes (salting/composite), equilíbrio de partituras.
Estado: TTL, compact snapshots, sintonização RocksDB/state backend.
Pré-regulação: Reduce nos primeiros estágios para temas ruidosos.
Sampling: apenas para métricas não ríticas (transações/complicações).
Chargeback: orçamentos para tópicos/jobs, quotas de réplicas e pedidos pesados.

13) Processos e RACI

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

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

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

2. Flink-jobs com watermark, dedução e 1 regra CEP (AML ou RG).

3. Vitrine operacional em ClickHouse/Pinot (1-5 min), dashboard lag/completeness.

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

• Enriquecimento online (Redis/Scylla), Função Store, lookups asincrônicos.
• Gerenciamento de regras como código, canary/A-B, streaming DQ.
• Regionalização das linhas de montagem, DSAR/PHILBF procedimentos, Legal Hold para as malas.

• Multi-região ativa, simulador «replay & what-if», calibração automática de liminares.
• Vitrines gold stream (GGR/RG/AML), relatórios near-real-time.
• Costa-dashboards, chargeback, ensinamentos Dr.

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

16) Folha de cheque antes de vender

• Os circuitos/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; o registro de alterações está ativado.
• Documentação de regras/vitrines; runbook 'e réplica/retração.

17) Erros frequentes e como evitá-los

Event-time: sem watermarks, as métricas «nadam».
Não há dedups, alertas falsos, registos duplos.
Chaves quentes - distorção de partituras → salting/resharding.
API externa sincronizada no caminho quente: apenas async + dinheiro.
Valor fora de controle: pré-regulação, estado TTL, quotas, monitoramento de custo.
Falta de simulador: escoamento sem «replay» → regressão.

18) Total

Um analista em tempo real não é um «BI rápido», mas um circuito controlado com contratos, uma lógica estateful, CEP, watermarks, enriquecimento online e SLO rigoroso. Seguindo essas práticas, a plataforma recebe sinais precisos e soluções em segundos, suportando a complacência, cenários de alimentos e estabilidade operacional a um custo controlado.