Almacenes de datos y modelos OLAP
(Sección: Tecnologías e Infraestructura)
Resumen breve
Data Warehouse (DWH) es la capa base de análisis de iGaming: informes a reguladores, rentabilidad por producto/mercado, cohorte LTV, análisis antifraude, segmentación CRM y dashboards de tiempo real. El DWH sostenible se basa en un modelo de datos claro (Star/Snowflake/Data Vault), integración confiable (ETL/ELT + CDC), rendimiento inteligente (motores de columna, lotes, MVs), métricas de semántica rigurosa, seguridad/PII y gestión de costes
Enfoques arquitectónicos
Clásico DWH (Kimball vs Inmon)
Kimball (Dimensional/Star/Snowflake): vitrinas rápidas de informes; enfoque en hechos y dimensiones, historia SCD. Rápido tiempo.
Inmon (Corporate Information Factory): núcleo normalizado + escaparates; más difícil en el tiempo, pero rigurosa y centralmente.
Data Vault 2. 0
Hubs-Links-Satellites: modelo escalable «crudo» para integrar fuentes y auditar cambios. Encima se construyen las vitrinas Star.
Data Lake / Lakehouse
Data Lake: archivos en bruto (Parquet/ORC) + directorios (Hive/Glue/Unity/Metastore).
Lakehouse: una sola capa para batch/stream, tabla ACID (Delta/Iceberg/Hudi), time-travel, upsert/merge, archivos compactos, Z-order/Clustering.
Medallion (Bronze–Silver–Gold)
Bronce: datos crudos (raw) + CDC.
Silver: limpiado y conformado.
Oro: escaparates de negocios/métricas/cubos.
Adecuado para híbridos (Kafka → Bronze; Silver в Lakehouse; Gold в ClickHouse/BigQuery/Snowflake).
Modelos OLAP: Star, Snowflake, Data Vault
Star Schema (estrella)
Datos de la tabla: transacciones (apuestas, depósitos, sesiones).
Dimensiones: jugador, juego, proveedor, fecha/hora, geo, canal de atracción.
Ventajas: Joynes simples, rendimiento proyectado.
Snowflake
Normalización de las mediciones (jerarquías de países/regiones/ciudades, jerarquías de productos).
Ventajas: menos duplicación; menos - más Joynes.
Data Vault → Star
Los cambios crudos se suman en DV (auditoría, reproducibilidad completa), los escaparates de los informes son construibles como Star/Snowflake.
Integración: ETL/ELT, CDC, cambios lentos
Pipeline
Outbox/CDC de OLTP (Postgres/MySQL) → Kafka/conectores → Bronze.
ELT: limpieza, dedoup, normalización en Silver.
Lógica de negocio y agregaciones en Gold/vitrinas.
SCD (Slowly Changing Dimensions)
Tipo 1: sobrescribir (para campos no esenciales).
Tipo 2: historicidad (versiones fechadas) - estándar para perfiles/canales/precios.
Tipo 3: almacenar un par de valores (raramente).
sql
-- insert new dimension version
INSERT INTO dim_player (player_sk, player_id, country, valid_from, valid_to, is_current)
SELECT gen_sk(), s. player_id, s. country, now(), '9999-12-31', true
FROM staging_player s
LEFT JOIN dim_player d ON d. player_id = s. player_id AND d. is_current = true
WHERE d. player_id IS NULL OR d. country <> s. country;
-- closing the old version
UPDATE dim_player d
SET valid_to = now(), is_current = false
FROM staging_player s
WHERE d. player_id = s. player_id AND d. is_current = true AND d. country <> s. country;Capa semántica y métricas «verdaderas»
Introduzca una sola capa de métricas (capa semántica): definiciones GGR, NGR, Net Deposits, ARPPU, LTV, Churn, Retention Cohorts.
Métricas como código (dbt metrics/LookML/Semantic Layer) → las mismas fórmulas en todos los informes.
Calendario: tabla de fechas/horas con atributos TZ/regiones/fines de semana/campañas.
Almacenes y motores: seleccione debajo de un perfil
Columnas y nubes DWH
ClickHouse: análisis/agregaciones ultrarrápidas, representaciones materializadas, proyecciones; excelente para eventos/telemetría y escaparates de marketing.
BigQuery: servidor, escala, cachés/clústeres automáticos; precio por escaneo; conveniente para cargas mixtas y ad-hoc.
Snowflake: oficina de computación/almacenamiento, clústeres bajo demanda, tiempo de viaje; transparente para diferentes comandos.
Redshift/Vertica/Pinot/Druid: opciones bajo OLAP/tiempo real.
Afinar el perfil
Partido por fecha/región/canal.
Clustering/ordenamiento por claves de filtrado/joynes.
Compresión y codificación por diccionarios.
Preagregaciones (rollup, cubes), representaciones materializadas.
Funciones de approx (HyperLogLog/approx_distinct) para calificaciones baratas.
Diseño de rendimiento
Partición y agrupamiento
El partido es el límite del compartimento. Lotes de día/hora para eventos.
Clustering (sort keys/Z-order): acelera los rangos y join-s.
Representaciones materializadas (MV)
Pre-cuenta GGR/NGR por día/país/producto.
Actualización incremental de CDC Stream.
sql
CREATE MATERIALIZED VIEW mv_ggr_daily
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMMDD(ts)
ORDER BY (country, product_id, toDate(ts)) AS
SELECT toDate(ts) AS d,
country,
product_id,
sum(stake) AS stake_sum,
sum(win) AS win_sum,
sum(stake - win) AS ggr
FROM bets
GROUP BY d, country, product_id;Modelos incrementales (dbt/ELT)
Estrategias 'insert _ overwrite' por lotes, 'merge' por llaves CDC, 'watermark' por 'updated _ at'.
Estrategias de Join
Réplica de medidas en cada segmento de lote (denorm).
Broadcast small dims; shuffle large facts con clasificación por clave.
Costo: control y optimización
BigQuery/Snowflake: limite el tamaño del escáner (diseñe lotes/clústeres), active las vistas de caché/materializadas, limite las misiones BI automáticas.
ClickHouse: tamaño de lotes, frecuencia de medición, presupuesto de almacenamiento (TTL para eventos crudos, las agregaciones son duraderas).
La semántica de métricas acorta los cálculos «duales».
Pruning de datos: retoque para Bronze, agregaciones para Gold.
Calidad de datos (DQ), directorio, lineage
Cheques DQ: integridad (completeness), singularidad, rangos, reglas de negocio (por ejemplo, GGR ≥ 0 en agregados).
Data Catalog & Lineage: descripciones de tablas/campos, propietarios, clasificación PII, seguimiento del informe al origen.
Control de esquemas: contrato de eventos/CDC, alertas en cambios incompatibles.
Seguridad, cumplimiento y multi-tenencia
Segmentación PII: zonas individuales, enmascaramiento/pseudonimización, columnas con cifrado KMS.
RBAC/ABAC: roles a nivel de proyecto/diagramas/tablas/filas (RLS), pinzas para «need-to-know».
Localización de datos: buckets/almacenes regionales (EU/TR/LATAM).
Auditoría de acceso: quién ha leído/cambiado vitrinas y modelos.
DR, backups y reproducibilidad
Versificación de código de datos (dbt/git), entorno Dev/QA/Prod.
Snapshots de metástor/directorio + versionar tablas (time-travel).
Retén/TTL de las capas Bronze/Silver/Gold; exportar escaparates críticos.
Día de juego: restaurar escaparates, comprobar la integridad de las métricas.
Vitrinas híbridas y de tiempo real
Stream-to-OLAP: Kafka → ClickHouse/Pinot/Druid para escaparates de minutos.
Vistas materializadas + CDC para actualizaciones casi online (5-15 min).
La capa semántica permanece unida: las métricas son idénticas en tiempo real y batch.
Ejemplo del escaparate «GGR por día y país» (SQL generalizado)
sql
CREATE TABLE fact_bets (
bet_id BIGINT,
player_sk BIGINT,
game_sk BIGINT,
country_sk BIGINT,
stake DECIMAL(18,2),
win DECIMAL(18,2),
ts TIMESTAMP
) PARTITION BY DATE(ts);
CREATE TABLE dim_country (
country_sk BIGINT PRIMARY KEY,
iso2 STRING,
region STRING,
valid_from TIMESTAMP,
valid_to TIMESTAMP,
is_current BOOL
);
-- Showcase
CREATE MATERIALIZED VIEW mart_ggr_daily AS
SELECT
DATE(ts) as d,
c. region,
SUM(stake) AS stake_sum,
SUM(win) AS win_sum,
SUM(stake - win) AS ggr
FROM fact_bets f
JOIN dim_country c ON c. country_sk = f. country_sk AND c. is_current
GROUP BY d, c. region;Lista de comprobación de implementación
1. Identifique las fuentes y los dominios, fije el diccionario de métricas.
2. Seleccione el modelo: DV para capas crudas/auditadas + Star para escaparates.
3. Diseñe lotes/clústeres bajo consultas y ventanas clave.
4. Configure CDC/ELT, políticas SCD y llaves de surrogate.
5. Introduzca la capa semántica (métricas como código) y el calendario de fechas/horas.
6. Cree MVs/preagregaciones para informes costosos.
7. Habilite el DQ/directorio/enlace y el control de esquemas.
8. Identificar RBAC/PII/localización, cifrado, auditoría.
9. Configure el monitoreo p95/p99, costo, alertas de degradación y sobrecostos.
10. Ejercicios regulares de RD y reproducibilidad de los alrededores.
antipatterny
«Un hecho gigantesco sin lotes» → escanea el terabyte y la cuenta crece.
Definiciones discordantes de métricas en diferentes dashboards.
La falta de SCD2 donde el negocio requiere historicidad.
Normalización prematura de las mediciones: joynas superfluas e informes lentos.
Datos crudos sin cheques DQ y lineage → informes de «nada».
Falta de retención/TTL → almacenamiento de basura y explosión de costos.
Resultados
Un iGaming-DWH fiable es un modelo claro (DV→Star), un diccionario de métricas unificado, lotes/agrupaciones correctos, escaparates materializados, DQ/lineage rigurosos, así como RBAC/PII/localización. Agregue streaming híbrido para la frescura, gestionado por ELT y disciplina de valor, y obtenga una plataforma de análisis sostenible que escale a torneos, informes regulatorios y un estudio ad-hoc sin sorpresas en p99 y presupuesto.