GH GambleHub

Procesos ETL/ELT

1) Asignación y contexto

Los transportadores ETL/ELT proporcionan una carga predecible, transformaciones y publicación de datos para reporting (GGR/NGR, reguladores), análisis/ML y paneles operativos.

ETL: transformamos antes de la descarga en DWH/Lakehouse (menos común en los stacks modernos).
ELT: primero enviamos a Lakehouse (Bronze/Silver), luego transformamos SQL/motores (recomendado).

2) Arquitectura de referencia

1. Ingest/Edge: HTTP/gRPC/Batch, CDC de OLTP, proveedores de S3/FTP de descarga.
2. Bronze (raw, append-only): payload's inmutables, lotes por fecha/mercado/tenant.
3. Silver (clean/amb): normalización, dedoup, directorios, SCD, FX/timesons.
4. Gold (serve): vitrinas desnormalizadas bajo BI/regulador/modelos.
5. Orquestación: Airflow/Dagster/Prefect (DAG 'y, SLA, retraídas, turnos).
6. DQ/Contracts: Schema Registry + DQ-как-код, consumer-driven tests.
7. Observabilidad: métricas de paipelines, lineage, logs, cost-dashboards.

3) Selección de ETL vs ELT

CriterioETLELT (recomendado)
Flexibilidad de los nuevos cálculosBajaalto (time-travel, reprocessing)
Costomás caro al creceróptimo al escalar
Control de calidaden ingesten Silver/Gold + DQ-como-código
Historicidad/fuerzaEs limitadacompleto (Bronze append-only)

Práctica: en iGaming - ELT + CDC: enviamos rápidamente, luego estandarizamos y contamos.

4) Incrementos y CDC

Acercamientos a los deltas:
  • CDC (Debezium/replicación de registro): cambios de OLTP → Bronze → MERGE en Silver.
  • Watermark en el tiempo: 'updated _ at> max_loaded_ts'.
  • Hash-diff: comparación de 'md5 (row)' para el detalle de los cambios.
  • Upsert/MERGE: idempotencia de las descargas.
Ejemplo de MERGE (Delta/Iceberg):
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) Contratos y esquemas

Schema-first: JSON/Avro/Protobuf en el Registro; 'schema _ version' en eventos/archivos.
Evolución: back-compatible (adiciones nullables); breaking - '/v2 '+ grabación doble.
Campos obligatorios: 'event _ time (UTC)', 'event _ id', 'trace _ id', 'user _ pseudo _ id', 'market'.

6) DQ-como-código (conjunto mínimo)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: unique_tx # uniqueness of transactions type: unique columns: [transaction_id]
severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
severity: major
- name: amount_positive type: range column: amount_base min: 0. 01 severity: critical
- name: fk_user type: foreign_key column: user_pseudo_id ref_table: dim. users_scd severity: critical

7) Orquestación: DAG 'y, dependencias, SLA

Diseño DAG: de fuentes a vitrinas; dependencias explícitas entre tareas.
Retraídas e idempotencia: backoff, repeticiones «puras», checkpoint's.
Turnos (catchup): un dogón ordenado de períodos perdidos.
SLA: por ejemplo, Gold. daily listo hasta las 06:00 hora local; alertas de infracciones.
Parametrización: mercados/tenantes/fechas a través de vars; un único patrón job's.

8) Idempotencia y exactly-once

En ingest: duplicados son posibles → dedoup por '(event_id, source)'.
En el procesamiento: upsert/merge; funciones de transformación «puras».
En sink: commits transaccionales o escrituras idempotentes; control de «doble contabilidad».
Outbox/Inbox: publicación transaccional de eventos de dominio desde OLTP.

9) Backfill и reprocessing

Backfill: relleno primario/rangos históricos.
Reprocesamiento: volver a calcular cuando se cambia la lógica/correcciones.
Guardrails: límites de rangos, cuotas, ventanas de tiempo, dry-run con la comparación de métricas.
Etiquetado: 'logic _ version', 'reprocessed _ at', 'recalc _ reason'.

10) Modelado Silver/Gold

Silver (3NF/BCNF): los hechos 'nat _ bets/payments/payouts', las medidas' dim _ users/games/providers/markets (SCD II) ', la estandarización de divisas/timeson.
Oro: vitrinas desnormalizadas bajo BI/regulador/modelos; Paquetes de exportación inmutables (WORM) + firma.

Ejemplo Gold: GGR Daily

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;

11) Privacidad y residencia

PII-minimización: tokenización; Mapings de ID reales en un circuito aislado.
RLS/CLS: políticas de acceso por roles/jurisdicciones, enmascaramiento.
Residencia: catálogos/claves individuales para EEA/UK/BR; Prohibición de la join's cruzada-regional sin fundamento.
DSAR/RTBF & Legal Hold: edición selectiva, archivos WORM para informes, auditoría de exportaciones.

12) Observabilidad y SLO

SLI/SLO puntos de referencia:
  • Freshness Silver p95 ≤ 15 min; El Gold Daily está listo hasta las 06:00. tiempo.
  • Completeness ≥ 99. 5%, Validity (esquema) ≥ 99. 9%.
  • Éxito job's ≥ 99. 0%, incidentes MTTR ≤ 24-48 h.

Dashboards: Freshness heatmap, embudo de pérdida DQ, costo/query & costo/GB, lineage-grafo.

13) Rendimiento y costo

Lotes: fecha/mercado/tenant; clustering/Z-order por filtros.
Formatos: Parquet + ACID (Delta/Iceberg/Hudi), compresión y estadísticas.
Compacto: lucha contra los archivos pequeños (OPTIMIZE/VACUUM).
Materialización: unidades estables; evitar las gigantescas join's on-the-fly.
Chargeback: presupuestos, cuotas de réplica/backfill; planificación en ventanas de baja carga.

14) Ejemplos de tareas tipo DAG (pseudocódigo Airflow)

python with DAG("elt_payments_daily", schedule="@daily", start_date=..., catchup=True) as dag:
extract = BashOperator(task_id="extract_cdc", bash_command="run_cdc_to_bronze. sh {{ ds }}")
load  = BashOperator(task_id="load_to_silver", bash_command="sql/run_merge_silver. sql {{ ds }}")
dq   = BashOperator(task_id="dq_checks", bash_command="dq/run_checks. sh silver. payments {{ ds }}")
gold  = BashOperator(task_id="build_gold_ggr", bash_command="sql/build_gold_ggr. sql {{ ds }}")
export = BashOperator(task_id="export_regulator", bash_command="export/run_worm_pack. sh {{ ds }}")

extract >> load >> dq >> gold >> export

15) Procesos y RACI

R (Responsable): Ingeniería de datos (DAG 'y, modelos Silver/Gold), Plataforma de datos (infra, Registro, DQ).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed): BI/Producto/Marketing/Operaciones.

16) Hoja de ruta para la implementación

MVP (3-5 semanas):

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

2. Código DQ como (10-15 reglas) y dashboards básicos Freshness/Completeness.

3. Primer escaparate de oro (GGR Daily) con SLA «hasta las 06:00», exportación WORM con firma.

4. Orquesta DAG y alerta en SLA/DQ.

Fase 2 (5-10 semanas):
  • Extensión de dominio, SCD II para usuarios/juegos/proveedores.
  • Capa semántica de métricas; análisis de lineage/impact; procedimientos de backfill/reprocessing.
  • Regionalización (EEA/UK), RLS/CLS, control de valor (cuotas/chargeback).
Fase 3 (10-16 semanas):
  • Simulador de réplica (what-if), documentación de autogeneración de escaparates/métricas.
  • Optimización de costos (clustering, materialización, TTL, compactación).
  • Enseñanza de DR y recuperación de tiempo-viaje.

17) Lista de verificación antes de la venta

  • Contratos/esquemas en el Registro, las pruebas de compatibilidad son verdes.
  • Los CDC/incrementos y MERGE son idempotentes; dedoup en ingest.
  • Las reglas DQ están activas (critical → fail + DLQ), los dashboards SLA están configurados.
  • Las vitrinas de oro están documentadas, fórmulas métricas en la capa semántica.
  • RBAC/ABAC, cifrado, residencia, DSAR/RTBF/Legal Hold verificados.
  • Compacto/OPTIMIZE/VACUUM según lo programado; límites en backfill/réplicas.
  • Runbook 'e incidentes y reprocesamiento, auditoría de exportaciones (WORM + hash).

18) Anti-patrones y riesgos

Reload completo «por si acaso»: utilice CDC/incrementos.
Mezcla de datos crudos e informes: mantenga Bronze/Silver/Gold por separado.
Ausencia de DQ y lineaje: no hay probabilidad y reproducibilidad.
PII en capas analíticas: aísle los muppings, aplique CLS/RLS.
Joba «nocturna» monolítica: aplastar, paralela por lotes.
Ignorar el costo: siga los archivos pequeños, materialice los agregados, introduzca cuotas.

19) Glosario (breve)

ETL/ELT - extracción/transformación/descarga (antes/después de la descarga).
CDC - Captura de cambios.
SCD - Historización de las mediciones (I/II/III).
WORM: almacenamiento inmutable de paquetes de informes.
Time-travel - Leer las versiones históricas de las tablas.

20) Resultado

ETL/ELT modernos no son scripts, sino una plataforma administrada: contratos y DQ, incrementos/CDC idempotentes, disciplina de capas de Bronce/Plata/Oro, observabilidad y SLO, privacidad y economía. Siguiendo esta guía, obtendrá transportadores reproducibles y auditables que alimentan constantemente informes, productos y modelos a escala y sin sorpresas.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.