GH GambleHub

Arquitectura de flujo de datos

1) Nombramiento y principios

Objetivos: entregar datos correctos, oportunos y cumplidos para análisis, informes, antifraude, personalización y ML.

Principios:
  • Data as a Product: propietarios claros, contratos, SLO y versioning.
  • Schema-first: los esquemas son obligatorios; evolución según las reglas.
  • Privacy-by-Design: minimización de PII, seudonimización, control de acceso.
  • Observabilidad por defecto: trazados, métricas, lineaje, perfiles de calidad.
  • Costo-aware: tiered-storage, sampling de eventos ruidosos, compresión.

2) Paisaje de fuentes y eventos

Transaccional: depósitos/retiros, apuestas/pagos, bonos, chargeback.
Personalizado: sesiones, clics, conversiones, límites RG, estados KYC.
Operativos: registros de aplicaciones, métricas de rendimiento, alertas.
Proveedores: PSP/KYC/sanciones/estudios de juego (agregadores).
Referencias: catálogos de juegos, guías de países/monedas, tarifas/impuestos.

Tipificación de eventos (ejemplo):
json
{
"event_time":"2025-10-31T19:20:11Z",
"event_type":"payment. deposit",
"schema_version":"1. 3. 0",
"user":{"id":"U-123","country":"EE","age_band":"18-24"},
"payment":{"amount":200. 00,"currency":"EUR","method":"card","psp_ref":"PSP-222"},
"ctx":{"ip":"198. 51. 100. 10","session_id":"s-2233","trace_id":"f4c2..."}
}

3) Arquitectura de referencia (alto nivel)

1. Capa de Ingest

Gateways (HTTP/gRPC), conectores CDC (desde OLTP), colas/buses (Kafka/Redpanda), colectores de telemetría.
Validación, normalización, edición PII en la entrada, resolución de contrato.

2. Streaming capa

Streaming jobs (Flink/Spark Structured Streaming/Beam) con deduplicación, watermark, agregados stateful.
Fan-out en repositorios y servicios en línea (fichastor, antifraude).

3. Batch capa

Orquestación (Airflow/Dagster), descargas incrementales, retrocesos y retrocesos, tipos SCD.

4. Almacenamiento (Lakehouse)

Bronce: eventos crudos (append-only, immutable).
Silver: tablas limpias, conformes con calidad y dedup.
Oro: escaparates/martas para casos específicos (BI/regulador/ML).
Formatos de tabla con ACID (Delta/Iceberg/Hudi), separación por capas calientes/cálidas/frías.

5. Serving y acceso

BI/SQL (Trino/Presto/DuckDB), capa semántica (metrics layer), API/GraphQL, Feature Store para coherencia online/offline.

6. Gobierno y seguridad

Directorio/linage, reglas DQ, motor de acceso político (RBAC/ABAC), enmascaramiento/tokenización, archivo WORM para informes.

4) Contratos y esquemas

Contratos de datos: OpenAPI/AsyncAPI/JSON Schema/Avro.
Evolución: versiones semánticas; cambios compatibles con backward - agregar campos nullables; breaking - sólo con '/v2 'y doble entrada para el período de migración.
Registros: Registro de Schema, Directorio de dominios (Pagos, Juegos, Marketing).

5) Patrones de integración

CDC (Change Data Capture): de OLTP a bus (Debezium), partición por claves de dominio.
Outbox/Inbox: entrega garantizada de eventos de lógica de dominio.
Exactly-Once/Effectively-Once: transacciones en state, idempotent sink 'y, claves de deduplicación.
Data & Watermarks Late: procesamiento de eventos atrasados; ventanas con lateness allowed.
Reprocessing: paipelines idempotentes, time-travel, parches snapshot.

6) Modelo Lakehouse: bronce/plata/oro

Bronze (raw):
  • Lotes en tiempo (event_date) y mercado (jurisdiction).
  • Sólo adición; almacenamiento del payload original para el forensic.
Silver (clean):
  • Tipos normalizados, referencias, deduplicación por '(event_id, event_time)'.
  • Verificación de FK, estandarización de divisas/temporización, enriquecimiento.
Gold (serve):
  • Vitrinas denormalizadas (GGR, puntuación RG, LTV, tablas de cohorte).
  • SLA para actualizaciones, agregados de BI y reporting.

7) Calidad de datos (Calidad de datos)

Reglas: validación de esquemas, rangos, singularidad, integridad, integración referencial.
Perfilando: distribuciones, cardinalidad, «deriva» de rasgos.
Monitoreo: p50/p95 paipline retardo, drop-rate, error budget.
Política de degradación: folback automático (último snapshot), alertas y t-test de métricas.

Ejemplo de contrato DQ (YAML):
yaml table: silver. payments rules:
- name: amount_positive type: range column: amount min: 0. 01
- name: currency_valid type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: unique_tx type: unique columns: [transaction_id]
slo:
freshness_minutes: 15 completeness_percent: 99. 5

8) Privacidad y cumplimiento

Minimización PII y enmascaramiento: almacenar pseudo-ID, separar los muppings look-up.
Regionalización: baquetas/catálogos geo-locales (EEA/UK/BR), «residencia de datos».
Operaciones legales: DSAR/RTBF (proyecciones calculadas y ediciones selectivas), Legal Hold, archivos de informes inmutables.
Lógica de acceso: auditoría de lecturas de tablas «sensibles», break-glass y acceso JIT.

9) Observabilidad y gestión

Linage: seguimiento automático de las dependencias desde la fuente hasta el escaparate.
Métricas de paipelines: throughput, lag, failure-rate, costo/GB, costo/query.
Rastreo (OTel): 'trace _ id' de las aplicaciones se dirige a los eventos → construye la ruta de acceso de la consulta.
Alertas: presupuestos SLO, anomalías de frescura/volumen/cardinalidad.

10) Acceso y modelo de seguridad

Categorías de datos: público/interno/confidencial/restringido.
Políticas: row/column-level security; enmascaramiento dinámico (PAN/IBAN/email).
Administración de claves: KMS/CMK, encriptación en tránsito/en tránsito, rotación.
Segregación de responsabilidades: funciones separadas prod/analista/administrador/reviewer.

11) Data Mesh y enfoque del producto

Домены: Payments, Gameplay, Marketing, Risk, Compliance.
Producto de datos: propietario, frescura SLA, diccionario de campos, pruebas, versiones, métrica de consumo.
Contratos entre dominios: versionables, con compatibilidad con backward, test-consumer (consumer-driven).

12) Flujos Fichastor y ML

Registro de características: descripción de rasgos, fuentes, transformaciones, SLO.
Coherencia en línea/fuera de línea: un código de transformación, el retraso de la materialización en línea ≤ 200-500 ms.
Monitoreo de la deriva: PSI/KS, autocalertas y modelos de retroceso, control PII.
Registro de experimentos: metadatos, versiones, reproducibility, mapas de modelos.

13) Finmodelo y optimización de costo

Partición y Z-order/Cluster según predicados frecuentes.
Almacenamiento en frío y TTL para tablas no utilizadas, VACUUM.
Vistas materializadas sólo bajo patrones de consulta persistentes.
Cuotas y presupuestos para los jobs pesados; chargeback por equipos.

14) Topología regional y multi-tenente

Active-active multi-región: replicación de temas y tablas, perímetros pipelinos independientes.
Failover/DR: objetivos RPO/RTO, snapshots de metadatos orquestadores, prueba de recuperación.
Multi-tenencia: aislamiento de catálogos/claves/cuotas, etiquetado de tenant_id.

15) Procesos y RACI (brevemente)

R: Plataforma de datos (ingesto, almacenamiento, orquestación), Ingeniería de datos (transformaciones).
A: Head of Data / Chief Data Officer.
C: Compliance/Legal/DPO, Arquitectura, SRE.
I: BI/Análisis, Producto, Marketing, Finanzas.

16) SLO/SLI para subprocesos

Frescura (freshness): p95 latencia Silver ≤ 15 min, Gold (daily) listo ≤ 06:00 look. tiempo.
Plenitud: ≥ 99. 5% de eventos en la ventana T.
Validez: error-rate verificaciones DQ <0. 5% del volumen.
Disponibilidad de serving: ≥ 99. 9% para la API de BI/Feature.

17) Plantillas de tabla y partición

sql
-- Bronze: Deposit events
CREATE TABLE bronze. payment_deposits (
event_time TIMESTAMP,
event_id STRING,
user_pseudo_id STRING,
amount DECIMAL(18,2),
currency STRING,
psp_ref STRING,
payload VARIANT
)
PARTITION BY DATE(event_time)
CLUSTER BY (currency);

-- Silver: normalized model
CREATE TABLE silver. payments AS
SELECT event_id,
CAST(event_time AS TIMESTAMP) AS ts,
user_pseudo_id,
amount,
currency,
psp_ref
FROM bronze. payment_deposits
QUALIFY ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY ts) = 1;

18) Orquesta y DevX

Infra-as-Code: repositorios de pipelines, pruebas, rugidos, GitOps.
Data Contracts CI: linternas de circuitos, pruebas de DQ antes de deployas.
Backfill-framework: retroprocesos seguros con restricción de R/W e idempotency.
Catálogos y plantillas: generadores de pipelines (cookies), mejores prácticas.

19) Hoja de ruta para la aplicación

MVP (4-6 semanas):

1. Bus de eventos + ingest de 2 a 3 fuentes clave (CDC OLTP, puerta de enlace API).

2. Lakehouse Bronze/Silver, formato con ACID, directorio y reglas DQ básicas.

3. 1-2 vitrinas de oro (GGR diario y embudo de conversión).

4. Métricas lag/completeness, lineaje básico, RBAC y enmascaramiento PII.

Fase 2 (6-12 semanas):
  • Unidades de streaming (p95 latency ≤ 5 min), Feature Store, escaparates RG/AML.
  • Capa semántica de métricas, SLA por informe; dashboards de costo.
  • Regionalización (EEA/UK), procedimientos DSAR/RTBF, Legal Hold para artefactos.
Fase 3 (12 + semanas):
  • Datos Mesh: dominios de productos, contratos de consumo-controlados.
  • Operaciones ML con monitoreo de deriva, negociación automática en línea/fuera de línea.
  • Simulaciones automáticas de cambios de esquemas (impact analysis) y «what-if» por valor.

20) Errores frecuentes y cómo evitarlos

payload's crudo sin esquemas: implementar schema-first, registro y validación CI.
Ausencia de deduplicación: claves de evento e idempotent-xink en Silver.
Mezclar PII con analíticas: separar mappings y enmascarar campos.
Oro sin propietario: asignar owner, SLO y métricas de consumo.
No hay estrategia de reprocesamiento: tiempo-viaje, versionar la lógica, controlar la «doble contabilidad».
Costo no administrado: lotes, compresión, TTL, observabilidad del valor.

21) Glosario (breve)

CDC - Captura de cambios de OLTP.
Outbox - Publicamos eventos de dominio de forma transaccional.
Watermark - Evaluación de la plenitud del flujo para las ventanas.
Lakehouse - data lake + tablas ACID.
Data Product es una unidad de producto de datos con propietario y SLO.
Feature Store - Distribución coherente de señales de ML.

22) Resultado

La arquitectura de flujo de datos es un sistema de arreglos administrados: contratos claros, observabilidad, seguridad y costo bajo control. Siguiendo los patrones descritos (schema-first, bronze/silver/gold, CDC + Outbox, DQ y lineage, privacy-by-design), la plataforma proporciona confiablemente datos de calidad de negocios, cumplimiento y ML con SLL predecibles O y el costo de propiedad comprensible.

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.