Almacenes de datos

1) Asignación y función de DWH en iGaming

• Definiciones de métricas únicas (GGR/NGR, ARPPU, Retention, Churn).
• Informes reproductivos para reguladores y stakeholders internos.
• Escaparates rápidos para paneles BI/operativos y fuentes para modelos.
• Control de calidad, lineaje y seguridad a nivel de plataforma.

2) Opciones arquitectónicas

2. 1 Classic DWH

ETL → DWH (estrella/copo de nieve) → BI.
Ventajas: modelos controlables, consistencia fuerte.
Contras: descargas costosas, backfill sofisticado, flexibilidad limitada.

2. 2 Lakehouse DWH

Bronze/Silver/Gold en tablas ACID (Delta/Iceberg/Hudi) + motor SQL/MPP.
Ventajas: solo storage, tiempo-travel, simple reprocessing.
Contras: requiere disciplina de capas y DQ, una orquestación madura.

2. 3 Híbrido

Lakehouse como «fuente de la verdad» (Bronze/Silver), DWH-March en MPP (ClickHouse/Pinot/Druid/Cloud DWH) para lectura de alta velocidad.
Ventajas: equilibrio de valor y rendimiento, escaparates flexibles.
Contras: doble soporte para circuitos y rodillos, necesita sincronización.

Recomendación: para iGaming - Lakehouse + DWH-marzo (híbrido). Bronze/Silver - estandarizado, Marts Oro/Real-time - mantienen las cargas de lectura.

3) Simulación de datos

3. 1 Estrella y copo de nieve

Las tablas de hecho son: estrechas, de eventos: 'nat _ bets', 'nat _ payouts',' nat _ payments '.
Medidas: 'dim _ users' (SCD), 'dim _ games', 'dim _ providers', 'dim _ markets'.
Copo de nieve es apropiado en Silver (normalización), Estrella - en Oro (lectura).

3. 2 Data Vault 2. 0 (núcleo de integración)

Hubs (claves de negocio), Links (relaciones), Satellites (contexto/historia).
Aplicar en Silver para integraciones de proveedores/PSP de larga vida.

3. 3 SCD I/II/III

SCD II para RG/KYC/canales y atributos de juego (RTP/volatilidad).
Intervalos estrictos de 'valid _ from/valid _ to', correctos en el tiempo.

4) Descarga: ETL/ELT, CDC e incrementos

Enfoque ELT: descarga en Silver → transformaciones en DWH.
CDC: Debezium/replicación de registro desde OLTP; los mergues son idempotentes.
Incrementos: por agua del tiempo ('updated _ at> max_loaded_ts') y/o hash delt.
Backfill/Reprocessing: tiempo-viaje, rangos, cuotas, comparaciones dry-run.

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

5) Capa semántica y métricas

Metrics Store/Semantic Layer: fórmulas uniformes GGR/NGR/Conversion/LTV.
Versificación de métricas y cálculos «as-of» para la reproducibilidad.
Acuerdos: nombres de métricas, unidades, moneda (base EUR) y 'fx _ source'.

6) Vitrinas y serving

Vitrinas de oro: desnormalizado, preparación SLA (por ejemplo, hasta 06:00 lock.) .
Martes operativos: ClickHouse/Pinot/Druid para paneles de 1 a 5 minutos.
Exportación: CSV/JSON/PDF + hash; Paquetes inmutables (WORM) para reguladores.

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS 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;

7) Calidad de los datos (DQ) y contratos

Schema-first: JSON/Avro registry + test de compatibilidad (consumer-driven).
DQ-как-код: completeness/validity/uniqueness/FK/range/temporal.
Políticas de reacción: critical → fail + DLQ; mayor/menor → etiqueta e informe.
Observabilidad DQ: dashboards Freshness/Completeness/Validity, embudo de registros perdidos.

8) Seguridad, privacidad y residencia

PII-minimización: usuarios a través de pseudo-ID; Mapinga por separado.
RLS/CLS: acceso construido/postolbz por funciones y jurisdicciones.
Cifrado: TLS in-transit; at-nat - KMS/CMK con rotación.
Residencia de datos: directorios y claves individuales para EEA/UK/BR; Prohibición de la join's cruzada-regional sin fundamento.
DSAR/RTBF: proyecciones calculadas y ediciones selectivas; Legal Hold sobre los artefactos reportados.

9) Rendimiento y costo (Costo de ingeniería)

Lotes: por fecha/mercado/tenante; clustering/Z-order por 'market', 'provider _ id', 'game _ id', 'user _ pseudo _ id'.
Formatos: Parquet + estadísticas y compresión; OPTIMIZE/VACUUM según lo programado.
Materialización: agregados estables y tablas sumarias; evite los «gruesos» join's al vuelo.
Cuotas/Chargeback: presupuestos para solicitudes/réplicas pesadas; informes de costo/query, costo/GB.
Tiered storage: hot/warm/cold; nítidos SLA de recuperación.

10) Observabilidad y gestión

Métricas de paipelines: duración, volúmenes, retraídas, lagunas, tolerancia a fallas.
Métricas DWH: tiempo de respuesta/competitividad/hits de caché/costo.
Lineage: grafo de fuentes a informes; análisis de impacto en los cambios.
SLO: Freshness Silver p95 ≤ 15 мин; Gold daily - listo antes de las 06:00; Validity ≥ 99. 9%; Completeness ≥ 99. 5%; disponibilidad ≥ 99. 9%.

11) Multitenencia y aislamiento de dominio

División por schema/database/catalog en tenant/mercado.
Cupos y grupos de recursos; restricción de «vecinos ruidosos».
Políticas de exportación/importación entre tenantes, contratos estandarizados.

12) Registro de datos y documentación

Data Catalog: owner, SLA, esquema, ejemplos, reglas DQ, lineage.
Métricas/dashboards: tarjetas con fórmulas y responsables.
Change Log: versiones de lógica, migración, impacto (impact).

13) Procesos y RACI

R (Responsable): Ingeniería de datos (modelos Silver/Gold, DAG 'i), Plataforma de datos (infra, registro, DQ).
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.

14) Hoja de ruta para la aplicación

1. Lakehouse Bronze/Silver (tablas ACID), CDC/incrementos para Payments/Gameplay.

2. Los primeros escaparates de oro (GGR Daily, conversiones), SLA hasta las 06:00.

3. DQ-as-code (10-15 reglas) + dashboards Freshness/Completeness.

4. Directorio de datos y capa semántica básica de métricas.

• SCD II для users/games/providers; Expansión de dominios.
• Martes operativos (ClickHouse/Pinot) para paneles de tiempo real/near-real-time.
• Lineage/impact-analysis, procedimientos DSAR/RTBF, regionalización (EEA/UK).

• Simulación automática de cambios (dry-run), réplicas y comparación de métricas.
• Chargeback/cupos, costas-dashboards; Ejercicios de DR y recuperación de tiempo-viaje.
• Autogeneración de documentación de escaparates y tarjetas métricas.

15) Ejemplos de plantillas SQL

sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);

sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

sql
SELECT market, DATE(event_time) d, COUNT() n
FROM silver. fact_bets
GROUP BY market, DATE(event_time)
HAVING n = 0;

16) Lista de verificación antes de la venta

• Los esquemas y contratos en el registro, las pruebas de compatibilidad son verdes.
• Los CDC/incrementos y los procedimientos MERGE son idempotentes.
• Las vitrinas de oro tienen SLA, fórmulas métricas fijadas.
• Las reglas DQ están activas (critical → fail + DLQ), los dashboards Freshness/Completeness.
• RBAC/ABAC, cifrado, residencia por región, registros de acceso.
• Lineage/impact están habilitados; time-travel/backup/DR verificados.
• Costo bajo control: lotes, agrupamiento, materialización, cuotas.

17) Anti-patrones y riesgos

«Un DWH gordo sin capas»: una mezcla de datos crudos y reportados → caos y correcciones costosas.
Reload completo todos los días sin necesidad: use incrementos/CDC.
Oro sin dueño y fórmulas: falta de una versión única de la verdad → disputas y retrocesos.
PII en capas analíticas: mantenga los muppings separados, CLS/RLS.
Sin DQ/lineage: no hay probabilidad para reguladores/auditorías.
Costo no administrado: no hay lotes/optimizaciones/cuotas.

18) Glosario (breve)

DWH - Almacenamiento de datos para consolidación y análisis.
Lakehouse - data lake + tablas ACID y motor SQL.
CDC - Captura de cambios de OLTP.
SCD - Mediciones de cambio lento (I/II/III).
El escaparate de oro es una tabla/presentación de informes lista para consumir.
Semantic Layer son definiciones uniformes de métricas y atributos.

19) Resultado

El DWH moderno para iGaming no es una «tabla grande», sino una plataforma administrada: capas Bronze/Silver/Gold, contratos estrictos y DQ, métricas únicas y lineaje, privacidad y residencia, productividad y rentabilidad. Al construir Lakehouse + DWH-March híbrido, obtendrá una toma de decisiones rápida y verificable, lista para auditorías, escalas y nuevos mercados.