Procesamiento de señales en tiempo real
1) Propósito y valor empresarial
El flujo de tiempo real es necesario para responder «aquí y ahora»:- Antifraude/AML: estructuración de depósitos, «mulación», ataques velocity.
- Juego responsable (RG): exceso de límites, patrones de comportamiento de riesgo.
- Riesgo/Cumplimiento: detección de sanciones en el registro/transacción en línea.
- Personalización: disparadores de bonos/misiones, campañas reactivas.
- Operaciones/SRE: degradación de SLA, balanzas de errores, anomalías métricas.
Objetivos clave: baja latencia (p95 0. 5-5 s), alta plenitud (≥99. 5%), resistencia a las ráfagas.
2) Taxonomía de señales
Transaccional: 'payment. deposit/withdraw/chargeback`.
Juegos: 'game. bet/payout`, `game. session_start/stop`.
Autenticación: 'auth. login/failure ', cambio de dispositivos/geo.
Conductual: tasa de apuestas, crecimiento exponencial de la suma, actividad nocturna.
Quirófanos: 'api. latency`, `error. rate ', «tormenta» de relanzamientos de podas.
Cada tipo tiene un esquema, propietario (domain owner), criticidad, SLO y reglas «late data».
3) Arquitectura de referencia de contorno de tiempo real
1. Ingest y bus: HTTP/gRPC → Edge → Kafka/Redpanda (lote por 'user _ id/tenant').
2. Streaming-движок: Flink/Spark Structured Streaming/Beam; operadores stateful, CEP.
3. Enriquecimiento en línea: tablas de búsqueda (Redis/Scylla/ClickHouse Read-Only), proveedores de caché (sanciones/CUS).
- Alert topics/kew (gestión de casos, SOAR).
- Fichastor en línea (puntuación de modelos).
- Vitrinas de streaming de oro (dashboards operativos).
- Almacenamiento «cálido» para análisis rápido (ClickHouse/Pinot/Druid).
- 5. Archivo/forensic: plegado inmutable en Lake (Parquet, time-travel).
- 6. Observabilidad: treysing/métricas/logs + lineage.
4) Ventanas, watermarks y «data late»
Vistas de ventanas:- Tumbling: ventanas fijas (por ejemplo, 1 min) - unidades simples.
- Hopping: superposición (por ejemplo, paso 30 s, ventana 2 min) - métricas «lisas».
- Sesión: brechas de inactividad - análisis de comportamiento.
- Watermarks: la frontera del «conocimiento del tiempo» para el event-time; permitimos la tardanza (allowed lateness, por ejemplo, 2 min).
- Estrategias tardías: domicilio de ajustes, llegada «late = true», DLQ.
5) Operadores Stateful y deduplicación
Clave: por 'user _ id', 'pago. account_id`, `device_id`.
Estado: sumadores, contadores deslizantes, filtros bloom para idempotency.
Dedoup: almacenamiento '(event_id, seen_at)' en state/kv; TTL = 24-72 h.
Exactly-Once: transacciones sink 'i (2-phase), operaciones de upsert idempotente.
6) Enriquecimiento de flujo
Lookup-joynes: límites RG, riesgo-score del usuario, nivel KYC, geo/ASN.
Llamadas asíncronas: registro de sanciones/proveedores antifraude (async I/O, taimaouts y fallback).
Normalización de monedas/temporizador: unificación a UTC y moneda base; fijar 'fx _ source'.
7) CEP: detección de patrones complejos
Ejemplos de reglas:- Estructura: ≥3 de depósito por 10 min, cada
X. - Dispositivo-switch: 3 dispositivos diferentes por 15 min + cambio IP/ASN.
- RG-fatigue: apuestas totales en 1 hora> límites + pérdida ≥ Y.
- Ops-storm: p95 latency> 2 × base, 5xx> 3% en una ventana de 5 min.
Es conveniente expresar CEP en Flink CEP/SQL o bibliotecas de plantillas de eventos.
8) Fichas y modelos en línea
Pipelines de características: contadores, métricas de velocidad, «hora del último evento», share-of-wallet.
Coherencia en línea/fuera de línea: una base de códigos de transformación; pruebas de retransmisión.
Puntuación: modelos light (logit/GBDT) sincronizados; pesado - asíncrono a través de la cola.
Control de deriva: PSI/KS y alertas; «lanzamientos oscuros» para nuevos modelos.
9) Garantías de envío y orden
At-least-once en bus + idempotencia en la recepción.
El envío por clave proporciona un orden local.
Retries & backpressure: retraídas exponenciales con jitter, control de presión automático.
10) SLO/SLI (recomendado)
11) Observabilidad del contorno en tiempo real
Métricas de paipline: throughput, lag per partition, busy time, checkpoint duration.
Calidad de las señales: completeness, duplication rate, late ratio.
Dashboards: mapa térmico de lags por topic, alert-embudo (sobytiye→pravilo→keys), mapa de llaves calientes.
Treking: asociar una alerta a los eventos originales (trace_id).
12) Seguridad y privacidad
PII-minimización: tokenización de identificadores, enmascaramiento de campos sensibles.
Geo-residencia: transportadores regionales (EEA/UK/BR).
Auditoría: registros de soluciones inmutables (quién, qué, por qué), Legal Hold para casos.
Acceso: RBAC a las reglas/modelos, control dual a los apagados.
13) Costo y rendimiento
Teclas calientes: redistribución (key salting), llaves compuestas.
Condición: TTL razonable, materialización incremental, afinación RocksDB.
Ventanas: dimensiones óptimas y lateness allowed; capas de preaggregación para flujos «ruidosos».
Sampling: en flujos no críticos y a nivel métrico (no en transacciones/cumplimiento).
14) Ejemplos (simplificado)
Flink SQL - structuring depósitos (10-min ventana, paso 1 min):sql
CREATE VIEW deposits AS
SELECT user_id, amount, ts
FROM kafka_deposits
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY ts
MEASURES
FIRST(A. ts) AS start_ts,
SUM(A. amount) AS total_amt,
COUNT() AS cnt
ONE ROW PER MATCH
AFTER MATCH SKIP PAST LAST ROW
PATTERN (A{3,})
WITHIN INTERVAL '10' MINUTE
) MR
WHERE total_amt > 500 AND cnt >= 3;
Pseudocódigo anti-velocity por apuestas:
python key = event. user_id window = sliding(minutes=5, step=30) # hopping window count = state. counter(key, window)
sum_amt = state. sum(key, window)
if count > 30 or sum_amt > THRESH:
emit_alert("RG_VELOCITY", key, snapshot(state))
Dedoup por event_id (Kafka Streams):
java if (!kvStore.putIfAbsent(event. getId(), now())) {
forward(event); // unseen -> process
}
15) Procesos y RACI
R (Responsable): Streaming Platform (infra, estado, lanzamientos), Domain Analytics (reglas/fichas).
A (Accountable): Head of Data/Risk/Compliance según sus dominios.
C (Consultado): DPO/Legal (PII/Retention), SRE (SLO/Incidentes), Arquitectura.
I (Informed): Producto/Soporte/Marketing.
16) Hoja de ruta para la implementación
MVP (2-4 semanas):1. 2-3 señales críticas (por ejemplo, 'pago. deposit`, `auth. login`, `game. bet`).
2. Kafka + Flink, el dedoop básico y watermark; una regla CEP para el antifraude y otra para el RG.
3. ClickHouse/Pinot para escaparates operativos; dashboards lag/completeness.
4. Canal de incidentes (webhook/Jira) y triage manual.
Fase 2 (4-8 semanas):- Fichastor en línea, modelos light scoring; lookups asíncronos (sanciones/CCA).
- La gestión de las reglas como código, canario, reglamento A/B.
- Regionalización y controles PII, Legal Hold para casos.
- Catálogo de señales, autogeneración de documentación, simulador «replay & what-if».
- Calibración automática de umbrales (Bayesian/quantile), métricas de precisión/recall en línea.
- Ejercicios de DR, multi-región active-active, modelos de chargeback por equipos.
17) Check-list de calidad antes de la venta
- Esquemas y contratos, validación en ingest.
- Ventanas personalizadas, watermarks, lateness allowed + DLQ.
- Dedoop y sink 'i idempotentes.
- Métricas lag/throughput/state size, alertas SLO.
- Seguridad: RBAC en reglas/modelos, enmascaramiento PII.
- Documentación: owner, SLO, ejemplos, mapas de dependencia.
- Procedimientos de rollback y botón friso.
18) Errores frecuentes y cómo evitarlos
Ignorar el evento-tiempo: use watermarks, de lo contrario «deslizará» métricas.
No hay dedup: los duplicados darán alertas falsas → escriba idempotency.
Teclas calientes: distorsión de lotes → salting/resharding.
Ventanas demasiado rígidas: pérdida de retrasos → lateness allowed + emisiones correctivas.
Mezcla PII: separe la tokenización y el flujo analítico.
No hay simulador: pruebe las reglas en la «réplica» antes de rodar.
19) Glosario (breve)
CEP - Procesamiento de eventos complex, detección de patrones.
Watermark es el umbral de tiempo para que la ventana esté lista.
Allowed Lateness - Admisión de eventos atrasados.
Stateful Operator es un operador con un estado persistente.
Feature Store - Almacenamiento de señales en línea/fuera de línea para ML.
20) Resultado
El procesamiento de señales en tiempo real es un transportador controlado con circuitos claros, ventanas y watermark 'ami, lógica stateful, enriquecimiento en línea y estrictos SLO. Siguiendo estas prácticas, obtiene detectores de riesgos rápidos y confiables, disparadores de personalización sostenibles y dashboards operativos que se escalan de manera rentable y satisfactoria.