Data Quality

¿Qué es?

Data quality (calidad del dato) es el conjunto de propiedades que determinan si un dato es apto para el uso que se le quiere dar. Un dato de alta calidad es preciso, completo, consistente y está disponible cuando se necesita. Un dato de baja calidad genera decisiones incorrectas, pipelines que fallan y pérdida de confianza en los sistemas analíticos.

La clave de la definición está en “apto para el uso”: no existe una calidad absoluta. Los mismos datos pueden ser suficientemente buenos para un reporte semanal y totalmente inadecuados para entrenar un modelo de machine learning.

Las 6 dimensiones estándar de calidad

Exactitud (Accuracy): el dato refleja la realidad que pretende representar. Un nombre de cliente mal escrito o un precio con un cero de más son problemas de exactitud.

Completitud (Completeness): ausencia de valores nulos o vacíos donde se espera información. Un campo de email vacío en el 30 % de los registros es un problema de completitud.

Consistencia (Consistency): el mismo dato tiene el mismo valor en sistemas distintos. Si la base de datos de ventas dice que el cliente X compró 1.000€ y el sistema contable registra 900€, hay inconsistencia.

Puntualidad (Timeliness): los datos están disponibles cuando se necesitan y reflejan el estado actual del negocio. Datos con 3 días de retraso en un dashboard operacional son un problema de puntualidad.

Unicidad (Uniqueness): ausencia de duplicados. El mismo cliente con dos IDs distintos en la misma tabla es un problema de unicidad.

Validez (Validity): el dato cumple el formato y rango esperados. Una fecha con valor 2099-99-99 o un código postal de 8 dígitos en España son problemas de validez.

Por qué los pipelines de datos amplifican los problemas de calidad

En una arquitectura de datos moderna, los datos pasan por múltiples capas: fuente → ingestión → staging → transformación → marts → BI. Cada capa puede introducir o propagar errores. Sin controles de calidad explícitos:

• Un nulo inesperado en la fuente puede llegar sin aviso hasta el dashboard de dirección.
• Una transformación incorrecta en dbt puede silenciosamente duplicar filas.
• Un cambio de esquema en la fuente puede romper el pipeline sin que nadie lo detecte.

Por eso los equipos maduros instalan controles de calidad en cada capa, no solo al final.

Cómo se mide y controla

Tests en dbt: para pipelines ELT modernos, dbt permite definir tests como not_null, unique, accepted_values y relationships directamente sobre los modelos SQL.

Great Expectations: framework Python open source para definir “expectativas” sobre los datos (rangos, formatos, cardinalidades) que se ejecutan como tests automatizados.

Data contracts: acuerdos formales entre el equipo productor y el consumidor sobre el esquema, tipos y SLA de calidad. Ver data contract.

Observabilidad de datos (data observability): monitorización continua de métricas de calidad en producción. Herramientas como Monte Carlo, Soda o Bigeye detectan anomalías estadísticas antes de que lleguen al usuario.

Catálogos con scoring: plataformas como Alation o Collibra asignan puntuaciones de calidad visibles para los consumidores de datos.

Quién es responsable

La trampa habitual es que “la calidad de los datos es responsabilidad de IT”. En la práctica, la calidad requiere colaboración:

• Equipos fuente (negocio): garantizan que los datos se introducen correctamente en origen.
• Ingeniería de datos: valida en la ingestión y en cada transformación.
• Analytics/BI: detecta anomalías cuando aparecen en los informes.
• Data governance: define estándares y dimensiones de calidad para toda la organización.

El concepto de data ownership (cada dominio tiene un owner responsable de la calidad de sus datos) es clave en arquitecturas data mesh.

Más información

Explora herramientas de gobernanza y catálogos de datos en el directorio de Dataprix.