Transportadores de análisis y ETL

(Sección: Tecnologías e Infraestructura)

Resumen breve

El transportador analítico convierte los eventos operativos «crudos» de iGaming (apuestas, depósitos, webhooks de PSP, registros de juegos) en escaparates de métricas sostenibles (GGR/NGR, LTV, retransmisión, señales antifraude). Principios de referencia: modelo de capa única (Bronze/Silver/Gold), disciplina instrumental DQ/lineage, incrementalidad e idempotencia, observabilidad y SLO, control de costos. Las decisiones se toman teniendo en cuenta el perfil de carga (picos de torneos), la capacidad de regulación (PII/localización) y los requisitos de frescura de los datos del negocio.

1) Arquitecturas: ETL vs ELT, batch vs stream

ETL (Extract → Transform → Load): transformaciones anteriores a la descarga en DWH. Es adecuado donde las transformaciones requieren un entorno controlado/secretos hasta la «nube».
ELT (Extract → Load → Transformación): materia prima en Lake/Lakehouse/DWH, en adelante SQL/motor (scripts dbt/SQL). Conveniente para motores de columna e iteraciones flexibles.
Batch: ventanas programadas (cada 5/15/60 minutos, nightly). Barato y previsible.
Stream: почти real-time (Kafka → Flink/ksqlDB → OLAP). Para escaparates near-real-time (5-60 segundos) y señales antifraude/CRM.
Híbrido: Bronze se llena de streaming, Silver/Gold son modelos de batch incrementales.

Recomendación: en iGaming mantener ELT + streaming: eventos a través de CDC/outbox → Bronze (minuto de frescura), transformaciones incrementales en Silver/Gold.

2) Modelo laminado (Medallion)

Bronze (Raw): eventos crudos/CDC sin lógica de negocio. Formatos Parquet/ORC, esquemas tal como son, validación mínima.
Silver (Conformed): limpieza, desduplicación, normalización de identificadores, medición SCD, unificación de divisas/zonas horarias.
Oro (Marts): escaparates de negocios (hechos/medidas, cubos), views materializados, preagrupaciones (días/países/productos).

Pros: reproducibilidad, evolución transparente, diferentes SLO y TTL en capas.

3) Fuentes y carga: CDC, outbox, archivos

CDC (Change Data Capture): flujos de cambios desde OLTP (Postgres/MySQL) con garantía de orden e idempotencia.
Patrón de outbox: los eventos se registran en la tabla/colección de outbox en la transacción del servicio → el conector publica en el bus/lago.
Descarga de archivos: descargas PSP, informes de afiliados; use manifiestos, control de tomas (checksum) y directorios de recepción.

Prácticas: se versionan las fuentes (versión schema), para cada fuente es un contrato de campos y expectativas de calidad.

4) Orquestación: DAG, dependencias, depla

DAGi: dependencias explícitas (raw → staging → dims → facts → marts).
Idempotencia de las tareas: reinicio sin efectos secundarios (partition-overwrite, 'MERGE '/upsert).
Separación del entorno: Dev/Stage/Prod, artefactos de promoción, «puerta manual» (manual approval) para backfill caro.
Planificación: cron/ventanas temporales + activadores de eventos (cuando llegan los archivos/lotes).
Secretos: fuera del secreto del gerente; prohibición de secretos en el código DAG.

python with DAG("dwh_daily", schedule="0  ") as dag:
bronze = ingest_cdc(source="payments", partition=hour())
silver = dedup_normalize(input=bronze)
dims  = build_dimensions(input=silver)
facts = build_facts(input=silver, dims=dims)
marts = build_marts(input=facts)
bronze >> silver >> [dims, facts] >> marts

5) Calidad de los datos (DQ) y lineaje

Cheques DQ: integridad (count, late arrivals), singularidad de claves, rangos/reglas de dominio (suma ≥ 0, moneda en referencia).
Umbral de activación: parada dura/soft-fail con alerta dependiendo de la criticidad de la tabla.
Lineage/catálogo: de report a fuente (tablas, columnas, métricas), propietarios, documentación, clasificación PII.
Control de circuitos: pruebas automáticas de compatibilidad (backward-/forward-compatible), alerta de cambios «rompedores».

6) Modelado: SCD, llaves de surrogate, normalización

SCD2 para las medidas: 'valid _ from/valid _ to/is _ current', surrogate key ('_ sk') y clave natural ('_ id').
SCD1: sobrescribir para atributos no esenciales (por ejemplo, la interfaz local).
Llaves de surrogate: '_ sk' estables para join, llaves naturales - para la singularidad.
Normalización de las mediciones: snowflake donde las jerarquías son profundas; de lo contrario, star por la velocidad.

7) Modelos incrementales y lotes

Marca de agua ('updated _ at', 'ingest _ ts'): sólo lee las cadenas nuevas/modificadas.
Estrategias incrementales: 'MERGE' por claves de negocio, 'INSERT OVERWRITE' por lotes, 'DELETE + INSERT' por lotes pequeños.
Partido: por fecha/hora/región; clustering (sort keys/Z-order) por claves de filtrado y join.
Representaciones materializadas: preagregación GGR/NGR, caché de secciones populares.
Unidades approx: HLL/approx_distinct para escaparates baratos top-N.

sql
MERGE INTO fact_deposits f
USING staging_deposits s
ON (f. deposit_id = s. deposit_id)
WHEN MATCHED THEN UPDATE SET amount = s. amount, status = s. status, updated_at = s. updated_at
WHEN NOT MATCHED THEN INSERT (...)
VALUES (...);

8) Backfill, reprocessing y gestión de historia

Backfill: DAGs individuales y con límites de recursos y ventanas; una clara «ventana de la verdad» (por ejemplo, 2024-01-01.. 2025-11-05).
Reprocesamiento: las transformaciones deterministas → la repetición producen el mismo resultado. Lógica de versiones de código de modelo.
Time-travel/versiones de tablas: conveniente para investigaciones y DR de «errores lógicos».
Retracción: política de revocación de datos (eliminación/corrección) con protocolo.

9) CLO/SLA/SLO del transportador

Frescura (frescura): Bronce ≤ 1-5 min, Plata ≤ 15 min, Oro ≤ 60 min (ejemplo).
Fiabilidad: porcentaje de carreras exitosas de DAG ≥ 99. x%.
Rendimiento: p95/p99 duración de nodos; Presupuesto de tiempo para el partido.
Lag monitoreo: rezago ingest-stream, profundidad de las colas, fracción «late data».
Alertas: perturbación de la frescura/volumen, DQ-feiles, aumento del costo de los escáneres, degradación del MV.

10) Costo: predicción y optimización

Los lotes y clústeres minimizan el volumen de escáneres.
Materialización de marcadores calientes (días/países/productos).
Caché de resultados/MVs para dashboards de uso frecuente.
Control de frecuencia de reinicio (ninguno «cada 5 minutos» sin motivo).
TTL: retiro agresivo de Bronze, plata media, oro largo (unidades únicas).
Planificación de la capacidad: métricas de catálogo, predicción de picos de torneos/campañas.

11) Seguridad, PII y localización

Clasificación de datos: PII/financiero/operativo.
Cifrado: en reposo y en tránsito; KMS/acceso basado en roles.
De-identificación: hashing/enmascaramiento, columnas individuales con claves.
RLS/pinzas para multi-tenencia (por 'tenant _ id').
Localización: zonas de almacenamiento y procesamiento por región (EU/TR/LATAM); exportar sólo a las ubicaciones permitidas.
Auditoría: lectura/escritura en tablas críticas, acceso al directorio.

12) Observabilidad: métricas, registros, tracks

Métricas de canalización: duración de las tareas, cola, errores, retrés, volumen de bytes/filas procesados, costo.
Registros: estructurados; correlación por 'trace _ id '/' run _ id'.
Treking: desde la fuente hasta el escaparate (ingest → transform → load → BI).
Dashboards: la frescura de las capas, el éxito de los DAGs, las consultas más caras, p95/p99.

13) Herramientas (puntos de referencia para los roles)

Orquestación: Orquestadores DAG (con planificador, retrés, alertas, secretos).
Transformaciones: simulación SQL («modelos como código»), pruebas unitarias de modelos, documentación.
DQ/contratos: marcos de verificación y SLA para conjuntos de datos.
Lineage/directorio: creación automática de grafos de dependencia, búsqueda del propietario.
Streaming: procesadores de ventanas/agregaciones, conectores sink/source.

(Los vendedores específicos se seleccionan bajo la pila de la empresa y los requisitos de seguridad).

14) Ejemplos de plantillas

Plantilla de escaparate GGR (SQL generalizado)

sql
CREATE OR REPLACE TABLE mart_ggr_daily AS
SELECT
DATE(b. ts) AS d,
c. country_code,
SUM(b. stake) AS stake_sum,
SUM(b. win)  AS win_sum,
SUM(b. stake - b. win) AS ggr
FROM fact_bets b
JOIN dim_country c ON c. country_sk = b. country_sk AND c. is_current
WHERE b. ts >= DATE_SUB(CURRENT_DATE, INTERVAL 60 DAY)
GROUP BY d, c. country_code;

Modelo incremental con «marca de agua»

sql
INSERT INTO fact_bets PARTITION (dt)
SELECT
FROM staging_bets
WHERE updated_at > (SELECT COALESCE(MAX(watermark), '1970-01-01') FROM _meta_watermarks WHERE table='fact_bets');
-- then update watermark

Comprobaciones DQ (idea)

sql
-- 1) key uniqueness
SELECT deposit_id FROM fact_deposits GROUP BY deposit_id HAVING COUNT()>1;

-- 2) negative amounts (error)
SELECT FROM fact_deposits WHERE amount < 0;

15) Lista de verificación de implementación

1. Definir diccionario de métricas (GGR/NGR/LTV/Retention) y propietarios.
2. Fije el SLO de frescura en las capas Bronze/Silver/Gold.
3. Estandarice los contratos de origen (esquemas, DQ, SLA).
4. Construye un gráfico DAG con pasos idempotentes y secretos aislados.
5. Implemente la incrementalidad (MERGE/overwrite por lotes) y las «marcas de agua».
6. Habilite el DQ (comprobaciones críticas/suaves), el lineage y el directorio de datos.
7. Ajuste la observabilidad (métricas, registros, tracks) y alertas.
8. Escriba Retén/TTL y la política backfill/reprocessing.
9. Proporcione control PII, cifrado, RLS y localización.
10. Pase un día de juego: simulando la caída de la fuente, «rompiendo» circuitos, backfill masivo.

16) Antipattern

«Una ETL nocturna para todo» sin partidos e incrementalidad.
La ausencia de DQ y lineaje → informes conflictivos y «caza fantasma».
Reciclaje completo de las tablas en cada lanzamiento (explosión de valor).
Ligamento rígido en tiempo real sin buffers/retraídas.
Mezcla de PII y escaparates públicos sin segmentación ni enmascaramiento.
No hay ninguna directiva de eliminación/retracción (no se pueden corregir los errores).

Resultados

La canalización de análisis sostenible en iGaming es una descarga en streaming ELT + en un modelo en capas con DQ/lineage rígido, modelos incrementales, orquestador transparente y SLO medibles. Agregue control de costos, políticas de PII/localización, ejercicios regulares de backfill/DR, y su plataforma de análisis se escalará de manera confiable bajo los picos del torneo, respondiendo al negocio con datos de la frescura y calidad deseadas.