Un catálogo de datos resuelve el problema de que nadie sabe qué datos existen, qué significan y quién es responsable de ellos. Esta guía explica cuándo es necesario y cómo elegir entre opciones open source y comerciales.
📌 En resumen
Un catálogo de datos resuelve el problema más habitual en empresas con múltiples sistemas: nadie sabe qué datos existen, qué significan realmente ni quién es responsable de ellos. Esta guía explica cuándo lo necesitas, la diferencia entre catálogo y diccionario de datos, las principales opciones de herramientas y cómo implementarlo en fases.
En una empresa con 4 o más sistemas generando datos, la situación habitual es la siguiente: cuando un analista necesita un dato, pregunta a un compañero que sabe en qué tabla está. Cuando el compañero no está disponible, el proceso se detiene. Cuando la definición del dato no es clara, cada departamento usa la suya. Esto no es un problema de herramientas — es un problema de conocimiento no documentado.
El catálogo de datos es la respuesta técnica y organizativa a este problema. Es el lugar donde los datos son encontrables, su significado está documentado y su propietario está identificado. Sin catálogo, el conocimiento sobre los datos vive en la cabeza de las personas que los crearon — y se pierde cuando esas personas se van.
El diccionario de datos es un inventario técnico: lista de tablas, columnas, tipos de datos y restricciones. Es útil para los ingenieros de datos, pero no para los analistas de negocio que necesitan saber qué significa 'cliente_estado = 2' o cómo se calcula el margen bruto en el ERP.
El catálogo de datos añade cuatro capas sobre el diccionario: el glosario de negocio (significados en lenguaje de negocio), el linaje (de dónde viene cada dato y a dónde va), la propiedad (quién es el Data Owner), y las métricas de calidad (si el dato es fiable). Es el puente entre el mundo técnico y el negocio.
| Herramienta | Tipo | Ideal para | Coste orientativo |
|---|---|---|---|
| DataHub (Acryl) | Open source | Equipos técnicos, stacks modernos (dbt, Airflow, Spark) | Gratuito (hosting propio) / SaaS desde ~30k€/año |
| Apache Atlas | Open source | Ecosistemas Hadoop/Hive maduros | Gratuito (requiere operación) |
| Amundsen (Lyft) | Open source | Empresas con Python y cultura data-driven | Gratuito (hosting propio) |
| Collibra | Comercial | Grandes empresas, perfiles de negocio, compliance | Desde ~80.000 €/año |
| Alation | Comercial | Empresas con analistas SQL, colaboración activa | Desde ~50.000 €/año |
| Microsoft Purview | Comercial | Ecosistemas Azure, integración con Power BI | Desde ~15.000 €/año (según datos escaneados) |
Conectar el catálogo a las fuentes de datos principales (data warehouse, dbt, herramientas de BI) para extraer automáticamente los metadatos técnicos: tablas, columnas, tipos de datos, estadísticas de uso. Esto requiere trabajo de ingeniería de datos, no de negocio.
Trabajar con los Data Owners de cada dominio para documentar las definiciones de negocio de los datos más usados. Priorizar los términos que más conflictos generan: ¿qué es un cliente activo? ¿cómo se calcula el ticket medio? Cada definición debe tener su autor, su fecha de aprobación y estar vinculada a los campos técnicos que la implementan.
Conectar el linaje automático desde las herramientas de transformación (dbt exporta linaje nativo al catálogo) y añadir métricas de calidad visibles desde el catálogo. Cuando un analista abre una tabla, debe poder ver su estado de calidad actual y la ruta que ha seguido el dato desde la fuente.
💡 Consejo
El mayor error en implementaciones de catálogo es centrarse en la tecnología antes que en los usuarios. Pregunta a 5 analistas cuáles son las 3 preguntas que más les cuesta responder sobre los datos. Las respuestas definen tu catálogo mínimo viable — no el inventario completo de tablas.
Siguiente paso recomendado
Implementamos catálogo de datos con linaje, glosario de negocio y ownership para que vuestros datos sean encontrables y fiables.
Sin compromiso · Respuesta en < 24h
Autor
Fundador y Consultor de Datos e IA
David Aldomar es fundador y consultor principal de MERIDIAN Data & IA, consultora especializada en ayudar a pymes y empresas medianas en España a tomar mejores decisiones con sus datos. Su trabajo se centra en cuatro áreas: diseño e implantación de plataformas de datos (data warehouses, pipelines ETL con dbt, integración de ERPs y CRMs), reporting y dashboards ejecutivos en Power BI, automatización de procesos de negocio con herramientas como n8n, y desarrollo de soluciones de inteligencia artificial aplicada — desde modelos de forecasting de demanda hasta copilots internos basados en RAG con LangChain y FastAPI. Ha liderado proyectos en sectores como logística y transporte, retail y distribución, servicios financieros, manufacturing y construcción, siempre con un enfoque pragmático: diagnóstico corto, entregables concretos y transferencia de conocimiento al equipo del cliente para que sea autónomo desde el primer día. Antes de fundar MERIDIAN, acumuló experiencia en consultoría de datos y transformación digital trabajando con stacks variados — desde entornos Microsoft (SQL Server, Power BI, Azure) hasta ecosistemas open source (Python, dbt, BigQuery). Su filosofía es que un buen proyecto de datos no se mide por la tecnología que usa, sino por las decisiones de negocio que permite tomar. Escribe regularmente en el blog de MERIDIAN sobre reporting, gobierno del dato, automatización e IA aplicada, con guías prácticas orientadas a responsables de negocio y equipos técnicos de empresas que quieren sacar partido real a sus datos sin depender de grandes consultoras.
Fuentes
Servicio de implantación de catálogo de datos, glosario y gobierno del dato.
Qué es el gobierno del dato y por qué el catálogo es solo una parte.
Data warehouse y pipelines donde el catálogo cobra sentido como capa de gobernanza.
Cómo definir las reglas de calidad que el catálogo debe documentar.
Seguir leyendo
10 min lectura
12 min lectura
9 min lectura
18 min lectura
11 min lectura
Última revisión: