Validación de datos

1) Por qué lo necesita la plataforma iGaming

Confianza en los informes y KPI: GGR/NET, conversiones, retención, señales RG.
Fiabilidad ML/puntuación: fijos correctos para antifraude/recomendaciones/RG.
Operaciones en tiempo real: alertas a la deriva/pérdida de eventos antes de que los pagos/UX se vean afectados.
Cumplimiento: ausencia de PII/secretos donde no deberían estar; trazabilidad probada.

2) Dónde validar: niveles de control

1. Higo (batch/stream): esquema, tipos, campos obligatorios, idempotency/dedoup.
2. Procesamiento en streaming: ventanas/marcas de agua, orden, pases/retrasos, exactly-once.
3. ETL/ELT y transformaciones: referencias/joynes, agregados, balances de negocios.
4. DWH/vitrinas (Oro): consistencia entre tablas, frescura, singularidad de claves.
5. Feature Store/online: gamas de fichas, consistencia de offlayn↔onlayn.
6. BI/API: conteos y filtros, SLAs en latency/freshness, k-anonimato.

3) Tipos de comprobación (catálogo)

Diagramas: tipo/nullable/enum/regex/JSON-shape; cambios incompatibles → paradas.
Dominios: cantidades de ≥0, moneda ∈ {EUR, USD, TRY, BRL}, tasa ≤ límite, strana∈litsenzii.
Identidad/claves: la clave principal es única, la clave exterior no es «colgante».
Calidad de los campos: relleno, longitudes, formato (IBAN, BIN, token de correo electrónico).
Estadísticas/líneas de base: frecuencias, distribuciones, corredores cuantiles.
Anomalías: saltos bruscos de volumen/fracción, ceros/duplicados, schema drift.
Frescura: max (ts) no mayor de X; doug ingest→gold ≤ T.
Consistencia: suma por pieza = resumen; multi-table reconciliation.
Privacidad/seguridad: Zero-PII fuera de las zonas permitidas; tokenización/máscaras.
Regulación: los campos RG/AML están presentes y son plausibles (fechas, signos).

4) Contratos de datos (contratos de datos)

El contrato fija el esquema + reglas de calidad + SLO entre la fuente y los consumidores.

yaml dataset: payments_ingest_v2 owner: team-payments schema:
id: {type: string, pattern: "^[a-f0-9]{32}$", unique: true}
ts: {type: timestamp, timezone: "UTC", nullable: false}
amount: {type: decimal(18,2), min: 0. 00}
currency: {type: string, enum: ["EUR","USD","TRY","BRL"]}
psp: {type: string, required: true}
quality:
freshness_max: "PT5M"
completeness_min: 0. 995 duplicate_rate_max: 0. 001 pii_allowed: false slo:
p95_ingest_latency_ms: 30000 success_rate: 0. 995

Cambios de contrato - a través de semver y migraciones: 'MAJOR' rompe, 'MINOR' añade campo, 'PATCH' corrige la descripción.

5) «Expectativas» (proyecciones) y políticas

Expectativas: verificaciones declarativas ejecutadas en pipelines (batch/stream).

yaml expectations:
- name: unique_primary_key check: "unique(id)"
severity: "error"
- name: amount_non_negative check: "amount >= 0"
severity: "error"
- name: currency_enum check: "currency in ['EUR','USD','TRY','BRL']"
severity: "error"
- name: ts_fresh_enough check: "now() - max(ts) <= interval '5 minutes'"
severity: "warn"
- name: pii_absent check: "no_plain_pii(columns: ['email','card','iban'])"
severity: "error"

• 'error' → cuarentena lote/batch, alerta + ticket; unidad downstream.
• 'warn' → pasa, pero crea una tarea a analizar; marca de calidad.
• 'info' → sólo monitoreo.

6) Streaming: características específicas de las inspecciones

Watermarks/late data: permitimos que el '≤ 120s' llegue tarde, de lo contrario, la cuarentena; compensamos con ventanas finales.
Idempotency: clave de evento + hash payload → dedoup en el corredor/en el flujo.
Exactly-once: sing transaccional (+ sinks idempotentes) para flujos críticos (pagos/rondas).
Contadores de volumen: «esperado» vs «recibido» por la ventana; divergencia → alerta.

scala val deduped = stream
.keyBy(_.id)
.process(new DeduplicateWithin(Time. minutes(10)))

val validated = deduped
.filter(_.amount >= 0)
.filter(_.currency in Set("EUR","USD","TRY","BRL"))

emitToQuarantineIfLate(validated, allowedLateness = 120. seconds)

7) DWH/SQL: invariantes y conciliaciones

sql
-- uniqueness
SELECT id, COUNT() c FROM gold. payments GROUP BY 1 HAVING c>1;

-- freshness
SELECT NOW() - MAX(ts) AS lag FROM gold. payments;

-- reconciliation of totals
SELECT
SUM(amount) AS by_rows,
(SELECT total_amount FROM gold. payments_summary WHERE date=CURRENT_DATE) AS by_summary
FROM gold. payments
WHERE date = CURRENT_DATE;

Match con vitrinas: cotidianas 'detail → summary', informes de discrepancias, ticket automático.

8) Privacidad y seguridad

Edición PII predeterminada: máscaras/tokens en el inicio de sesión; prohibimos los e-mail/tarjetas/teléfonos «crudos» en los logs.
Política de permisos: tablas con PII - capa/directorio independiente, acceso por roles (RBAC/ABAC).
Informes de anonimato K: mínimo N líneas en el corte.
Detectores Leak: verificaciones regulares de patrones PII, «secretos» (claves/tokens).
Jurisdicciones: aislamiento geo/tenant (país/marca/licencia), claves separadas.

9) Métricas de calidad y SLO

• Freshness - rezago max (ts).
• Completeness: proporción de registros no vacíos/esperados.
• Uniqueness - llaves duplicadas.
• Consistencia - invariantes y balances (intertable).
• Accuracy: validación con un origen/reglas de dominio externo.
• Validity - conformidad con los tipos/enum/regex.

• `Freshness payments_gold ≤ 5 мин` (p95).
• `Completeness game_rounds ≥ 99. 7 %/день `.
• `Duplicate_rate ≤ 0. 1‰`.
• `PII_leak = 0`.

10) Alertas, tickets y runbook

Routing: Slack/PagerDuty → propietario del dominio; aplicamos automáticamente samples y diff.
Agrupación: un incidente por conjunto «labels: dataset = payments, brand = TR».

1. Compruebe el log ingest y la cola del corredor.

2. Comparar «esperado vs recibido» por PSP.

3. Habilitar Retrai/Cambiar ruta PSP.

4. Anotar la causa; restart de los beaks; Llevar a cabo un post mortem.

11) Proceso de versionamiento, pruebas y waiver

Semver reglas de calidad: 'quality @ MAJOR. MINOR. PATCH`.
Pruebas unitarias de transformación (SQL/DBT/python) y pruebas contractuales para fuentes.
Conjuntos GOLDEN: casos conocidos de discrepancias/fugas son obligatorios en la regresión.
Waiver (excepción): permiso a corto plazo para violar la regla (descripción, propietario, plazo, medidas compensatorias).

12) Catálogos/artefactos (plantillas terminadas)

12. 1 Pasaporte Dataset

yaml dataset: gold. game_rounds owner: team-games steward: data-governance contracts: ["games_rounds_v3"]
quality_slo:
freshness_p95: "PT10M"
completeness_min: 0. 997 uniqueness_max_dup: 0. 0005 alerts:
channels: ["#dq-incidents","#games-ops"]
severity_map: {error: "P1", warn: "P2"}

12. 2 Política de cuarentena

yaml quarantine:
storage: "s3://quarantine/payments/"
retention: "P30D"
access: ["team-payments","data-governance"]
auto_reprocess:
cron: "/15  "
max_attempts: 3

12. 3 Expectation для Feature Store

yaml featureset: fs_payments_online_v1 checks:
- name: feature_freshness check: "now() - max(feature_ts) <= interval '60 seconds'"
severity: "error"
- name: range_amount_avg check: "amount_avg in [0, 2000]"
severity: "warn"
- name: enum_device check: "device in ['ios','android','web']"
severity: "error"

13) Especificidad de iGaming: casos terminados

Pagos/PSP: conciliar la cantidad de depósitos/retiros con los informes PSP; estados faltantes → cuarentena de batch; alerta de crecimiento 'decline _ rate'.
Proveedores de juegos: caída 'rounds _ per _ min' vs baseline + schema drift del proveedor → unidad de transformación del proveedor A, banner de estado.
RG/AML: campos obligatorios (límites, autoexclusión, estados KYC); KYC vencidos → la bandera en el bloque de pago, ticket en cumplimiento.
Marketing/CRM: validez de los parámetros de campaña, UTM, dedoup de eventos; k-anonimato en las vitrinas.

14) Hoja de ruta para la aplicación

0-30 días (MVP)

1. Incluir contratos para kits clave: pagos, game_rounds, usuarios, características.
2. Catálogo de espera (10-15 básico) + cuarentena + alertas.
3. Dashboard Freshness/Completeness/Uniqueness; Informe de incidentes.
4. Runbook’и для `Freshness`, `Duplicates`, `Schema drift`.

30-90 días

1. Conciliaciones y balances intertablistas; proceso waiver y reglas semver.
2. Validación por streaming (data late, dedoop, watermarks); Detectores PII.
3. Integración con CI/CD: pruebas de contrato de fuentes y transformaciones.
4. Calidad SLO en los equipos de dominio OKR.

3-6 meses

1. Pistas de umbral AIOps; Localización automática de las causas.
2. Política de calidad de marca cruzada/geo e informes de cumplimiento.
3. Los incidentes P1 post-mortem → la reposición de conjuntos de oro y reglas.
4. Ligamento con alerting de flujos y análisis de anomalías (circuito único).

15) RACI

Data Governance (A/R): normas, contratos, auditoría de reglas.
Domain Owners (R): expectativas de dominio e invariantes.
Plataforma de datos (R): marco de expectativas, cuarentena, alertas, monitoreo.
Seguridad/DPO (A/R): privacidad/PII/k-anonimato, aislamiento geo/tenant.
SRE/Observabilidad (C): enrutamiento de incidentes, SLO/SLI.
Producto/Finanzas (C): balances de negocios, prioridades de incidentes.

16) Anti-patrones

Validación «sólo en DWH» - tarde, caro, doloroso.
No hay cuarentena - «suciedad» va a Oro/ML y rompe la confianza.
Umbrales rígidos sin estacionalidad/horas/mercados → tormenta de alertas.
La ausencia del propietario y las reglas semver → el caos de las excepciones.
Logs con PII y «capturas de pantalla al canal general».
«días sanitarios» únicos en lugar de un circuito permanente.

17) Secciones relacionadas

Prácticas de DataOps, Auditoría de Datos y Versionabilidad, Origen y Ruta de Datos, Alertas de Flujos de Datos, Análisis de Anomalías y Correlaciones, Control de Acceso, Seguridad de Datos y Cifrado, Políticas de Retención de Datos, MLOps: Explotación de Modelos.

La validación no es un filtro al final, sino un contrato de calidad transversal: desde el higo y el stream hasta las vitrinas y el fich online. Las expectativas claras, la cuarentena, las alertas y los SLO convierten los datos en un activo fiable: los informes son correctos, los modelos son sostenibles, los pagos son seguros, el cumplimiento es tranquilo.