Control de calidad de datos

1) Nombramiento y principios

Por qué: informes fiables (GGR/impuestos), modelos antifraude y RG, descargas de cumplimiento, productos y personalización.

• Schema-first & Contracts: todas las fuentes están obligadas a publicar los datos del contrato.
• Código DQ: reglas en el repositorio, versiones, pruebas y rugidos.
• Observabilidad por defecto: métricas/lógica/línea.
• Privacidad por diseño: mínimo PII, enmascaramiento y RLS/CLS.
• Coste-aware: priorización de reglas críticas, muestras inteligentes.

2) Taxonomía de las mediciones de calidad

Completeness (Plenitud): proporción de campos/filas obligatorios.
Validity (Admisibilidad): corresponde a tipos/rangos/referencias.
Uniqueness (Unicidad): sin duplicados de claves/eventos.
Consistencia: integridad referencial, invariantes empresariales.
Accuracy (Precisión): aproximación a la fuente «verdadera» (conciliaciones resumidas).
Timeliness/Freshness (Oportunidad): retraso del material.
Integración de líneas: guardar el origen/versiones de las transformaciones.

Para cada dominio se definen los KPI de calidad y criticidad (crítico/mayor/menor).

3) Contratos y esquemas (fuente de la verdad)

Contratos de datos: JSON Schema/Avro/OpenAPI/AsyncAPI, alojados en el Registro.
Estabilidad: cambios compatibles con backward - agregar nullable; breaking - nueva versión + grabación doble.
Trazabilidad: en eventos - 'event _ id', 'trace _ id', 'schema _ version', 'source'.

4) DQ-como-código: estructura de artefactos

/dq/
rules/
silver. payments. yaml gold. ggr_daily. yaml checks/
sql/
python/
policies/
severities. yaml notifications/
routes. yaml

Reglas: YAML/SQL declarativa;

Seriedad: mapping → alert-links/niveles de escalamiento;

CI: linternas de circuito, pruebas de compatibilidad, "dry-run'/simulador.

5) Ejemplos de reglas (YAML)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive severity: critical type: range column: amount min: 0. 01
- name: currency_in_whitelist severity: major type: in_set column: currency set: [EUR, USD, GBP, TRY, BRL]
- name: unique_tx severity: critical type: unique columns: [transaction_id]
- name: fk_user_exists severity: critical type: foreign_key column: user_pseudo_id ref_table: dim. users ref_column: user_pseudo_id
- name: ts_monotonicity severity: minor type: temporal expression: "ts between date_sub(now(), interval 90 day) and now()"

6) Pruebas SQL (muestras)

Singularidad de las claves

sql
SELECT transaction_id, COUNT() AS c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

Completar campos obligatorios

sql
SELECT COUNT() AS nulls
FROM silver. payments
WHERE amount IS NULL OR currency IS NULL OR ts IS NULL;

Referencias/consistencia

sql
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON p. currency = r. code
WHERE r. code IS NULL;

7) Streaming DQ (tiempo real)

Validación Ingest: validación schema, size-limits, tipos y enum's.
Cheques on-stream: dedoop '(event_id, source)', lateness allowed, validez de monedas/sumas.
Límites: errores críticos → alerta DLQ +; no crítico → tegiar, sino saltarse (con la bandera 'dq _ flag').
Métricas: completeness/lag/dup-rate por lotes.

8) Trabajar con errores y excepciones

DLQ/Quarantine: los registros «enfermos» se mantienen, disponibles para corrección.
Registros de excepción: tarjeta de excepción (owner, fecha límite, causa, área).
Auto-fallback: utilizando el último snapshot de escaparate correcto.
Cierre SLA: crítico - ≤ 24-48 h; major - ≤ 5 esclavos. días.

9) Alineación con privacidad y cumplimiento

Minimización PII: no verifique los PII «crudos» en capas analíticas; aplique alias.
RLS/CLS: las comprobaciones se realizan teniendo en cuenta el enmascaramiento de los campos.
Regionalización: las reglas tienen en cuenta la 'jurisdiction' (EEA/UK/BR).
Legal Hold: prohibición de regrabar archivos como parte de la retención.

10) Observabilidad, SLI/SLO y alertas

• Freshness p95 (Plata): ≤ 15 min.
• Completeness (critical types): ≥ 99. 5%.
• Validity (schema): ≥ 99. 9%.
• Duplicate rate: ≤ 0. 1%.
• DQ incident MTTR: ≤ 24–48 ч.

Alertas: enrutamiento por gravedad (pager para critical), suavizado (dedoop alert), «mantenimiento de windows».

11) Dashboards (conjunto mínimo)

Tarjeta térmica Freshness/Completeness por dominio y mercado.
La N superior de las tablas por la tasa incidente y por el coste de las correcciones.
Embudo DQ: ingest → silver → gold (pérdidas/correcciones).
Tarjeta de linaje para informes críticos (regulador/GGR/RG/AML).
Mapa de esquemas y clientes «obsoletos» (versiones SDK/esquemas).

12) Procesos y RACI

R (Responsable): Ingeniería de datos (reglas por tabla), Owners de dominio (semántica).
A (Accountable): Head of Data/CDO.
C (Consultado): Compliance/Legal/DPO, Arquitectura, SRE.
I (Informed): BI/Продукт/Маркетинг/Финансы/Операции.

Ciclo de vida de la regla: sugerencia → rugido → «lanzamiento oscuro» → inclusión → monitoreo → retrospectiva.

13) Conciliación y precisión (Accuracy)

Importes de comprobación/transacciones: conjunto con OLTP/proveedores (PSP/KYC).
Comparaciones de dos circuitos: pipeline independiente para validación selectiva.
Tolerancias: umbrales porcentuales por métricas (por ejemplo, divergencia GGR ≤ 0. 2%).
Actos diarios: informes de las soldaduras para la auditoría.

14) Costo y prioridad

Reglas críticas ejecutar más a menudo (streaming/reloj), menor - diario.
Utilice muestreos y comprobaciones materializadas para tablas pesadas.
Realice un seguimiento del costo/query y del costo/GB, aplique la clusterización/indexación.
Asigne un presupuesto a DQ en la sección de comandos (chargeback).

15) Plantillas para escaparates de oro (ejemplo del GGR Daily)

yaml table: gold. ggr_daily owner: fin-analytics slo:
ready_by_local_time: "06:00"
rules:
- name: ggr_not_negative severity: critical type: range column: ggr min: 0. 0
- name: market_known severity: major type: in_set column: market set_ref: ref. markets
- name: fx_source_present severity: major type: not_null column: fx_source
- name: completeness_by_market severity: critical type: completeness partition_keys: [event_date, market]
expected_rows_expression: "ref. expected_activity(event_date, market)"

16) Incidentes de calidad: gestión y comunicación

Ticketing: creación automática de tareas con muestreos y métricas adjuntos.
Patrones de Comm: notificar a los propietarios de productos/reguladores cuando están afectados.
Post-mortem: causa raíz (schema drift, upstream bug, carga), acciones CAPA, control de «retorno de regresiones».

17) Hoja de ruta para la aplicación

1. Catálogo de tablas críticas (Payments, Gameplay, GGR, Compliance).

2. Reglas YAML para 10-15 comprobaciones clave + validación CI.

3. Dashboard Freshness/Completeness y alertas para critical.

4. Correcciones DLQ/Quarantine + runbook.

• Extensión de reglas (FK/accuracy), simulador "dry-run', inclusiones A/B.
• Integración con lineage, acuerdos de excepción y SLA.
• Streaming DQ en ingest para fuentes «ruidosas».

• Autogeneración de documentación de reglas, métricas de valor.
• «Contornos de control» (reconciliación independiente), retrospectivas semanales.
• Rule-as-Code plataformas SDK, el registro de comprobaciones de dominio estándar.

18) Lista de verificación antes de la venta

• Contratos y esquemas en el Registro, las pruebas de compatibilidad pasan.
• Las reglas YAML se tornan, se asignan severidades/escaladas.
• Los dashboards y alertas están activos; Los SLO están definidos y acordados.
• DLQ/Quarantine está disponible, runbooks están documentados.
• Los procedimientos de exenciones/actos de verificacion se acuerdan con Legal/Compliance.
• Mediciones del costo de las inspecciones y límites para solicitudes pesadas.

19) Errores frecuentes y cómo evitarlos

Datos crudos sin contratos: ingrese schema-first y consumer-tests.
Verificaciones «manuales»: traduzca en código DQ y CI.
Sin priorización: comparta critical/major/minor y los canales de alertas.
Falta DLQ: no hay nada que funcione con errores: agregue la cuarentena.
Ignorar el costo: perfilar las consultas, utilizar la materialización.
No hay post mortems: los errores se repiten - introduzca CAPA y control de regresiones.

20) Resultado

El sistema de control de calidad de datos no es un conjunto de inspecciones dispares, sino un programa administrado: contratos y esquemas, código DQ-as-code, observabilidad y SLO, disciplina de incidentes y conversiones. Siguiendo este artículo, obtendrá datos reproducibles, verificables y rentables suficientes para informes regulatorios, soluciones de productos y detectores de riesgo en tiempo real.