Catálogo de datos, lineage y calidad: los 3 pilares del gobierno de datos

En el artículo anterior explicamos qué es el gobierno de datos sin jerga: ponerse de acuerdo sobre quién responde por cada dato, qué significa, qué tan confiable es y quién puede usarlo. La pregunta natural que sigue es: ¿y eso cómo se aterriza en el día a día? En nuestra experiencia —más de 15 años de trabajo en Telecom y Fintech en Latinoamérica— todo programa de gobierno que funciona se apoya en tres capacidades concretas: el catálogo de datos, el lineage y la calidad de datos. Vamos una por una.

Pilar 1 — El catálogo de datos: un buscador para tus datos

Piensa en cuántas veces has visto esta conversación en el chat interno de una empresa: «¿alguien sabe dónde está la tabla buena de churn?». Tres personas responden con tres tablas distintas. Una está deprecada, otra es el experimento de alguien que ya se fue, y la tercera… quizá sea la buena. Nadie está seguro.

Un catálogo de datos resuelve exactamente eso: es el inventario buscable de todos los activos de datos de la organización —tablas, dashboards, pipelines, modelos— con su contexto: qué contiene cada uno, quién es su dueño, qué significan sus columnas, qué tan actualizado está y qué etiquetas lleva (por ejemplo, si contiene datos personales).

$ search "churn"

1. analytics.fact_churn_monthly      [certificada]
   owner: Equipo Analytics | actualizada: hoy
   "Churn mensual oficial. Fuente del dashboard ejecutivo."

2. sandbox.churn_test_v2_OLD         [deprecada]
   owner: (sin asignar) | actualizada: hace 14 meses

La diferencia entre adivinar y saber: el catálogo te dice cuál es la tabla oficial, de quién es y si está viva.

La analogía que más usamos: el catálogo es el Google interno de tus datos. Sin él, encontrar información depende de a quién conozcas y de cuánto tiempo lleves en la empresa — conocimiento tribal puro. Con él, cualquier persona nueva encuentra en minutos lo que antes tomaba semanas de preguntar por los pasillos.

Pilar 2 — Lineage: el mapa de dependencias

El lineage (linaje de datos) responde dos preguntas: ¿de dónde viene este dato? y ¿qué se rompe si lo toco? Es el mapa que muestra cómo fluyen los datos desde los sistemas fuente hasta el dashboard final, pasando por cada transformación intermedia.

Volvamos al ejemplo del artículo anterior: el reporte que amanece roto un lunes. La historia completa suele ser así: el viernes, el equipo del CRM renombró la columna customer_type a segment. Cambio menor, pensaron. Pero esa columna alimentaba una tabla de staging, que alimentaba la tabla maestra de clientes, que alimentaba el dashboard ejecutivo:

crm.customers (columna renombrada el viernes 18:40)
  └─> staging.stg_customers      [x] pipeline fallido
       └─> marts.dim_customers   [x] sin actualizar
            └─> "Executive KPIs" [x] dashboard vacío el lunes

Lineage: la cadena de dependencias que nadie ve… hasta que se rompe.

Con lineage, esta historia cambia en dos momentos. Antes del cambio: el equipo del CRM consulta el mapa, ve que 3 pipelines y 12 dashboards dependen de esa columna, y avisa (o decide no renombrarla). Después de una falla: en lugar de tres horas de arqueología de SQL para encontrar la causa raíz, el mapa muestra en segundos dónde empezó el problema y qué quedó afectado río abajo.

El lineage también tiene un uso menos dramático y más valioso: la confianza. Cuando un director pregunta «¿de dónde sale este número?», poder mostrar el camino completo —de qué sistema viene, qué transformaciones sufrió— convierte una discusión de fe en una conversación de ingeniería.

Pilar 3 — Calidad de datos: tests para tus datos

En ingeniería de software nadie despliega código importante sin tests. En datos, curiosamente, durante años fue normal lo contrario: pipelines que mueven millones de filas a producción sin una sola validación. La calidad de datos aplica la misma disciplina de testing al dato mismo.

Las dimensiones clásicas, en lenguaje llano:

• Frescura (freshness). ¿Llegaron los datos de hoy? Una tabla perfecta pero con datos de hace tres días puede ser peor que ninguna, porque nadie nota que está vieja.
• Completitud. ¿Están todas las filas y valores que deberían estar? Si customer_id tiene 4% de nulos desde ayer, algo se rompió río arriba.
• Unicidad. ¿Hay duplicados? El clásico: un backfill mal hecho duplica filas y, de pronto, los ingresos del mes «crecieron» 30%. La celebración dura hasta que alguien revisa.
• Validez. ¿Los valores tienen sentido? Fechas de nacimiento en el futuro, montos negativos donde no aplican, códigos de país que no existen.

El punto clave es que estas validaciones corren automáticamente y de forma continua, como los tests de software en un pipeline de integración continua. El objetivo es que el equipo de datos se entere de los problemas antes que los usuarios del dashboard — y no al revés, que es lo que ocurre cuando no existe esta disciplina. Si quieres ver cómo se crea una de estas reglas en la práctica, lo mostramos con capturas reales en cómo poner una regla de calidad en OpenMetadata.

Los tres pilares se refuerzan entre sí

Por separado, cada pilar ayuda. Juntos, cambian la naturaleza del sistema:

• El catálogo te dice qué existe, qué significa y de quién es.
• El lineage te dice de dónde viene y qué impacta.
• La calidad te dice si puedes confiar en ello ahora mismo.

La combinación es lo poderoso: encuentras la tabla en el catálogo, ves en su lineage que alimenta el dashboard ejecutivo y compruebas que sus tests de calidad están en verde — todo en el mismo lugar. Esa combinación tiene un nombre: confianza. Y cuando los resultados de los tests y los avisos de cambios fluyen hacia los dueños que definiste en el catálogo, el círculo se cierra: los problemas se detectan, se enrutan y se resuelven sin heroísmos.

Catálogo, lineage y calidad no son tres proyectos separados: son tres caras de la misma pregunta — ¿puedo confiar en este dato?

Durante años, montar estos tres pilares exigía tres herramientas distintas (o construirlas en casa, como hicieron las grandes tecnológicas). Hoy existen plataformas open source que los unifican en un solo lugar; de la más relevante —OpenMetadata— hablamos en el próximo artículo de esta serie.

¿Quieres saber qué tan sólidos son estos tres pilares en tu organización? Empieza por una evaluación de madurez de datos o conoce cómo trabajamos la implementación de OpenMetadata.