Análisis Stream vs Batch

1) Breve esencia

Stream - procesamiento continuo de eventos en segundos: antifraude/AML, RG-desencadenantes, alertas SLA, paneles operativos.
Batch - Revalorización periódica con reproducibilidad completa: informes regulatorios (GGR/NGR), máquinas de fondos, datacets ML.

Puntos de referencia: Stream p95 e2e 0. 5-5 s, Batch D + 1 a 06:00 (lok.) .

2) Matriz de selección (TL; DR)

Regla 80/20: cualquier cosa que no requiera una reacción <5 minutos - en Batch; el resto está en Stream, con la validación nocturna de Batch.

3) Arquitecturas

3. 1 Lambda

Stream para la consolidación en línea + Batch. Además: flexibilidad. Menos: dos lógicas.

3. 2 Kappa

Todo como flujos; Batch = «réplica» a través del registro. Además: un solo código. Menos: dificultad de réplicas/costo.

3. 3 Lakehouse-Hybrid (recomendado)

Stream → OLAP-marts operativos (minutos) y Bronze/Silver; Batch recalcula Oro (D + 1) y publica informes.

4) Datos y tiempo

Stream

Ventanas: tumbling/hopping/session.
Watermarks: 2-5 minutos; late data se marca y se emite.
Stateful: CEP, dedoop, TTL.

Batch

Incrementos/CDC: 'updated _ at', replicación de registro.
SCD I/II/III: historia de los atributos.
Snapshots: capas diurnas/mensuales para «as-of».

5) Patrones de aplicación en iGaming

AML/Antifraude: Stream (velocity/estructuración) + Batch conciliaciones y casos.
Juego responsable: Control Stream de límites/autoexclusiones; Registros de informes de Batch.
Operaciones/SRE: alertas Stream SLA; Batch post-análisis de incidentes y tendencias.
Producto/marketing: Stream personalización/misión; Cohortes de batalla/LTV.
Finanzas/informes: Batch (Oro D + 1, paquetes WORM), Stream - paneles en línea.

6) DQ, reproducibilidad, repetición

Stream DQ: validación de esquemas, dedup '(event_id, source)', completeness de ventana, late-ratio, dup-rate; → DLQ crítico.
Batch DQ: singularidad/FK/range/temporal, conciliaciones con OLTP/proveedores; → crítico fail job + informe.

• Stream: una réplica de topics en el rango de transformación + deterministic.
• Batch: time-travel/logic version ('logic _ version') + snapshots Gold.

7) Privacidad y residencia

Stream: pseudonimización, enmascaramiento en línea, transportadores regionales (EEA/UK/BR), temporizadores en lookups PII externos.
Batch: aislamiento de mappings PII, RLS/CLS, DSAR/RTBF, Legal Hold, archivos WORM.

8) Costh-engineering

Stream: evitar las claves «hot» (salting), restringir async lookups, estado TTL, preagregación.
Batch: partición/agrupamiento, compilación de archivos pequeños, materialización de agregados estables, cuotas/ventanas de inicio.

9) Ejemplos

9. 1 Stream - Flink SQL (10-min de depósitos velocity)

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

9. 2 Stream - CEP (pseudocódigo AML)

python if count_deposits(10MIN) >= 3 and sum_deposits(10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window):
emit_alert("AML_STRUCTURING", user_id, snapshot())

9. 3 Batch - MERGE (incremento de plata)

sql
MERGE INTO silver. payments s
USING stage. delta_payments d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

9. 4 Batch — Gold GGR (D+1)

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) event_date,
b. market, g. provider_id,
SUM(b. stake_base) stakes_eur,
SUM(p. amount_base) payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

10) Métricas y SLO

Stream (puntos de referencia)

p95 ingest→alert ≤ 2–5 c completeness окна ≥ 99. 5%

schema-errors ≤ 0. 1%

late-ratio ≤ 1%

disponibilidad ≥ 99. 9%

Batch (puntos de referencia)

Gold. daily listo hasta las 06:00 lock.

completeness ≥ 99. 5%

validity ≥ 99. 9%

MTTR DQ-incidente ≤ 24-48 h

11) Pruebas y lanzamientos

Contratos/esquemas: pruebas de consumo; back-compat CI.
Stream: reglas canarias, lanzamiento oscuro, replay-simulador.
Batch: dry-run en muestreos, comparación de métricas, resumen de control (reconciliation).

12) Anti-patrones

Lógica duplicada: diferentes cálculos de Stream y Batch sin alinear fórmulas.
APIs externas sincrónicas en la ruta de acceso de Stream sin caché/temporizadores.
Reload completo «por si acaso» en lugar de incrementos.
Ausencia de políticas watermarks/late.
PII en capas analíticas; sin CLS/RLS.
Vitrinas de oro que «mutan» retroactivamente.

13) Híbrido recomendado (playbook)

1. Circuito Stream: ingest → bus → Flink/Beam (watermarks, dedoop, CEP) →

OLAP (ClickHouse/Pinot) para paneles de 1-5 min + Bronze/Silver (append).
2. Circuito de batalla: aumentos/CDC → Silver normalización/SCD → Gold Diary Showcases/Reports (WORM).
3. Armonización: una sola capa semántica de métricas; nightly Stream↔Batch de conciliación; discrepancias> umbrales → tickets.

14) RACI

R (Responsable): Streaming Platform (Stream-infra), Data Engineering (Batch Model), Domain Analytics (métricas/reglas), MLOps (Feature Store).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/Legal/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed): BI/Producto/Marketing/Operaciones.

15) Hoja de ruta

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

2. Flink-joba: watermark + dedup + 1 regla CEP (AML o RG).

3. Escaparate OLAP 1-5 min + dashboards lag/late/dup.

4. Lakehouse Silver (ACID), el primer Oro. ggr_daily (D + 1 hasta las 06:00).

• Incrementos/CDC por dominio, SCD II, capa semántica de métricas.
• Streaming DQ y nightly Stream↔Batch de conciliación.
• Regionalización (EEA/UK/BR), DSAR/RTBF, Legal Hold.

• Simulador de réplica, lanzamientos canarios/A-B de reglas/métricas.
• Costas-dashboards y cuotas; tiered storage; Enseñanzas de DR.
• Autogeneración de documentación de escaparates/métricas y lineage.

16) Lista de verificación de implementación

• Esquemas/Contratos en el Registro; pruebas de back-compat verde.
• Stream: watermarks/allowed-lateness, дедуп, DLQ; Panel OLAP en venta.
• Batch: incrementos/CDC, SCD II, Oro D + 1 con exportaciones WORM.
• Una sola capa semántica de métricas; nightly Stream↔Batch de conciliación.
• DQ-dashboards Freshness/Completeness/Validity; alertas lag/late/dup.
• RBAC/ABAC, cifrado, residencia; DSAR/RTBF/Legal Hold.
• El costo bajo control (costo/GB, costo/query, tamaño del estado, réplicas de cuotas).

17) Resultado

Stream y Batch no son competidores, sino dos engranajes de la misma unidad. Stream da una reacción «aquí y ahora», Batch es una verdad verificable «por la mañana». El enfoque de Lakehouse híbrido, una sola capa de métricas y la disciplina de DQ/lineage le permiten construir contornos analíticos rápidos, reproducibles y cumplidos, óptimos en SLA y costos.