Lagos de datos y agregación de flujos

1) Propósito y valor

• Los flujos de productos/juegos/pagos aterrizan en Bronze «tal cual».
• Silver normaliza y enriquece, proporcionando claves coherentes y calidad.
• Oro - vitrinas agregadas (incluyendo real-/near-real-time) para BI, regulador, antifraude/RG.

La agregación de flujos en Lakehouse da: baja latencia en los informes, costo predecible, reproducibilidad y fuerza.

2) Arquitectura de referencia

1. Ingest/Edge: HTTP/gRPC, OTel, batch endpoints → шина (Kafka/Redpanda).
2. Bronze (append-only): almacenamiento de objetos + tablas ACID (Delta/Iceberg/Hudi), lotes por fecha/mercado/tenant; almacenamiento del payload original.
3. Stream Compute: Flink/Spark/Beam - unidades de ventana, CEP, dedoop, online-lookups.
4. Silver (clean/amb): normalización de monedas/timeson, FK/directorios, SCD para mediciones.
5. Serving/OLAP: ClickHouse/Pinot/Druid: agregados de minutos/segundos materializados para paneles.
6. Gold (serve): escaparates diurnos/relojes, cortes reguladores, paquetes de exportación inmutables (WORM).
7. Contornos de control: Registro de Schema, código DQ-like, lineage, directorios, secretos/KMS, RBAC/ABAC.

3) Contratos y esquemas

Schema-first: JSON/Avro/Protobuf; campos obligatorios: 'event _ time (UTC)', 'event _ id', 'trace _ id', 'user _ pseudo _ id', 'market', 'schema _ version'.
Evolución: back-compatible → añadir nullable; breaking → '/v2 '+ grabación doble.
Catálogo: descripción del dominio, propietario, frescura SLA, reglas DQ, lineage.

4) Desembarco de flujos en el lago

Exactly-once en la parte inferior: en-least-once publishing + idempotent sink (MERGE/upsert por 'event _ id').
Dedoop: stateful en stream + singularidad en Silver.
Compilación de archivos: archivos pequeños → OPTIMIZE/VACUUM regulares para lectura y costo.
Time-travel: incluye depuración, replay y audit.

sql
CREATE TABLE bronze. payment_events (
event_id STRING, user_pseudo_id STRING, currency STRING,
amount DECIMAL(18,2), market STRING, event_time TIMESTAMP, payload STRING
)
PARTITIONED BY (days(event_time), market);

5) Agregación de flujos: ventanas y watermarks

• Tumbling - fijo (por ejemplo, 1 min/5 min) para paneles estables.
• Hopping - superposición (paso
• Sesión: interrupciones del comportamiento por inactividad.
• Watermarks: control de datos latos (generalmente 2-5 minutos), reglas de preemergencia/corrección.

sql
SELECT market,
TUMBLE_START(event_time, INTERVAL '1' MINUTE) AS ts_min,
COUNT() AS deposits_1m,
SUM(amount_base) AS sum_1m
FROM silver. payments
GROUP BY market, TUMBLE(event_time, INTERVAL '1' MINUTE);

6) Materialización de agregados

Motor OLAP (ClickHouse/Pinot/Druid): almacena unidades de minutos/segundos para dashboards y análisis operativo.
Lakehouse Gold: almacena las rebanadas diarias/horarias para reportar y soldar (reproducibilidad).

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;

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(event_time) AS event_date,
market, provider_id,
SUM(stake_base) AS stakes_eur,
SUM(payout_base) AS payouts_eur,
SUM(stake_base) - SUM(payout_base) AS ggr_eur
FROM silver. fact_game_financials
GROUP BY 1,2,3;

7) Plata: normalización y armonización

Tiempo y moneda: 'event _ time (UTC)', 'amount _ base', 'fx _ rate _ used', 'fx _ source'.
Claves/referencias: 'user _ pseudo _ id', 'game _ id', 'provider _ id', 'market'.
SCD II: historización de las mediciones (users/games/providers/RG/KYC).
Reglas DQ: singularidad de claves, referencias, rangos de sumas, validez temporal.

8) Registro de agregados y definiciones «correctas»

Semantic Layer: fórmulas uniformes GGR/NGR, apuestas/ganancias, conversión, ARPPU, latency p95.
Versificación de métricas: 'metric _ version' y 'as-of' de cálculo.
Tarjetas de acoplamiento: owner, fórmula, fuentes, preparación SLA.

9) Exactly-once/idempotencia y orden

Bus: en-least-once + lote (orden local).
Procesamiento: dedoop por 'event _ id' (TTL 24-72h), operadores de CER/ventanas con ajustes.
Sink: commits transaccionales o idempotent upsert/merge.
Outbox/Inbox: publicación de eventos de dominio desde OLTP con garantía.

10) Datos latos y ajustes

Lateness Allowed: 2-5 minutos para escaparates operativos; repaso diario para Gold.
Correcciones: preemisiones en OLAP y reconsideración Gold (idempotent).
Indicadores: 'late = true', 'correction _ of = <event _ id>' para auditoría.

11) Observabilidad y DQ

• p95 ingest→1 -min escaparate ≤ 2-5 c; El Gold Daily está listo hasta las 06:00.
• Completeness ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Las métricas de paipelines son: lag/throughput/busy time/state size, late-ratio, dup-rate.
• DQ-dashboards: Freshness/Completeness/Validity, embudo de pérdida, tarjeta de llaves «hot».
• Lineage: camino de Bronce a Oro/Exportaciones; análisis de impacto en los cambios.

12) Privacidad, residencia, seguridad

Minimización PII: seudonimización, mapping protegido separado.
Residencia: EEA/UK/BR - directorios separados y claves de cifrado; Prohibición de la join's cruzada-regional sin fundamento.
Cifrado: TLS in-transit; KMS/CMK at-rest; firmas de exportación + WORM en el regulador.
DSAR/RTBF/Legal Hold: edición selectiva, congelación de desinstalaciones, accesos auditados.

13) Rendimiento y costo

Lotes: por fecha/mercado/tenante; clustering/Z-order por atributos filtrables con frecuencia.
Compacto: eliminación de archivos pequeños, OPTIMIZE/VACUUM regular.
Materialización: minutos/segundos - en OLAP; día/horas - en Oro.
Tiered storage: hot/warm/cold, recuperación SLA, chargeback por equipos (costo/GB, costo/query).
Preagrupaciones/sketches: HyperLogLog/approx-distinct donde es aceptable.

14) Ejemplos (fragmentos)

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

sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time) rn
FROM bronze. payment_events p
) WHERE rn = 1;

sql
MERGE INTO silver. fact_bets s
USING stage. fact_bets_delta d
ON s. bet_id = d. bet_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

15) Procesos y RACI

• Plataforma de datos (Lakehouse/catálogo/ACID, compacto),
• Streaming (agregados/CEP/dedup),
• Domain Analytics (métricas/Oro).
• A (Accountable): Head of Data/CDO.
• C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), SRE (SLO/стоимость), Security.
• I (Informed): BI/Producto/Marketing/Operaciones.

16) Hoja de ruta para la implementación

1. Lakehouse Bronze/Silver (tablas ACID), ingest de Kafka, circuitos de registro.

2. Unidades de flujo básico (1-5 min) en OLAP; escaparate Gold. ggr_daily (D + 1 hasta las 06:00).

3. DQ-as-code para Payments/Gameplay, dashboards Freshness/Completeness.

4. Compactación/OPTIMIZE, métricas de costo mínimo y alertas lag/late/dup.

• Expansión de Silver (SCD II para usuarios/juegos/proveedores), lineage y análisis de impacto.
• Lookups asíncronos (RG/KYC/ASN/BIN), control de correcciones late.
• Capa semántica de métricas, reglamento de exportaciones (WORM/firmas).

• Multi-región, DR/replay simulador, ventanas auto-tuning y watermarks.
• Costs-dashboards, chargeback/cupos, storage tiered y archiving.
• Autogeneración de documentación de escaparates y tarjetas métricas.

17) Lista de verificación antes de la venta

• Esquemas y contratos en el registro; pruebas de back-compat verde.
• Incluido dedoop, watermark/allowed lateness, DLQ.
• El compacto/OPTIMIZE/VACUUM está configurado según lo programado.
• SLO: p95 ingest→minute-view, Gold до 06:00; alertas lag/late/dup/state size.
• Las reglas DQ están activas; lineage es visible desde Bronze hasta las exportaciones.
• RBAC/ABAC и KMS; residencia y DSAR/RTBF/Legal Hold probado.
• El costo bajo control (costo/GB, costo/query, fracción cold), límites a las réplicas.

18) Anti-patrones y riesgos

Mezcla de datos crudos e informes en una tabla: rompe la reproducibilidad.
Sin compacción: explosión de archivos pequeños → consultas costosas.
Cálculo «retroactivo» de FX: rompe el historial y los informes.
No hay watermarks/late-politics: vitrinas y alertas «flotan».
Reload completo sin necesidad: use incrementos/MERGE y ajustes.
PII en análisis: mantenga los muppings separados, active CLS/RLS.

19) Glosario (breve)

Lakehouse - data lake + tablas ACID y motor SQL.
Bronze/Silver/Gold - capas crudas/normalizadas/de surf.
Watermark es el límite de preparación de ventanas por tiempo de evento.
Materialized View es un escaparate anticipado para una lectura rápida.
Time-travel - Leer las versiones históricas de las tablas.
WORM - Almacenamiento inmutable de artefactos de exportación.

20) Resultado

Un lago de datos con la agregación en streaming correcta es una disciplina de capas y contratos: Bronce «tal cual», Plata para normalización y calidad, OLAP para paneles de minutos, Oro para informes reproducibles. Al administrar ventanas y watermarks, dedup y compactación, privacidad y costo, obtiene vitrinas rápidas, verificables y completas para el producto, el cumplimiento y la gestión operativa.