Streaming y análisis de streaming

1) Propósito y valor

• Antifraude/AML: identificación de la estructuración de depósitos, ataques velocity, anomalías de proveedores.
• Juego responsable (RG): superación de límites, patrones de riesgo, autoexclusiones.
• Operaciones/ERE: degradación de SLA, picos de errores, señales tempranas de incidentes.
• Producto/marketing: eventos de personalización, misiones/misiones, segmentación real-time.
• Reporting near-real-time: vitrinas GGR/NGR, paneles operativos.

Características objetivo: p95 end-to-end 0. 5-5 s, plenitud ≥ 99. 5%, costo manejable.

2) Arquitectura de referencia

1. Ingest/Edge

`/events/batch` (HTTP/2/3), gRPC, OTel Collector.
Validación de esquemas, anti-duplicados, geo-enrutamiento.

2. Bus de eventos

Kafka/Redpanda (lote por 'user _ id/tenant/market').
Retention 3-7 días, compresión, DLQ/« cuarentena »para mensajes« rotos ».

3. Procesamiento de secuencias

Flink / Spark Structured Streaming / Beam.
Operadores de estado, CEP, watermark, lateness allowed, deduplicación.
Enriquecimiento (Redis/Scylla/ClickHouse-Lookup), asíncrono I/O con temporizadores.

4. Serving/escaparates operativos

ClickHouse/Pinot/Druid para agregación de minutos/segundos y dashboards.
Feature Store (online) para capturar modelos.
Alert topics → SOAR/ticketing/webhooks.

5. Almacenamiento a largo plazo (Lakehouse)

Bronze (raw), Silver (clean), Gold (serve) — Parquet + Delta/Iceberg/Hudi.
Replay/Backtest, time-travel.

6. Observabilidad

Métricas de paipelines, treysing (OTel), logs, lineage.

3) Esquemas y contratos

Schema-first: JSON/Avro/Protobuf + Registry, 'schema _ version' en cada evento.
Evolución: back-compatible - nuevos campos nullables; breaking - '/v2 '+ publicación doble.
Campos obligatorios: 'event _ time' (UTC), 'event _ id', 'trace _ id', 'user. pseudo_id`, `market`, `source`.

4) Ventanas, watermarks y datos atrasados

• Tumbling (fijo), Hopping (con superposición), Session (por inactividad).
• Watermark: umbral de «conocimiento» por event-time; por ejemplo, 2-5 minutos.
• Data tardía: Domaemisión de ajustes, «late = true», DLQ con un fuerte retraso.

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 Stateful y CEP

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

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

Bus: en-least-once + llaves de lote proporcionan un orden local.
Idempotencia: 'event _ id' + dedup state (TTL 24-72 h).
Sink: commits transaccionales (2-phase) o upsert/merge-idempotent.
Outbox/Inbox: publicación garantizada de eventos de dominio desde OLTP.

7) Enriquecimiento en tiempo real

Lookup: Redis/Scylla (límites RG, estado KYC, BIN→MCC, IP→Geo/ASN).
Desafíos asíncronos: API sancionadores/RER con taimauts y fallback («sin conexión»).
FX/temporizador: normalización de sumas y tiempo de mercado local ('fx _ source', 'tz').

8) Vitrinas serving y real-time

ClickHouse/Pinot/Druid: agregaciones por minutos/segundos, vistas materializadas.
Gold-stream: tablas operativas GGR/RG/AML, SLA por retraso ≤ 1-5 min.
API/GraphQL: baja latencia para dashboards e integraciones 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) Observabilidad y SLO

• p95 ingest→alert ≤ 2 s (crítico), ≤ 5 s (resto).
• Completeness de la ventana T ≥ 99. 5%.
• Errores de esquema ≤ 0. 1%; la proporción de eventos con 'trace _ id' ≥ 98%.
• Disponibilidad del servicio de streaming ≥ 99. 9%.

• Lags por lotes/topics, tiempo de compra de los operadores, tamaño del estado.
• Embudo «sobytiye→pravilo→keys», tarjeta de llaves «calientes», late-ratio.
• Costo: costo/GB, costo/query, valor de las facturas/réplicas.

10) Privacidad y cumplimiento

Minimización PII: seudonimización de ID, enmascaramiento de campos, tokenización PAN/IBAN.
Residencia de datos: transportadores regionales (EEA/UK/BR), claves de cifrado individuales.
Operaciones legales: DSAR/RTBF en escaparates downstream, Legal Hold para casos/informes.
Auditoría: registros de acceso, archivos de soluciones inmutables.

11) Economía y productividad

Llaves y charding: evita las llaves «calientes» (salting/composite key).
Condición: TTL razonable, snapshots, tuning RocksDB/backend state.
Preagrupación: reducción de arriba al frente para flujos ruidosos.
Sampling: permitir en métricas no críticas (no en transacciones/cumplimiento).
Chargeback: presupuestos para temas/jobs, cuotas y alocación por equipos.

12) Streaming DQ (calidad)

Validación de Ingest (schema, enums, size), dedoop '(event_id, source)'.
En el hilo: completeness/dup-rate/late-ratio, control de ventanas (no hay doble contabilidad).
Políticas de reacción: crítica → DLQ + alerta; mayor/menor → etiqueta y posterior limpieza.

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) Seguridad de acceso y control de release

RBAC/ABAC: roles separados para leer hilos, cambiar reglas/modelos.
Control dual: apilando reglas y modelos a través de «2 claves».
Canary/A/B: ejecución oscura de reglas y modelos, control de precisión/recall.
Secretos: KMS/CMK, rotación regular, prohibición de secretos en las guaridas.

14) Procesos y RACI

R (Responsable): Streaming Platform (infra/lanzamientos), Domain Analytics (reglas/fichas), MLOps (puntuación).
A (Accountable): Head of Data/Risk/Compliance por dominios.
C (Consultado): DPO/Legal (PII/Retention), SRE (SLO/Incidentes), Arquitectura.
I (Informed): Producto, Soporte, Marketing, Finanzas.

15) Hoja de ruta para la implementación

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

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

3. ClickHouse/Pinot escaparate 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.
• Gestión de la normativa como código, lanzamientos canarios, A/B.
• DQ streaming, regionalización de transportadores, procedimientos DSAR/RTBF.

• Multi-región active-active, replay-simulador «what-if», calibración automática de los umbrales.
• Escaparates de oro completo (GGR/RG/AML), reporting near-real-time.
• Dashboards de valor, chargeback, ejercicios de DR.

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

17) Lista de verificación antes de la venta

• Esquemas y 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, todos los cambios son lógicos.
• Documentación de reglas, escaparates y runbook 'y réplica/retroceso.

18) Errores frecuentes y cómo evitarlos

Ignora el momento del evento: sin watermarks, las métricas «flotan».
No hay dedo: alertas falsas y 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, dashboards de costo.
Falta de simulador: los apagados sin «replay» conducen a regresiones.

19) Glosario (breve)

CEP - Complex Event Processing (patrones de eventos).
Watermark es el límite de preparación de ventanas por tiempo de evento.
Allowed Lateness - Admisión de eventos tardíos.
Stateful Operator es un operador con un estado guardado.
Feature Store (Tienda de características) es un serving coherente de características (online/offline).

20) Resultado

Streaming y streaming analytics es un sistema gestionado: contratos, ventanas y watermarks, stateful-logics y CEP, escaparates de enriquecimiento y tiempo real, SLO y observabilidad, privacidad y valor bajo control. Siguiendo las prácticas descritas, la plataforma obtiene detectores de riesgo confiables, paneles operativos y personalización con latencia y costos predecibles.