Análisis en tiempo real

1) Propósito y valor empresarial

• AML/Antifraude: estructuración de depósitos, ataques velocity, transacciones de riesgo.
• Juego responsable (RG): exceso de límites, patrones de riesgo, auto-exclusión.
• SRE/Operaciones: detección temprana de degradación de SLA, picos de error, sobrecalentamiento de clústeres.
• Producto y marketing: disparadores de personalización, misiones/misiones, segmentación real-time.
• Informes operativos: near-real-time GGR/NGR, dashboards de salas/proveedores.

Puntos de referencia de destino: p95 end-to-end 0. 5–5 с, completeness ≥ 99. 5%, disponibilidad ≥ 99. 9%.

2) Arquitectura de referencia

1. Ingest/Edge — `/events/batch` (HTTP/2/3), gRPC, OTel Collector; validación de circuitos, anti-toma, geo-enrutamiento.
2. El bus de eventos es Kafka/Redpanda (lote por 'user _ id/tenant/market', DLQ, retoque de 3-7 días).
3. Procesamiento de streaming - Flink/Spark Structured Streaming/Beam: operadores de stateful, CEP, watermarks, allowed lateness, dedoop.
4. Enriquecimiento en línea - Redis/Scylla/ClickHouse lookups (límites RG, KYC, BIN→MCC, IP→Geo/ASN), llamadas asíncronas con timeout y fallback.
5. Serving - ClickHouse/Pinot/Druid (escaparates operativos de 1-5 minutos), Feature Store (señales en línea), webhooks/ticketing/SOAR.
6. Lakehouse - Bronze/Silver/Gold para la consolidación a largo plazo, la reproducción y la soldadura.
7. La observabilidad es métricas de paipelines, treising (OTel), logs, lineage y cost-dashboards.

3) Señales y taxonomía

Pagos: 'pago. deposit/withdraw/chargeback`.
Juegos: 'game. bet/payout ', sesiones.
Autenticación y comportamiento: 'auth. login/failure`, device-switch, velocity.
Quirófanos: latency, error-rate, reinicio de pods, saturation.
Cumplimiento: cribado de sanciones, banderas RG, eventos DSAR.

Cada tipo tiene un propietario (domain owner), un esquema, un SLO de frescura y una política de datos late.

4) Ventanas, watermarks y datos late

Ventanas: tumbling (fix.) , hopping (superposición), session (por inactividad).
Watermark: la frontera del «conocimiento en el tiempo» (generalmente 2-5 min).
Eventos tardíos: preemisiones de ajustes, bandera 'late = true', DLQ cuando llega muy tarde.

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) Agregaciones CEP y stateful

Clave: 'user _ id', 'device _ id', 'payment. account_id`.
Estado: contadores deslizantes/sumas, filtros bloom para dedup, TTL.
Patrones CEP: structuring (<umbral, ≥N veces, más allá de la ventana T), device-switch, RG-fatigue.

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, orden e idempotencia

Entrega en bus + dedoup por 'event _ id' en procesamiento (TTL 24-72 h).
Orden: lote de llaves (orden local garantizado).
Sink: commits transaccionales (2-phase) o idempotent upsert/merge.
Outbox/Inbox: publicación transaccional de eventos de dominio desde OLTP.

7) Enriquecimiento en línea y Feature Store

Lookup: límites RG, estados KYC, BIN→MCC, IP→Geo/ASN, mercados/impuestos, FX en el momento del evento.
Desafíos asíncronos: API sancionadores/RR con timauts; si el error es 'unknown' + retray/caché.
Feature Store: negociación online/offline; una base de código de transformación.

8) Exhibiciones en tiempo real y serving

ClickHouse/Pinot/Druid: unidades de segundo/minuto, vistas materializadas, SLA por latencia de 1-5 min.
API/GraphQL: baja latencia para dashboards/widgets.
Alertas: webhooks/Jira/SOAR con un contexto enriquecido (trace_id, eventos last).

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 y dashboards

• p95 ingest→alert ≤ 2 s (reglas críticas), ≤ 5 c (otras).
• Completeness de la ventana T ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Disponibilidad del servicio de streaming ≥ 99. 9%; late-ratio ≤ 1%.

• Lag por lotes/topic; Tiempo de compra de los operadores; tamaño del estado.
• Embudo «sobytiye→pravilo→keys», precision/recall por dominios.
• Tarjeta térmica late/completeness; tarjeta de teclas «calientes».

10) Streaming DQ (calidad)

Validaciones de Ingest: schema/enums/size-limits, anti-toma.
En el hilo: completeness/dup-rate/late-ratio, corrección de ventanas (sin doble contabilización).
Políticas de reacción: critical → DLQ + pager; mayor/menor → teging + informe.

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) Privacidad, seguridad y residencia

Minimización PII: seudonimización de ID, enmascaramiento de campos sensibles, tokenización PAN/IBAN.
Residencia de datos: transportadores regionales (EEA/UK/BR), claves KMS individuales.
DSAR/RTBF: edición selectiva en escaparates downstream; Legal Hold para casos/informes.
Auditoría: registros de acceso/cambios de reglas inmutables, registro de lanzamientos.

12) Economía y productividad

Charding/keys: evita las llaves «hot» (salting/composite), el equilibrio de lotes.
Estado: TTL, snapshots compactos, tuning RocksDB/state backend.
Preagregaciones: reducir en las primeras etapas para temas ruidosos.
Sampling: sólo para métricas no críticas (no transacciones/cumplimiento).
Chargeback: presupuestos para temas/jobs, cuotas de réplicas y peticiones pesadas.

13) Procesos y RACI

R: Streaming Platform (infra/lanzamientos), Domain Analytics (reglas/fichas), MLOps (scoring/Feature Store).
A: Head of Data/Risk/Compliance por dominios.
C: DPO/Legal (PII/retention), SRE (SLO/incidentes), Arquitectura.
I: Producto, Soporte, Marketing, Finanzas.

14) Hoja de ruta para la aplicación

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

2. Flink-joba con watermark, dedoop y 1 regla CEP (AML o RG).

3. Escaparate en línea en ClickHouse/Pinot (1-5 min), dashboards lag/completeness.

4. Canal de incidentes (webhooks/Jira), SLO básicos y alertas.

• Enriquecimiento en línea (Redis/Scylla), Feature Store, lookups asíncronos.
• Control de reglas como código, canario/A-B, streaming DQ.
• Regionalización de transportadores, procedimientos DSAR/RTBF, Legal Hold para casos.

• Multi-región active-active, simulador «replay & what-if», calibración automática de umbrales.
• Escaparates de oro-stream (GGR/RG/AML), informes near-real-time.
• Costa-dashboards, chargeback, enseñanzas de DR.

15) Ejemplos (fragmentos)

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) Lista de verificación antes de la venta

• Esquemas/contratos en Registry, pruebas de back-compat verde.
• Se incluyen watermark/allowed lateness, dedoup y DLQ.
• SLO y alertas personalizadas (lag/late/dup/state size).
• Enriquecimiento con cachés y timautas; fallback «unknown».
• RBAC/dual-control en reglas/modelos; el registro de cambios está habilitado.
• Documentación de normas/escaparates; runbook 'y réplica/retroceso.

17) Errores frecuentes y cómo evitarlos

Ignora el momento del evento: sin watermarks, las métricas «flotan».
No hay dedo: alertas falsas, doble contabilidad.
Teclas calientes: distorsión de lotes → salting/resharding.
APIs externas sincrónicas en la ruta de acceso: sólo async + caché.
Costo no administrado: preagregaciones, estado TTL, cuotas, control de costos.
Falta de simulador: apagado sin «replay» → regresión.

18) Resultado

La analítica en tiempo real no es un «BI rápido», sino un circuito controlado con contratos, lógica estateful, CEP, watermarks, enriquecimiento en línea y estrictos SLO. Siguiendo estas prácticas, la plataforma recibe señales y soluciones precisas en segundos, manteniendo el cumplimiento, los escenarios de productos y la estabilidad operativa a un costo controlado.