Catálogo de Datos (Data Catalog)

Definición completa

Un catálogo de datos (data catalog) es un sistema centralizado que registra y organiza los metadatos sobre todos los activos de datos de una organización — tablas en el warehouse, modelos analíticos, pipelines de datos, reportes, dashboards y fuentes de datos externas. El catálogo no almacena los datos en sí, sino información sobre esos datos: su estructura, su significado de negocio, quién los produce, quién los consume, cuándo se actualizan, cuán confiables son y cómo se relacionan con otros activos.

La función primaria del catálogo es el descubrimiento de datos: cuando un analista necesita entender el comportamiento de retención de los clientes, el catálogo le permite buscar qué tablas contienen datos de suscripciones, qué columnas son relevantes, quién es el propietario de esos datos y si existe documentación sobre cómo se definen los eventos de cancelación. Sin catálogo, esa investigación requiere preguntar a la persona correcta — que puede estar disponible o no — o revisar el código de los pipelines directamente, lo que asume conocimiento técnico que no todos los analistas tienen.

Los catálogos modernos van más allá del inventario pasivo y se convierten en plataformas activas de colaboración sobre datos. Incluyen linaje de datos — visualizaciones de cómo fluyen los datos desde sus fuentes hasta los reportes finales — que permiten responder preguntas como "¿qué reportes se verán afectados si cambio esta tabla?" o "¿de qué tabla de origen proviene este número en el dashboard?". Incluyen también perfil de datos (estadísticas sobre los valores de cada columna: distribución, valores nulos, valores únicos) que permiten evaluar la calidad antes de usar un conjunto de datos. Y permiten que los usuarios añadan comentarios, mencionen a propietarios y documenten casos de uso, convirtiendo el catálogo en una base de conocimiento colectivo sobre los datos de la organización.

La distinción entre metadatos técnicos y metadatos de negocio es fundamental para entender cómo se divide el trabajo de mantenimiento del catálogo. Los metadatos técnicos — esquemas, tipos de datos, frecuencia de actualización, tamaño de las tablas, estadísticas de uso — pueden auto-popularse automáticamente desde el warehouse mediante conectores. Los metadatos de negocio — qué significa realmente la columna "status", por qué existen dos tablas con nombres similares, qué eventos deben incluirse en el cálculo del MRR, cuál es la definición acordada de "cliente activo" — solo puede documentarlos el equipo. La clave para que un catálogo sea sostenible es minimizar la carga manual sobre los metadatos técnicos para que el equipo pueda invertir su atención en los metadatos de negocio, que son los que realmente generan valor.

Cómo implementar un catálogo de datos

La implementación de un catálogo de datos sigue una secuencia en cuatro etapas. El error más común es empezar con la herramienta en lugar de empezar con la estrategia: elegir la tecnología antes de definir qué problemas se quiere resolver y qué activos son prioritarios.

1. 1

   Definir los casos de uso prioritarios

   Antes de elegir herramienta, identifique los tres o cuatro problemas que el catálogo debe resolver. ¿El problema principal es el descubrimiento — los analistas no saben qué datos existen? ¿Es la confianza — no saben si los datos están actualizados? ¿Es el cumplimiento — necesitan saber qué tablas contienen PII para responder solicitudes de eliminación? Cada problema tiene implicaciones diferentes para qué funcionalidades del catálogo son más importantes.

2. 2

   Seleccionar la herramienta adecuada al contexto

   Para empresas en etapas tempranas con presupuesto limitado: OpenMetadata o DataHub (open source, autohospedados). Para equipos que priorizan UX y velocidad de implementación: Castor o Select Star (SaaS con planes accesibles). Para organizaciones con requisitos avanzados de cumplimiento regulatorio: Alation o Collibra. El criterio más importante no es el número de funcionalidades sino la facilidad de adopción: un catálogo que el equipo no usa es peor que no tener catálogo.

3. 3

   Conectar fuentes y auto-poblar metadatos técnicos

   Configure los conectores del catálogo con el warehouse (BigQuery, Snowflake, Redshift), las herramientas de BI (Looker, Metabase, Tableau), y si el equipo usa dbt, integre el repositorio para importar automáticamente las descripciones documentadas en los modelos. La mayoría de los catálogos modernos pueden poblar metadatos técnicos en menos de un día de trabajo. Una vez conectadas las fuentes, el inventario técnico está disponible sin esfuerzo manual adicional.

4. 4

   Documentar metadatos de negocio de forma priorizada

   No intente documentar todo desde el inicio: es una tarea sin fin que genera fatiga y abandono. Identifique los 20 activos de datos más utilizados por el equipo — típicamente las tablas del warehouse que alimentan los reportes operativos principales — y empiece por documentar esos con propietarios asignados, descripciones de columnas críticas y clasificación de sensibilidad. Establezca como política que cualquier tabla nueva que entre en producción debe tener propietario y descripción antes de considerarse lista para uso general.

Ejemplo concreto

Considera el caso de Distribuidora Corferias, una empresa colombiana de distribución de insumos industriales con sede en Bogotá. Con 120 empleados y ventas anuales de aproximadamente COP 28,000 millones, Corferias tiene datos distribuidos en su ERP (SAP B1), su CRM (HubSpot), su plataforma de ecommerce B2B y un warehouse en BigQuery con más de 180 tablas generadas por el equipo de datos en los últimos tres años.

El equipo de datos de Corferias tenía un problema conocido pero no resuelto: existían tres tablas con nombres similares relacionadas con órdenes de compra — orders, purchase_orders y op_historico — y ningún analista nuevo podía determinar sin preguntar cuál de las tres era la fuente autoritativa, cuáles eran equivalentes y cuáles tenían datos de períodos diferentes. El CFO había descubierto que el equipo de finanzas y el equipo de ventas calculaban los ingresos del mes con tablas diferentes y obtenían resultados que diferían hasta en COP 450 millones para el mismo período. El equipo de cumplimiento tampoco podía identificar fácilmente qué tablas contenían datos de personas naturales que requerían protección bajo la Ley 1581.

Corferias implementó OpenMetadata en su infraestructura de Google Cloud, conectado a BigQuery y a los modelos dbt del equipo. En la primera semana, el catálogo auto-pobló metadatos técnicos de las 180 tablas: esquemas, estadísticas de columnas, frecuencia de actualización y linaje desde los pipelines dbt. El equipo de datos dedicó las siguientes dos semanas a documentar los 30 activos más críticos: marcó purchase_orders como la tabla autoritativa para órdenes confirmadas, documentó que orders es una vista intermedia sin persistencia y que op_historico contiene solo datos anteriores a 2022 con un esquema diferente. Etiquetó todas las columnas con datos de persona natural (nombre, NIT de persona natural, email, dirección) con la clasificación "PII — Ley 1581". El resultado: las preguntas sobre qué tabla usar se redujeron drásticamente, el equipo de finanzas y ventas unificaron su definición de ingresos a una diferencia de cero, y la primera auditoría de cumplimiento tomó dos días en lugar de las dos semanas proyectadas inicialmente.

Análisis en profundidad

El catálogo de datos surgió como respuesta a un problema que se agrava con la madurez analítica de la organización: cuanto más datos se generan y más pipelines se construyen, más difícil se vuelve saber qué existe y cómo usarlo correctamente. En las primeras etapas de madurez de datos, cuando el warehouse tiene 20 tablas y el equipo analítico son dos personas que construyeron todo el sistema, el conocimiento sobre los datos existe en la cabeza de quienes los crearon. A medida que el equipo crece, el sistema se complejiza y hay rotación de personal, ese conocimiento tácito se fragmenta y eventualmente se pierde. El catálogo externaliza ese conocimiento en un sistema persistente que no depende de que la persona que construyó una tabla siga en la empresa.

La relación entre el catálogo de datos y la gobernanza de datos es de complementariedad inseparable: el catálogo es el instrumento operativo a través del cual se implementan muchas de las políticas de gobernanza. La clasificación de datos sensibles para controlar el acceso requiere que el catálogo registre qué tablas y columnas contienen PII. El linaje de datos que permite responder solicitudes de eliminación bajo la LFPDPPP o la Ley 1581 requiere que el catálogo registre cómo fluyen los datos desde la captura hasta el almacenamiento. La asignación de propietarios de datos por dominio — componente central de cualquier modelo de gobernanza — se implementa y hace visible a través del catálogo. Intentar implementar gobernanza sin catálogo es como intentar administrar un inventario físico sin sistema de registro: las políticas existen en papel pero no tienen forma de aplicarse operativamente.

El linaje de datos como funcionalidad del catálogo merece análisis propio porque tiene implicaciones que van más allá del descubrimiento. El linaje a nivel de tabla — "esta tabla marts.revenue se alimenta de staging.orders y staging.invoices" — es útil para análisis de impacto: si necesito cambiar staging.orders, ¿qué tablas aguas abajo se verán afectadas? El linaje a nivel de columna — "la columna net_revenue en marts.revenue se calcula como gross_revenue de staging.invoices menos refunds de staging.returns" — es más granular y más poderoso: permite trazar exactamente cómo se compone cada valor en un reporte hasta sus fuentes de origen. El linaje entre sistemas — que conecta, por ejemplo, un campo en el CRM con la tabla en el warehouse con el KPI en el dashboard — es el nivel más complejo pero el más operativamente útil, porque permite responder la pregunta que se hace cualquier ejecutivo cuando ve un número inesperado: "¿de dónde viene exactamente este dato?"

La distinción entre catálogos de datos de primera generación y los modernos refleja una evolución fundamental en la filosofía de mantenimiento. Los catálogos de primera generación — muchos basados en tecnología de los 2000s como IBM InfoSphere o Informatica — dependían de catalogación manual: equipos de analistas dedicados revisaban los sistemas y documentaban los activos en el catálogo. Este modelo fracasaba porque el ritmo de cambio en los sistemas de datos supera la capacidad de cualquier equipo de mantenimiento manual. La documentación envejecía más rápido de lo que podía actualizarse, y los usuarios dejaban de confiar en el catálogo porque la información estaba desactualizada. Los catálogos modernos invierten este modelo: auto-poblan metadatos técnicos mediante conectores activos, reducen la carga manual al contexto de negocio que realmente agrega valor, y notifican a los propietarios cuando los activos cambian para que mantengan actualizada la documentación de negocio.

La emergencia de la inteligencia artificial en el entorno de datos añade una nueva dimensión al catálogo: los modelos de lenguaje y los agentes de datos que responden preguntas en lenguaje natural necesitan metadatos precisos para generar respuestas correctas. Un modelo de IA que intenta responder "¿cuántos clientes nuevos adquirimos este trimestre?" necesita saber qué tabla contiene los registros de clientes, cómo se define "nuevo" en el contexto de la organización, qué columna registra la fecha de incorporación y si existen condiciones de filtro adicionales (por ejemplo, excluir clientes de prueba). Sin un catálogo con metadatos de negocio bien documentados, los modelos de IA aplican suposiciones que producen respuestas plausibles pero incorrectas — el problema del "hallucination" aplicado a los datos propios de la empresa. El catálogo de datos se convierte así en la capa de conocimiento que hace que los sistemas de IA sobre datos propietarios sean confiables en lugar de peligrosos.

Errores frecuentes

• ✗

  Intentar documentar todos los activos de datos antes de lanzar el catálogo al equipo. Es el error más común: el equipo de datos pasa semanas o meses documentando cada tabla antes de que cualquier analista pueda usar el catálogo. Para cuando el catálogo se "lanza", las primeras tablas documentadas ya tienen meses de antigüedad y algunas están desactualizadas. El enfoque correcto es lanzar el catálogo con metadatos técnicos auto-poblados desde el primer día, documentar manualmente solo los activos más críticos, y crecer la documentación de forma iterativa con contribuciones de todo el equipo.

• ✗

  Elegir una herramienta enterprise sin considerar la capacidad operativa del equipo para mantenerla. Alation y Collibra son herramientas poderosas diseñadas para equipos de datos maduros con recursos dedicados a la gestión del catálogo. Para una empresa con un equipo de tres a cinco personas en datos, estas plataformas generan una carga operativa que el equipo no puede sostener, con el resultado de que el catálogo se vuelve un proyecto de mantenimiento en lugar de una herramienta de productividad. La sofisticación de la herramienta debe ser proporcional a la madurez y el tamaño del equipo que la va a operar.

• ✗

  No asignar propietarios de datos con responsabilidad clara sobre la documentación. Si la documentación del catálogo es responsabilidad "de todos", en la práctica es responsabilidad de nadie. Cada activo de datos relevante debe tener un propietario nombrado — una persona específica, no un equipo genérico — responsable de mantener actualizada la descripción de negocio, aprobar cambios de acceso y validar que la documentación refleja la realidad actual del dato. Sin responsabilidad individual clara, el catálogo degenera en un inventario técnico sin contexto de negocio, que es útil para el equipo de ingeniería pero no para los analistas y ejecutivos que más lo necesitan.

Cómo Fairview lo gestiona

Fairview funciona como una capa de inteligencia operativa sobre sus datos existentes, con un enfoque que comparte la filosofía central del catálogo de datos: hacer que los datos sean comprensibles y confiables para quien los necesita, sin requerir conocimiento técnico de la infraestructura subyacente. Cada métrica que Fairview expone en el Operating Dashboard tiene una definición única y documentada — la misma que se usa para calcular el número, disponible para cualquier usuario que quiera entender de dónde viene ese valor.

Cuando Fairview conecta con sus fuentes de datos — CRM, ERP, plataforma de pagos, herramientas de marketing — genera un mapa de las entidades y métricas disponibles, mostrando qué datos alimentan cada cálculo y qué fuentes son autoritativas para cada concepto. Si la empresa tiene datos de clientes en HubSpot y en Stripe, Fairview muestra cómo reconcilia ambas fuentes y qué regla de prioridad aplica. Esto elimina las discrepancias entre reportes que generan reuniones de reconciliación en lugar de conversaciones sobre acción. Para organizaciones que necesitan gobernanza más formal sobre sus datos operativos, Fairview complementa — no reemplaza — un catálogo de datos dedicado, exponiendo las métricas clave con la trazabilidad suficiente para que el equipo pueda confiar en los números que impulsan las decisiones.

Preguntas frecuentes