Data Lineage (Linaje de Datos)

Definición

Data lineage (linaje de datos) es el mapa documentado de la trayectoria que siguen los datos a través de un sistema analítico: desde las fuentes de origen — bases de datos de producción, APIs, archivos — a través de cada transformación, modelo intermedio y tabla derivada, hasta los consumidores finales: dashboards, reportes, modelos de machine learning, métricas operacionales. El linaje responde a preguntas que son fundamentales para cualquier equipo que opera con datos: ¿qué tablas producen qué resultados?, ¿qué columnas de origen fluyen hacia qué métricas de negocio?, ¿qué reportes se romperían si cambio esta tabla?, ¿de dónde viene exactamente este número que aparece en el dashboard?

El linaje existe en cuatro niveles de granularidad, cada uno con utilidad diferente. El linaje a nivel de tabla — el más común — documenta qué tablas o modelos dependen de qué otras tablas: el modelo mrr_monthly depende de subscriptions y payment_events. El linaje a nivel de columna va más profundo: documenta que la columna mrr_monthly.net_mrr se calcula a partir de subscriptions.amount_cents menos payment_events.refund_amount. El linaje a nivel de métrica conecta definiciones de negocio con sus implementaciones técnicas. El linaje entre sistemas — el más operacionalmente valioso — conecta fuentes en sistemas de producción con métricas en herramientas de BI, cruzando los límites de múltiples plataformas.

Cómo se implementa

El linaje moderno se genera automáticamente desde el código, no se documenta manualmente. Las herramientas de transformación SQL como dbt construyen un grafo DAG (Directed Acyclic Graph) de dependencias entre modelos a partir de las referencias explícitas en el código SQL — cada vez que un modelo llama a ref('otro_modelo'), dbt registra esa dependencia y la incluye en el linaje. Para linaje a nivel de columna, herramientas como Datafold analizan el SQL de cada modelo para determinar de qué columnas de origen se deriva cada columna de destino.

Ejemplo práctico

Considere una empresa de software de nómina para PYMEs con sede en Bogotá, Colombia, que opera un stack de datos compuesto por una base de datos Postgres en producción, Fivetran para replicación CDC, dbt en BigQuery para transformaciones, y Looker para visualización. El equipo de datos tiene 45 modelos dbt que alimentan 12 dashboards ejecutivos y 8 reportes automatizados que se envían semanalmente a clientes enterprise. El MRR reportado en el dashboard ejecutivo depende de una cadena de 6 modelos: raw_subscriptions → stg_subscriptions → int_subscription_events → fct_mrr → mrr_monthly_summary → kpi_executive_dashboard.

El equipo de ingeniería de producto decide cambiar el tipo de dato de la columna plan_amount en la tabla de suscripciones de producción — de integer (centavos COP) a decimal (pesos COP con decimales) — para soportar precios fraccionados por usuario. Sin linaje documentado, el equipo de datos no sabría que este cambio afecta 6 modelos dbt en cascada y que el MRR del dashboard ejecutivo comenzaría a mostrar valores incorrectos desde el siguiente ciclo de transformación. Con linaje a nivel de columna generado automáticamente por Datafold, el análisis de impacto del cambio muestra en segundos que plan_amount fluye hacia stg_subscriptions.monthly_amount_cop, luego hacia fct_mrr.net_mrr_cop, y finalmente hacia la métrica de MRR en el dashboard ejecutivo. El equipo puede coordinar el cambio de esquema con la actualización de los modelos dbt en la misma ventana de mantenimiento, evitando datos incorrectos en producción.

Análisis en profundidad

El valor estratégico del linaje de datos no es técnico sino organizacional: el linaje es la infraestructura de confianza que permite a los operadores y ejecutivos confiar en los números que ven en los dashboards. En ausencia de linaje documentado, cada vez que un dashboard muestra una cifra inesperada — un MRR que no cuadra con el sistema de facturación, una tasa de churn que difiere entre dos reportes, un margen de contribución que cambia sin que nadie lo haya modificado — el equipo de datos debe iniciar una investigación manual que puede durar horas o días. Con linaje, la respuesta a "¿de dónde viene este número?" se obtiene en minutos navegando el grafo de dependencias desde la métrica de destino hasta la fuente de origen.

La distinción entre linaje a nivel de tabla y linaje a nivel de columna tiene implicaciones prácticas que se vuelven relevantes a medida que la complejidad del stack crece. El linaje a nivel de tabla es suficiente para la mayoría de los análisis de impacto de alto nivel — si necesito saber si un cambio en la tabla orders afectará el reporte de ingresos, el linaje a nivel de tabla me da esa respuesta. Pero en contextos donde múltiples columnas de la misma tabla tienen propósitos diferentes y fluyen hacia métricas diferentes — la columna gross_amount fluye hacia el cálculo de ingresos brutos mientras que net_amount fluye hacia el cálculo de ingresos netos — solo el linaje a nivel de columna permite determinar con precisión qué métricas se ven afectadas por un cambio específico en un campo específico.

La relación entre linaje y gobernanza de datos es bidireccional. El linaje facilita la gobernanza al hacer explícito quién consume qué datos y con qué propósito — información fundamental para aplicar controles de acceso apropiados, identificar qué activos de datos contienen información personal (PII) y rastrear el cumplimiento de regulaciones como LGPD en Brasil o las disposiciones de privacidad del INAI en México. Al mismo tiempo, la gobernanza facilita el linaje al crear incentivos organizacionales para documentar y mantener los metadatos de los activos de datos. En organizaciones donde la gobernanza se aplica con rigor, el linaje tiende a ser más completo porque los equipos de datos tienen la disciplina de registrar dependencias y propietarios para cada activo.

El linaje entre sistemas — que cruza los límites de múltiples plataformas — es el más difícil de implementar pero el más valioso operacionalmente. En un stack típico, los datos fluyen desde una base de datos de producción (Postgres), a través de una herramienta de replicación (Fivetran), hacia un data warehouse (Snowflake), a través de un framework de transformación (dbt), hacia una capa semántica (dbt Semantic Layer o Looker), hacia una herramienta de BI (Looker, Tableau, Metabase). El linaje dentro de cada sistema es relativamente accesible — dbt genera su DAG, Looker documenta sus dimensiones y métricas. El linaje entre sistemas — que conecta la columna fuente en Postgres con la métrica en el dashboard de Looker cruzando tres o cuatro plataformas intermedias — requiere herramientas que integren metadatos de todos los sistemas involucrados. OpenLineage como estándar abierto y Atlan o Castor como plataformas de metadatos unificados son los enfoques más maduros para este problema.

En el contexto latinoamericano, el linaje de datos tiene una dimensión adicional relacionada con la heterogeneidad de los stacks tecnológicos. Muchas empresas medianas en LATAM operan con una mezcla de sistemas legacy — ERPs on-premise como SAP B1 o Microsoft Dynamics, bases de datos Oracle o SQL Server de hace décadas — y herramientas modernas de cloud analytics. El linaje en este contexto debe cruzar no solo diferentes plataformas sino también diferentes paradigmas técnicos: datos que vienen de archivos Excel exportados manualmente de un ERP, procesados por scripts Python, cargados en BigQuery, transformados por dbt y visualizados en Looker Studio. Construir linaje en este entorno requiere un enfoque pragmático que priorice los activos más críticos para el negocio — las métricas de ingresos, margen y flujo de caja que se reportan a dirección — antes de intentar mapear la totalidad del stack de datos.

Errores frecuentes

• ✗

  Intentar documentar el linaje manualmente en wikis o spreadsheets. El linaje manual es inmantenible a escala porque los pipelines de datos cambian constantemente. Cada modificación de un modelo SQL, cada nueva fuente de datos, cada renombramiento de columna deja la documentación manual desactualizada en horas. Los equipos que intentan mantener linaje manual terminan con documentación que nadie confía porque saben que está desactualizada. La única solución sostenible es el linaje generado automáticamente desde el código — dbt, parseo SQL, eventos de OpenLineage — donde la documentación se actualiza con cada ejecución del pipeline.

• ✗

  Confundir linaje con documentación de negocio. El linaje técnico — qué tablas dependen de qué — no reemplaza la documentación de negocio que explica qué significa cada métrica y cómo debe interpretarse. Un equipo puede tener linaje perfecto a nivel de tabla pero aún así tener conflictos sobre qué incluye exactamente el "MRR" — ¿incluye pruebas gratuitas? ¿contratos anuales prorrateados? ¿descuentos aplicados? La capa semántica o el glosario de métricas de negocio son el complemento necesario al linaje técnico. Sin ambos, el linaje resuelve el problema de "¿de dónde viene este número?" pero no el problema de "¿por qué este número difiere del que usa el equipo de finanzas?"

• ✗

  Implementar linaje solo después de que los pipelines están en producción. Añadir linaje retroactivamente a un stack de datos ya existente — con modelos SQL no estructurados, dependencias implícitas y código sin organización — es un proyecto de meses que frecuentemente no se completa. El linaje es más fácil de implementar como parte de la construcción inicial del pipeline: elegir dbt desde el principio en lugar de SQL ad-hoc, usar referencias explícitas entre modelos en lugar de hardcodear nombres de tablas, y adoptar OpenLineage antes de que el pipeline crezca a decenas de fuentes. El costo de añadir linaje desde el inicio es marginal; el costo de retroalimentarlo en un sistema legacy es significativo.

Cómo lo rastrea Fairview

Fairview mantiene linaje interno completo de cada métrica que presenta en su Operating Dashboard — desde la fuente de datos de origen hasta el número visible en el dashboard. Cada métrica de Fairview tiene documentada su cadena de dependencias: qué conector de datos la alimenta, qué transformaciones aplica la plataforma para construirla, qué lógica de negocio define su cálculo. Cuando un operador o CFO ve el MRR del mes en Fairview y necesita verificar cómo se calculó — para reconciliarlo con el reporte de finanzas o para entender por qué cambió respecto al mes anterior — puede acceder a la definición de la métrica y rastrear su origen hasta la fuente. Esta transparencia en el linaje de métricas es parte de lo que diferencia a Fairview de los dashboards genéricos: cada número tiene una trayectoria documentada que el equipo puede auditar cuando lo necesita.

Preguntas frecuentes