Calidad de Datos: Cómo Mejorarla con Técnicas Efectivas

La calidad de datos indica si un conjunto sirve para el uso que se le quiere dar. Un dato puede ser correcto y, aun así, llegar demasiado tarde; puede estar completo pero duplicado; o puede respetar el formato mientras representa una entidad equivocada. Por eso la calidad se define mediante reglas ligadas a procesos y decisiones concretas.

Seis dimensiones que puedes medir

Dimensión	Pregunta	Ejemplo de control
Exactitud	¿El valor representa la realidad?	Contrastar el código postal con una fuente autorizada.
Completitud	¿Faltan campos necesarios?	Porcentaje de pedidos con fecha y cliente.
Validez	¿Cumple tipo, rango y formato?	Importe no negativo y moneda admitida.
Consistencia	¿Coincide entre sistemas y reglas?	Estado “enviado” exige una fecha de envío.
Unicidad	¿Hay registros repetidos?	Una fila activa por identificador de cliente.
Oportunidad	¿Llega a tiempo para decidir?	Inventario actualizado antes de abrir la venta.

No todas las dimensiones tienen el mismo peso. Un catálogo de países tolera una actualización menos frecuente que un sistema antifraude. La definición debe incluir propietario, umbral, ventana temporal y acción cuando el control falla.

Empieza por el uso, no por la herramienta

Antes de escribir reglas, identifica qué decisión depende de los datos. Para un informe de ingresos, los campos críticos pueden ser pedido, fecha, estado, importe y moneda. Para una campaña, consentimiento y canal permitido pueden ser más importantes que completar un segundo apellido.

Clasifica cada elemento como crítico, importante o informativo. Así evitas gastar el mismo esfuerzo en columnas que no afectan el resultado.

Perfilado inicial

El perfilado describe el estado real antes de imponer expectativas. Calcula nulos, cardinalidad, distribuciones, mínimos, máximos, patrones, duplicados y cambios respecto al periodo anterior.

SELECT
  COUNT(*) AS filas,
  SUM(CASE WHEN cliente_id IS NULL THEN 1 ELSE 0 END) AS sin_cliente,
  COUNT(DISTINCT pedido_id) AS pedidos_unicos,
  MIN(fecha_pedido) AS primera_fecha,
  MAX(fecha_pedido) AS ultima_fecha
FROM pedidos;

Un perfil no decide si el dato es bueno. Revela anomalías que después deben convertirse en reglas con contexto.

Reglas ejecutables

Una regla útil tiene un nombre, una consulta o expresión, un umbral y una respuesta. “La tabla debe estar bien” no es verificable. “Al menos el 99,5 % de pedidos confirmados debe tener moneda admitida” sí lo es.

SELECT COUNT(*) AS errores
FROM pedidos
WHERE estado = 'confirmado'
  AND (moneda IS NULL OR moneda NOT IN ('EUR', 'USD', 'GBP'));

Decide también si un fallo bloquea la carga, pone registros en cuarentena o solo genera una alerta. Bloquear todo por una columna informativa puede ser tan dañino como ignorar un error crítico.

Controles en cada etapa

1. Origen: valida contratos, tipos y campos obligatorios.
2. Ingesta: registra cantidad, fecha, checksum o identificador de lote.
3. Transformación: prueba relaciones, duplicados y reglas de negocio.
4. Publicación: comprueba frescura, reconciliación y acceso.
5. Consumo: monitorea si un cambio altera informes o modelos.

Contratos de datos y cambios de esquema

Un contrato documenta qué publica un productor: columnas, tipos, semántica, periodicidad y compatibilidad. No impide todos los cambios, pero obliga a anunciarlos y probarlos. Un campo que pasa de entero a texto o cambia de zona horaria debe detectarse antes de llegar a un dashboard.

Versiona los contratos junto al código y ejecuta pruebas en integración continua. Para flujos entre equipos, define un periodo de deprecación en lugar de retirar columnas sin aviso.

Observabilidad y respuesta

Un panel de calidad debe mostrar tendencia, no solo un semáforo. Registra resultado, volumen afectado, primera aparición, propietario y tiempo de resolución. Cuando una regla falla, conserva ejemplos mínimos que permitan depurar sin exponer datos personales innecesarios.

La alerta debe llegar al equipo que puede actuar. Enviar cientos de avisos sin prioridad produce fatiga y termina ocultando incidentes reales.

Ejemplo de plan para una tabla de clientes

• Identidad: cliente_id no nulo y único.
• Contacto: correo válido solo cuando el canal requiere email.
• Consentimiento: valor, fuente y fecha registrados.
• Frescura: actualización dentro del acuerdo definido.
• Reconciliación: altas y bajas cuadran con el sistema origen.
• Privacidad: acceso limitado y retención aplicada.

Qué no arregla la calidad de datos

Las reglas no corrigen una definición de negocio ambigua. Tampoco sustituyen la seguridad, el consentimiento o el análisis de sesgo. Un dataset puede pasar todas las pruebas técnicas y seguir siendo inadecuado para entrenar un modelo si no representa a la población objetivo.

Para implementar el proceso, combina esta guía con las técnicas de limpieza de datos y con un registro de linaje. Herramientas como Great Expectations permiten convertir expectativas en validaciones, pero la definición de cada regla sigue siendo responsabilidad del negocio y del equipo de datos.

Preguntas frecuentes

¿Cuál es una puntuación aceptable?

No existe un porcentaje universal. El umbral depende del impacto, del campo y de la decisión que utiliza el dato.

¿Se deben eliminar siempre los duplicados?

No. Dos eventos iguales pueden ser observaciones legítimas. Primero define la entidad, la clave y la ventana que convierte dos filas en duplicado.

¿Quién es responsable de la calidad?

El productor conoce el origen, el equipo de datos implementa controles y el consumidor define el uso. Hace falta un propietario capaz de decidir prioridades.