Data Lake y DWH para casino: esquemas, descargas SLA

Texto completo del artículo

💡 18+. Material técnico para plataformas/operadores, estudios y equipos analíticos. No es una llamada al juego. La plataforma se refiere a PAM/monedero/cajero/bonos/RG, por los proveedores - RGS/live/jackpots/integración de pago.

1) Por qué los casinos Data Lake y DWH

Informe y cumplimiento: descargas regulatorias (GGR/NGR, KYC/AML, RG), auditoría del dinero.

Producto/marketing: LTV/retention, segmentación, A/B, recomendaciones.

Operaciones: monitoreo de proveedores, PSP, juegos en vivo SLA y taquilla.

Soluciones de datos: vitrinas rápidas (DWH) sobre almacenamiento barato a largo plazo (Lake).

En pocas palabras: Lake almacena capas crudas y depuradas, DWH proporciona consultas rápidas y modelos controlados.

2) Arquitectura de referencia (lakehouse)


Sources (OLTP, Kafka, Webhooks, CDC)
│
├─Bronze (raw, append-only; Parquet/Delta/Iceberg)
│   ingestion_time, source_metadata, no schema changes in place
├─Silver (cleaned, conformed; dedup, PII masking, SCD2)
│   business keys, constraints, quality checks
└─Gold (marts; star/snowflake; cube tables, aggregates)
└─DWH/Query Engines (Snowflake/BigQuery/Trino/Spark SQL)

Форматы: Delta Lake / Apache Iceberg / Hudi (ACID в lake, time travel, MERGE).

Archivos: Parquet + ZSTD/Snappy, destino ~ 128-512 MB; compilación de «archivos pequeños».

Catálogo: Hive/Unity/Iceberg Catalog; zonas 'bronze/silver/gold' en baquetas per region/tenant.

3) Esquemas de dominio (conceptualmente)

3. 1 Cartera/Contabilidad

`wallet_entry`: `entry_id`, `account_id`, `direction (debit	credit)`, `amount_minor`, `currency`, `reason`, `reference_id`, `occurred_at`, `region`, `tenant_id`, `trace_id`, `idempotency_key`.
Invariante: suma por cuenta = saldo (vía snapshot + change log).

3. 2 Apuestas/settlement (RGS/live)

`bet`: `bet_id`, `round_id`, `player_id`, `game_id`, `stake_minor`, `currency`, `placed_at`, `brand/region`, `provider_id`, `in_bonus`.

`settlement`: `settlement_id`, `bet_id`, `round_id`, `win_minor`, `settled_at`, `jackpot_hit`, `bonus_state`.

3. 3 Pagos (Caja/PSP/Crypto)

`payment_intent`: `intent_id`, `player_id`, `method`, `status`, `amount`, `currency`, `psp`, `created_at`.

'capture/refund/chargeback': tablas individuales con referencias a 'intent _ id', 'psp _ ref', códigos de causa.

Крипто: `txid`, `network`, `confirmations`, `finalized_at`.

3. 4 Bonos/Vager/Jackpots

`bonus_grant`, `bonus_progress (wager)`, `jackpot_contribution`, `jackpot_payout`.

3. 5 Manuales y medidas

'dim _ player' (pseudo-ID, geo, canales, estados RG - sin PII en analítica), 'dim _ game', 'dim _ provider', 'dim _ psp', 'dim _ brand', 'dim _ region', medidas de calendario.

Claves y compatibilidad: en los modelos Silver/Gold, las claves de negocio estables ('bet _ id', 'round _ id', 'payout _ id', 'intent _ id') y la semántica de eventos 'idempotentes'.

4) Flujos de descarga: streaming + microbatches

Streaming (Kafka/Pulsar → Bronze): eventos OLTP y webhooks, outbox/CDC, garantías «al menos una vez» con deduplicación en Silver.

CDC (Debezium/registro de replicación): cambiar las tablas OLTP (wallet/payments) → Bronze.

Microbatches: informes PSP/bancos/castodi (SFTP/API) → Bronze Raw Files → normalización.

MERGE in Silver: dedoup por 'idempotency _ key/event _ id', eliminación de atrasos ('watermark') SCD2 en las medidas.

5) SLA de descargas y ventana de retrasos (watermarks)

5. 1 SLA tipo (puntos de referencia)

Eventos Wallet/ledger: Bronce ≤ 1-2 min, Plata ≤ 5-10 min, Martas de Oro ≤ 15 min.

Bets/settlements: Bronce ≤ 1-2 min, Plata ≤ 10 min, Oro ≤ 30 min.

Pagos (PSP webhooks): Bronce ≤ 5 min, Plata ≤ 15 min, Oro ≤ 30-60 min.

Crypto Finality: depende de la red; escaparates con N. de confirmación.

Informes diarios PSP/bancos: T + 1 hasta las 09:00 hora local de la región.

5. 2 Ventanas de retraso

Watermark según la hora del evento ('occurred _ at') + tolerancias:

monedero/apuestas: 24-48 horas, pagos/PSP: 72 horas (hay retro-webhooks), crypto: hasta 24 horas para raros reorgs.
Eventos de reprocess tardíos: recuento incremental de los escaparates de oro (MERGE), registro de correcciones.

5. 3 Comunicación SLA

El directorio de datos contiene atributos SLA: 'freshness _ target', 'freshness _ status', 'expected _ lag _ p95', 'watermark'.

Dashboards de «frescura» con alertas cuando se violan.

6) Calidad de los datos (DQ) y contratos

Contratos de datos para cada tema: esquemas Avro/JSON, semver, campos obligatorios, invariantes empresariales (por ejemplo, 'win _ minor ≥ 0', 'currency ∈ ISO-4217').

Comprobación DQ de Silver: singularidad de claves, integridad referencial, comprobación de equilibrio (conciliación de billeteras), validez de códigos PSP/razones, rangos de fechas.

Severity: 'ERROR' (bloqueo), 'WARN' (etiquetado),' INFO '.

Monitoring:% de infracciones, causas superiores, tickets automáticos.

Sampling & replay: almacenar Bronze crudo para reciclar.

7) PII, residencia y seguridad

El escaparate PII está separado de los análisis: en Silver/Gold - alias, enmascaramiento/hashes, tokenización.

Residencia de datos: EU/UK/BR y otros - baquetas/catálogos físicamente separados; ninguna lectura cruzada-regional sin consentimiento y proxey.

Доступ: RBAC/ABAC (Lake/DWH), row-level security по `tenant/brand/region`.

Encriptación: En (KMS) e in-transit, claves por región/marca, auditoría WORM de acceso y cambios de políticas.

Derecho al olvido: mecanismo para localizar datos de juego sin eliminar registros financieros (de-identificación).

8) Modelado de escaparates de oro (estrella)

8. 1 Tabla de hechos

'nat _ bets' (apuesta y settlment por fila/o dos tablas), 'nat _ wallet _ entries', 'nat _ payments' (depósitos/cachautas/devoluciones), 'nat _ bonus _ wager', 'nat _ jackpot'.

8. 2 Medidas

`dim_date/time`, `dim_player` (pseudonymous), `dim_game`, `dim_provider`, `dim_psp`, `dim_brand`, `dim_region`, `dim_currency`.

8. 3 Métricas y cálculos

GGR/NGR, retención/frecuencia, RTP (por juego/proveedor/región), conversión de depósito, settle lag, PSP de tasa de éxito, costo-por-éxito, FX-PnL, jackpot contrations/payouts.

9) Rendimiento y costo

Partición: por 'occurred _ date' + 'region/tenant', a veces 'game _ id' para agregados de Oro.

Clustering/Z-Order: por 'player _ id', 'game _ id', 'psp', 'currency'.

Compacto y vacío: planeado 'OPTIMIZE/COMPACT', eliminación de versiones 'colgantes' (teniendo en cuenta retazos legales).

Caché: nat-cache/warehouse cache, vistas materializadas para paneles calientes.

Índices en DWH: cluster/segment (Snowflake clustering keys, BigQuery partition + cluster).

Costo: Bronze frío en almacenamiento de objetos, unidades de oro caliente/marzo - en DWH; auto-parking/auto-skale.

10) Linj, catálogos y documentación

Catálogo de datos (OpenMetadata/Amundsen/Collibra): descripción de tablas, propietario, SLA, campos PII, directivas de acceso.

Linj: desde la fuente (evento/CDC) hasta el escaparate y el informe; Visibilidad de dependencias para cambios seguros.

Esquemas de Changelog: semver y registro de deprechates; pruebas de compatibilidad en pipelines CI.

11) Reconciliation (conciliación de datos)

Diariamente:

'wallet _ entry' ↔ balances totales (acumulación de ≡ snapshot), pagos: informes PSP/bancos ↔ 'nat _ payments', crypto: 'txid/network' ↔ 'nat _ payments'.
Категории: `match`, `timing`, `missing_source`, `missing_platform`, `amount_mismatch`.
Alertas: fracción de 'mismatch'> umbral; aging no fieles> N días.

12) Tablas SLA de instancia (ejemplo)

Dominio	Bronze (ingesto)	Silver (limpieza)	Oro (marzo)	Eventos posteriores (watermark)
Wallet	≤2 de minas	≤10 de minas	≤15 de minas	48 h
Bets/Settlements	≤2 de minas	≤10 de minas	≤30 de minas	48 h
Payments (PSP)	≤5 de minas	≤15 de minas	≤60 de minas	72 h
Crypto	realtime→finalnost	≤15 de minas	≤60 de minas	24 horas
Reports (T+1)	06:00–08:00	≤09:00	≤10:00	7 d

13) Pipelines: de lo que recogemos

Ingeniería: Kafka Connect/Debezium, servicios de ingeniería en la nube, pullers SFTP.

ETL/ELT: Spark/DBT/Trino/Beam/Flink (Silver streaming), Airflow/Argo para orquestación.

Calidad: Grandes proyecciones/pruebas de Deex/dbt.

Monitoreo: OpenTelemetry + métricas Lake/DWH (freshness delay, job latency, costo).

Accidentes y repetición: reprocess de Bronze, dedoop con llaves, paipelines versionados.

14) Hojas de cheques

Arquitectura y seguridad

Formato Lakehouse (Delta/Iceberg/Hudi) con ACID y tiempo de viaje.
Separación 'bronze/silver/gold', outbox/CDC como fuentes principales.
Aislamiento PII, tokenización, RLS por 'tenant/brand/region'.
Residencia a nivel de baquetas/directorios, claves/secretos por región.
Auditoría WORM de cambios en esquemas/políticas/reglas de acceso.

Calidad y SLA

Contratos de datos y esquemas semiverales; pruebas de compatibilidad.
Watermarks y reprocess, escaparates MERGE incrementales.
Dashboards de frescura y alertas SLA; owner en cada tabla.
Reconciliation por monedero/pagos/cripto.

Rendimiento y costo

Partición y agrupamiento; compilación de «archivos pequeños».
Vitrinas materializadas bajo informes clave.
Auto-skale/auto-parking, política de retensado y archivos.

15) Banderas rojas (anti-patrones)

El BI y los informes regulatorios golpean directamente al OLTP.

Bronze «reescribe» y pierde datos crudos.

No watermarks, los eventos posteriores se «recortan».

No hay dedo por 'idempotency _ key '/' event _ id' → tomas en Oro.

El PII y el dinero de las diferentes regiones se mantienen juntos sin RLS y residencia.

Los esquemas cambian «silenciosamente» (sin semver/contratos), rompiendo las vitrinas.

Millones de pequeños archivos de parquet sin compilación → costosas solicitudes.

No hay SLA/dashboards de frescura; «sorpresas» en el informe trimestral.

16) Conclusión

Data Lake + DWH en iGaming no es solo un almacenamiento, sino un ecosistema controlado: esquemas y contratos estandarizados, ACID-lakehouse, nítidos SLA de frescura y ventanas de retraso, calidad y linaje, seguridad PII y residencia. Agregue reconciliation y ahorros en particiones/compacciones, y tendrá una base para reporting, soluciones de productos y escalar su negocio sin migraciones nocturnas y «Excel manual».