Procesamiento por lotes de datos

1) Propósito y valor

• Informes regulatorios y financieros (GGR/NGR, impuestos, registros RG/AML).
• BI y análisis de productos (cohortes, LTV, embudos de conversión).
• Verificador de precisión (OLTP↔DWH, proveedores/PSP), historización (SCD).
• Preparación de fichas y kits de entrenamiento para ML.

Propiedades clave: previsibilidad, integridad, reproducibilidad, bajo costo por unidad de datos.

2) Arquitectura (referencia)

1. Ingest (captura de raw): HTTP/gRPC, CDC de OLTP, proveedores de descarga → Bronze.
2. Lakehouse: Bronze (raw, append-only) → Silver (clean/conform) → Gold (serve).
3. Orquestación: Airflow/Dagster/Prefect (DAG 'y, dependencias, retraídas, SLA).
4. Procesamiento: Spark/Trino/DBT/motores SQL; lotes y formatos ACID (Delta/Iceberg/Hudi).
5. DQ y Contratos: Registro de Schema, Reglas de DQ (YAML/SQL), pruebas de consumo.
6. Serving: BI/capa semántica, exportaciones reportadas (CSV/PDF/JSON + hash), API/GraphQL.
7. Observabilidad: métricas de paipline, lineage, logs, costo (costo/GB, costo/query).

3) Frecuencias y SLAs

Diario (D + 1 hasta 06:00 lock.) : informes GGR, descargas regulatorias, conciliaciones.
Horario/cuasirealtime: paneles operativos para Ops/Finanzas.
Semana/mes: finconsolidación, modelos y retrocesos.

• Los escaparates diarios de oro están listos hasta las 06:00 hora local.
• Freshness Silver p95 ≤ 15 min para microbatches/ ≤ 2 h para diurnos.
• Completeness ≥ 99. 5%, Validity (esquema) ≥ 99. 9%.

4) Descargas incrementales y CDC

• CDC (Change Data Capture): Debezium/replicación de registro → Bronze → incrementos en Silver.
• Watermark en el tiempo: 'updated _ at> max_loaded_ts'.
• Comparación hash: 'md5 (row)' para el niño de los cambios.
• Upsert/Merge: actualizaciones idempotentes de Silver/Gold.

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

5) SCD (historización de mediciones)

SCD I: regrabación (ortografía, correcciones menores).
SCD II: historia completa ('valid _ from/valid _ to/is _ current').
SCD III: «antes/después» para breves comparaciones.

sql
MERGE INTO dim. users_scd t
USING stage. users u
ON t. user_pseudo_id = u. user_pseudo_id AND t. is_current = TRUE
WHEN MATCHED AND (t. country <> u. country OR t. rg_status <> u. rg_status)
THEN UPDATE SET t. is_current = FALSE, t. valid_to = CURRENT_TIMESTAMP
WHEN NOT MATCHED
THEN INSERT (user_pseudo_id, country, rg_status, valid_from, valid_to, is_current)
VALUES (u. user_pseudo_id, u. country, u. rg_status, CURRENT_TIMESTAMP, NULL, TRUE);

6) Backfill и Reprocessing

Backfill: relleno primario/dosificación histórica.
Reprocessing: volver a calcular los escaparates después de editar la lógica/corregir los datos.

• Idempotencia (MERGE/upsert), inmutabilidad de Bronze, versionamiento de la lógica.
• Tiempo de viaje para repeticiones; snapshots de metadatos.
• Guardrails: limitación de rangos, cuotas y jobs competitivos.
• Documentación: runbook con pasos y criterios de finalización.

7) Modelado de capas

• Append-only, lotes 'event _ date', 'jurisdiction', 'tenant'.
• Almacenamos el payload original (para forensiki), fijamos 'ingested _ at'.

• Normalización y estandarización: FK/directorios, dedoup, FX/timesons.
• Tablas de hechos/medidas (3NF/BCNF), SCD para mediciones clave.

• Vitrinas denormalizadas bajo BI/regulador/finanzas, preparación SLA.
• La materialización de los agregados; artefactos de exportación inmutables (hash + WORM).

8) Calidad de los datos (DQ-like-code)

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

Políticas de reacción: critical → fail job + DLQ; mayor/menor → etiqueta + informe.

9) Capa semántica y presentación de informes

Definiciones de métricas unificadas (GGR/NGR, ARPPU, Retention) en semantic-layer/metrics-store.
Versificación de métricas; integración con paquetes de BI/exportación.
Informes: CSV/JSON/PDF + sha256, registro de descargas y Legal Hold si es necesario.

10) Privacidad, residencia, seguridad

PII-minimización: seudonimización de usuarios; mapping - en un circuito protegido separado.
Residencia de datos: catálogos separados/claves por EEA/UK/BR; Prohibición de la join's cruzada-regional sin fundamento legal.
Cifrado: TLS in-transit; KMS/CMK at-rest; Control de las exportaciones.
DSAR/RTBF: proyecciones calculadas, ediciones selectivas; auditoría de accesos.
Legal Hold: archivos WORM para artefactos regulatorios.

11) Rendimiento y costo

Partido por fecha/mercado/tenante; Z-order/cluster según predicados frecuentes.
Formatos: Parquet + tablas ACID; compresión/estadísticas, OPTIMIZE/VACUUM.
Materialización: agregaciones estables en Oro; evitar los jobs «monolíticos».
Cuotas/presupuestos: chargeback por equipos; límites de backfill/consultas pesadas.
Planificación: ventanas de baja carga (noche/fin de semana), prioridades de colas.

12) Observabilidad y gestión

Métricas de paipelines: duration, success rate, retries, rows processed, cost/query.
Métricas DQ: completeness, validity, uniqueness, errores FK, drift.
Freshness heatmap: por dominios y mercados; SLA-dashboards.
Lineage: origen desde Bronze hasta los informes; análisis de impacto antes de los cambios.
Alertas: presupuestos de SLO, degradación del DQ, retrasos, aumento del costo.

13) Ejemplos de modelos SQL/

sql
CREATE OR REPLACE TABLE silver. payments AS
SELECT p. transaction_id,
p. user_pseudo_id,
p. currency,
p. amount_orig,
r. rate AS fx_rate_used,
p. amount_orig r. rate AS amount_base,
p. market,
CAST(p. event_time AS TIMESTAMP) AS event_time
FROM bronze. payment_events p
JOIN dim. fx_rates r
ON r. date = DATE(p. event_time)
AND r. ccy_from = p. currency AND r. ccy_to = 'EUR';

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;

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

14) Procesos y RACI

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

15) Hoja de ruta para la implementación

1. Lakehouse Bronze/Silver (formato ACID), CDC/incrementos para 2-3 dominios.

2. DQ-like-code: 10-15 reglas para Payments/Gameplay + CI-validación.

3. El primer escaparate de oro (GGR Daily) con SLA hasta las 06:00; informe de exportación + hash.

4. Dashboards Freshness/Completeness/Cost, alertas básicas.

• SCD II для users/games/providers; Expansión de dominios.
• Capa semántica de métricas; conciliaciones con OLTP/proveedores (accuracy).
• Procedimientos de backfill/reprocessing, lineage y análisis de impacto, regionalización (EEA/UK).

• Simulación automática de cambios (dry-run), presupuestos/cuotas, chargeback.
• Documentación automática (páginas de producto de datos), ejercicios de DR y recuperación de tiempo de viaje.
• Optimización de costes (agrupamiento, materialización, TTL, vacío).

16) Lista de verificación antes de la venta

• Contratos y esquemas en el Registro, las pruebas de compatibilidad son verdes.
• Las descargas incrementales/CDC funcionan, MERGE es idempotente.
• Las reglas DQ están activas; critical → fail + DLQ; Informe de infracciones.
• SLA/dashboards de frescura/plenitud; alertas personalizadas.
• Las políticas PII/DSAR/RTBF/Legal Hold han sido confirmadas por Legal/DPO.
• Se han probado Runbook 'y backfill/reprocessing/DR.
• El costo bajo control (costo/query, costo/GB, cuotas).

17) Anti-patrones y cómo evitar

Jobs nocturnos monolíticos: aplastar en pasos independientes, paralelos por lotes.
Full-reload sin necesidad: utilice incrementos/CDC/merjes.
Mezcla de PII en análisis: mantenga los muppings separados, aplique CLS/RLS.
Sin DQ/lineage: introduzca el código DQ como código y rastree el origen.
Backfill's «manuales»: automatice y documente, limite los rangos.
Costo no administrado: clustering, materialización, políticas de retén.

18) Glosario (breve)

CDC - Captura de cambios de OLTP.
SCD - Mediciones de cambio lento (I/II/III).
Lakehouse - data lake + tablas ACID.
MERGE/Upsert - Operaciones de actualización idempotentes.
Time-travel - Lectura de las versiones históricas de las tablas.
WORM - Almacenamiento inmutable de artefactos.

19) Resultado

El procesamiento por lotes es una disciplina de transportadores predecibles, reproducibles y cumplidos. Siguiendo los principios de schema-first, incrementos/CDC, historización SCD, código DQ-as-code, observabilidad y economía consciente, obtendrá vitrinas de oro estables e informes verificados por las conciliaciones y listos para ser auditados en cualquier momento.