Data Lake y almacenamiento centralizado

(Sección: Tecnologías e Infraestructura)

Resumen breve

Data Lake es una capa básica de almacenamiento centralizado de materias primas y datasets consolidados. Para iGaming, acepta eventos de apuestas/pagos/registros de juegos, descargas de afiliados, CDC de OLTP y los entrega a analíticas, antifraude, CRM y BI. Práctica moderna - Lakehouse: formatos de columna abierta + capa de tabla ACID + directorio único + transacciones/versiones de datos. La clave del éxito es la disciplina de esquemas y partituras, la gestión de costes, la seguridad PII y una cultura operativa rigurosa (DQ, lineage, DR).

El rol de Data Lake en la plataforma iGaming

Un único punto de verdad para la analítica: almacenar datos crudos y depurados independientemente de la fuente y el formato.
Flexibilidad: soporte para batch y streaming (CDC/conectores, streams de eventos).
Evolución: de Bronze crudo a Silver conformes y escaparates de negocios Gold.
Responsabilidad compartida: los servicios prod escriben en bus/staging, analítica/ML consume desde capas de Lake.

Modelos arquitectónicos: Lago vs Lakehouse

Data Lake (S3/ADLS/GCS + Parquet/ORC): schema-on-read, almacenamiento barato, flexibilidad de formatos.
Lakehouse (Delta/Iceberg/Hudi sobre Parquet): transacciones ACID, upsert/merge, time-travel, archivos compactos, vacío, indexación/clustering.
Práctica: para iGaming, Lakehouse es beneficioso como capa principal, mientras que los OLAP externos (ClickHouse/BigQuery/Snowflake/Pinot) son como escaparates y motores de especias.

Modelo de medallón de capas

Bronze (Raw/Staging): archivos crudos de fuentes (CDC, volcado de registro, CSV afiliados, webhooks). La validación mínima, «tal cual».
Silver (Conformed): limpieza/desdoop, normalización de divisas/zonas horarias, tipos de cambio, medidas SCD, claves de consistencia.
Oro (Marts/Serving): unidades para GGR/NGR/LTV/Retention, vitrinas materializadas bajo BI/CRM/antifraude.
TTL: agresivo en Bronze, moderado en Silver, a largo plazo en unidades Gold.

Formatos y capas de tabla

Columnas: Parquet (estándar de facto), ORC.

• Delta Lake - transacciones, 'MERGE', tiempo-viaje, optimización/vacío, Z-order.
• Apache Iceberg - tablas con manifiestos/snapshots, particionamiento oculto, 'MERGE/DELETE/UPDATE', tiempo-viaje.
• Apache Hudi - copy-on-write/merge-on-read, optimización upsert, extracciones incrementales.
• Elija según el ecosistema y los requisitos de upsert/streaming/flexibilidad de la evolución de los circuitos.

Directorio y metástor

El directorio único (Hive Metastore/Unity/Glue/Platform Directory) almacena esquemas, lotes, versiones, derechos.
Requisitos: coherencia transaccional con la capa de tabla, soporte para múltiples motores (Spark, Trino/Presto, Flink, dbt), audit/lineage.

Esquemas y evolución

Contrato Schema: fijar los campos, tipos, semánticas obligatorias; versionar las fuentes ('schema _ version').
Evolución: adición de campos opcionales, prohibición de romper cambios sin migraciones; esquemas automáticos de comprobación en pipelines.
Segmentación PII: campos sensibles: en columnas/tablas individuales con cifrado y derechos individuales.

Partición y salida lay-out de datos

Fecha/hora: clave básica para eventos; dop. campos: 'country', 'product', 'tenant _ id'.
Hive-style путь: `s3://lake/bronze/payments/source=pspA/dt=2025-11-05/hour=13/part-0001. parquet`.
Clustering/Ordenamiento: Z-order/Sort keys por campos filtrados a menudo (player_id, país).
Tamaño del archivo: apunte a 128-1024 MB; evite los «archivos pequeños» (ver más abajo).
Altavoces virtuales (Iceberg/Delta) para particionamiento oculto.

El problema de los archivos pequeños y el compacto

Fuentes de streaming pequeñas chancas → degradación de escáneres y metadatos.
Solución: optimize/compaction periódica (coalesce), programador de problemas de compactación, batch-micro-bundle en ingestion, 'autoOptimize' (si está disponible).
La política merge-on-read vs copy-on-write es el equilibrio entre la latencia de escritura y la velocidad de lectura.

Ingesto: batch, stream, CDC

CDC de OLTP (Debezium/conectores) → Bronze (frescura de minuto).
Stream (Kafka/Flink/Spark Structured Streaming) → Silver/Gold incrementalmente (upsert/merge).
Batch (informes de afiliados/CSV/JSON) - a través de «receptores» con manifiestos, control de tomas por checksum.
Idempotency: llaves (idempotency_key), dedoop por (key, ts), "water signs' (watermarks) para grabaciones posteriores llegadas.

Calidad de datos (DQ) y lineage

Cheques DQ: integridad, singularidad de claves, rangos, integridad de referencia (listas de países/monedas), reglas de negocio (GGR ≥ 0).
Lineage: gráfico de dependencias del informe a la fuente, versión del código del modelo y snapshot de la tabla.
Control de circuitos: pruebas automáticas de back/forward-compat que bloquean los cambios «rompedores».
Auditoría de descargas: quién/cuándo/cuánto, lotes rechazados, retraídas.

Serving y acceso

Motores SQL: Spark/Trino/Presto para ad-hoc y transformaciones; dbt para modelos ELT.
Real-time/near-real-time: Pinot/Druid/ClickHouse como escaparates; Lakehouse es una fuente a través de sink incremental.
Compartiendo datos: sharing de tablas/snapshots a comandos externos sin copias (si es compatible con formato).

Seguridad, PII y multi-tenencia

Encriptación: at-nat (KMS) e in-transit (TLS).
IAM/RBAC/ABAC: funciones a nivel de directorio/tabla/columna/fila (enmascaramiento, políticas dinámicas).
Segmentación por regiones (localización UE/Turquía/LatAm): aislamiento de baquetas y agrupaciones computacionales.
Multi-tenencia: namespace/directorios y prefijos de ruta, filtros por 'tenant _ id', opcionalmente - políticas de row-level.
Auditoría de acceso: registros de lectura/modificación de metadatos, retenciones y registros no modificables.

Administración de costos

Clases de almacenamiento: caliente (a menudo leído) en la clase estándar, el archivo está en clases frías/Glacier con políticas TTL.
Lotes/clústeres reducen los escáneres → menos de $ $.
Vitrinas materializadas para informes caros; caché de resultados BI.
Compacto y «tamaño de archivo correcto» - menos metadatos y I/O.
Cuotas y presupuesto: límites en clústeres/jobs computados, informes de costo por dataset/comando.
Eliminación de basura: 'VACUUM/REWRITE' en formatos de tabla, TTL Bronze.

DR y reproducibilidad

Versificación de tablas (time-travel) y snapshots de catálogo.
Replicación cruzada regional de baquetas y metadatos.
PITR: almacenamiento de registros de transacciones de tablas (Delta/Iceberg/Hudi) y registros de pipelines.
Día de juego: ejercicios regulares de recuperación y cambio de región.

Observabilidad y SLO

Frescura SLO: Bronce ≤ 5 min, Plata ≤ 15-30 min, Oro ≤ 60 min (ejemplo).
Métricas: volumen/cole de archivos, tamaño promedio de archivo de parquet, tiempo de escaneo, fracción de lotes omitidos, frecuencia de compactación, costo/dataset, errores de DQ, datos atrasados.
Alertas: estallido de archivos pequeños, aumento del costo, degradación de p95/p99, interrupción de DQ/circuitos, retraso de los cincos en streaming.

Convenciones de Neuming y Rutas (plantilla)

s3://<lake>/<layer>/<domain>/<dataset>/
source=<sys>/      # для Bronze dt=YYYY-MM-DD/
hour=HH/
country=XX/

Los nombres de los datasets son: 'bets _ raw', 'payments _ cdc', 'players _ silver', 'mart _ gr _ daily'.
Los altavoces metadatos son: 'ingest _ ts',' source ',' schema _ version ',' trace _ id ',' tenant _ id '.

Ejemplos (generalizados)

1) Iceberg: tabla Silver con lote oculto por fecha

sql
CREATE TABLE silver. bets (
bet_id    BIGINT,
player_id   BIGINT,
country    STRING,
stake     DECIMAL(18,2),
win      DECIMAL(18,2),
event_ts   TIMESTAMP,
ingest_ts   TIMESTAMP,
schema_version INT
)
PARTITIONED BY (days(event_ts))
TBLPROPERTIES ('format-version'='2');

2) Delta: upsert incremental de CDC

sql
MERGE INTO silver. players t
USING bronze. players_cdc s
ON t. player_id = s. player_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

3) Política de TTL para Bronze (idea)

bronze/: keep 30 days silver/: keep 365 days (non-PII), 90 days (PII masked)
gold/marts/: keep 2–3 years (aggregated)

Lista de comprobación de implementación

1. Seleccione el formato de tabla (Delta/Iceberg/Hudi) y el directorio; concordar con los motores (Spark/Trino/Flink/dbt).
2. Identifique las capas de medallones, las reglas de TTL y la responsabilidad de los equipos.
3. Fije los contratos schema, el control de evolución, la segmentación PII y el cifrado.
4. Diseñar lay-out: lotes, teclas de grado, tamaño de archivo objetivo; habilite la compacción.
5. Configure ingest (CDC/stream/batch) con idempotencia y dedoop.
6. Habilite DQ/lineage, catálogo de metadatos y auditoría.
7. Identificar SLO frescura/costo, dashboards métricas y alertas.
8. Organizar DR: snapshots/replicación/recuperación + ejercicios regulares.
9. Estandarizar Neuming y paths, metacolonks ('ingest _ ts',' source ',' schema _ version ').
10. Lleve las vitrinas de oro y el serving en tiempo real a los motores OLAP/RT adecuados.

antipatterny

Un «saco» común sin capas y TTL → el caos y la explosión del valor.
Lote sólo en el tiempo sin tener en cuenta el país/producto → escáneres pesados.
Flujos que crean miles de archivos pequeños/hora, sin compactación.
La falta de control de esquemas y DQ → cambios «rompedores» y desconfianza en los informes.
Mezclar PII con vitrinas de oro sin enmascarar/separar derechos.
Un código duro de derechos de acceso a nivel de baquetas en lugar de directorios y directivas de tabla.

Resultados

El moderno Data Lake para iGaming es un Lakehouse con formato de tabla abierta, un único catálogo y un modelo de medallón. La disciplina de circuitos/lotes, compactación contra archivos pequeños, DQ/lineage, seguridad PII e higiene de costos convierte la capa en una base estable: barato para el almacenamiento, rápido para leer, predecible por SLO y listo para DR. Tal base escala para torneos picos y soporta tanto los análisis de batch como los escaparates near-real-time.