Un pipeline con 200 transformaciones SQL puede funcionar. Pero cuando algo falla, rastrear el origen del problema se convierte en arqueología. Y modificar una columna puede romper cosas que ni sabías que existían.
El SQL que escribís importa. Pero las dependencias entre transformaciones importan más.
El problema de las dependencias implícitas
En un pipeline tradicional, las dependencias están en tu cabeza. O en un documento que nadie actualiza. O en el orden de ejecución de un orquestador que alguien configuró hace dos años.
El resultado es predecible: nadie sabe con certeza qué depende de qué. Las relaciones entre transformaciones existen, pero no están declaradas en ningún lado que el sistema pueda leer.
Dependencias explícitas como contrato
Cuando declarás explícitamente que una transformación usa el resultado de otra, estás estableciendo un contrato. Ese contrato dice: "este modelo necesita que aquel otro exista y esté actualizado antes de ejecutarse".
Ese contrato habilita varias cosas que sin él son imposibles o muy costosas:
Ejecución ordenada automática: el sistema sabe qué ejecutar primero, qué después, y qué puede correr en paralelo. No tenés que orquestar manualmente ni mantener un orden de ejecución en un script.
Análisis de impacto: antes de modificar una columna, podés ver qué transformaciones la usan. Eso es fundamental para gobierno de datos. Sabés qué puede romperse antes de romperlo.
Documentación que no se desactualiza: el grafo de dependencias se genera automáticamente desde el código. No es un diagrama que alguien dibujó una vez y quedó obsoleto.
Ejecución selectiva: podés ejecutar solo una transformación y sus dependencias, o solo las transformaciones que dependen de una específica. Eso acelera el desarrollo cuando trabajás en una parte del pipeline.
El grafo como artefacto de gobierno
El grafo de dependencias no es solo una herramienta de ejecución. Es un artefacto de gobierno.
Cuando alguien nuevo llega al proyecto, puede ver la estructura completa de un vistazo. Cuando hay un problema en producción, podés rastrear hacia atrás hasta encontrar el origen. Cuando negocio pide un cambio, podés evaluar el impacto antes de comprometerte.
Sin linaje explícito, estas tareas requieren leer todo el código, entrevistar a la gente que lo escribió (si todavía está), y armar el mapa mental de las relaciones. Con linaje explícito, la información está disponible para cualquiera que la necesite.
Cómo se implementa en la práctica
En herramientas como dbt, SQLMesh o Dataform, las dependencias se declaran usando funciones especiales. En lugar de referenciar una tabla directamente, usás una función que le dice al sistema "este modelo depende de aquel otro".
El sistema usa esa información para construir el grafo automáticamente. Cada vez que agregás una dependencia, el grafo se actualiza.
La implementación específica varía entre herramientas, pero el concepto es el mismo: hacer explícito lo que antes estaba implícito.
Lo que el linaje no resuelve
El linaje explícito resuelve el problema de las dependencias, pero no resuelve otros problemas:
Calidad de los datos: que el grafo esté bien armado no significa que los datos sean correctos. Necesitás tests y validaciones además del linaje.
Lógica de negocio: el linaje te dice qué depende de qué, no si la transformación hace lo que debería hacer. Eso sigue siendo responsabilidad del desarrollador.
Dependencias externas: si tu transformación depende de una tabla que no está en el sistema de linaje, esa dependencia queda invisible. El grafo solo conoce lo que le declarás.
Linaje vs relaciones entre tablas: dos mapas distintos
Hay una confusión frecuente entre el linaje y las relaciones entre tablas (foreign keys, diagramas ER). Ambos son mapas, pero muestran cosas diferentes.
Las relaciones entre tablas muestran cómo se conectan las tablas para consultas. cliente_id en la tabla de ventas referencia a la tabla de clientes. producto_id referencia a la tabla de productos. Son relaciones de join: describen cómo combinar tablas para análisis.
El linaje muestra cómo se construyen las tablas a partir de otras tablas. La tabla fct_ventas se genera a partir de stg_pedidos, stg_lineas y dim_productos. Son relaciones de construcción: describen el flujo de transformación.
Un diagrama ER te dice que podés joinear ventas con clientes por cliente_id. El linaje te dice que la tabla de ventas se construye transformando datos de tres tablas upstream.
Ambos son necesarios y se complementan:
- Las FKs y el modelo relacional te ayudan a entender qué joins son válidos para análisis.
- El linaje te ayuda a entender qué se rompe si modificás una tabla upstream.
Confundirlos lleva a errores. Que dos tablas estén conectadas en el linaje no significa que tenga sentido joinearlas para análisis (una puede ser un paso intermedio que ni siquiera debería exponerse). Y que dos tablas tengan una FK entre ellas no significa que una se construya a partir de la otra.
El linaje como inversión
Declarar dependencias explícitas tiene un costo inicial. Tenés que cambiar la forma en que escribís las transformaciones. Tenés que adoptar una herramienta que soporte el concepto. Tenés que migrar código existente.
Pero el retorno es claro: a medida que el pipeline crece, el costo de no tener linaje crece más rápido. Cada transformación nueva es una relación más que tenés que mantener en tu cabeza. Cada cambio es un riesgo más difícil de evaluar.
El linaje explícito es una inversión en mantenibilidad. Y como toda inversión, conviene hacerla temprano.
En resumen
El SQL que escribís define qué hace cada transformación. Las dependencias explícitas definen cómo se relacionan entre sí. Sin lo segundo, lo primero se vuelve inmanejable a escala.
El linaje no es un feature de una herramienta. Es un contrato entre las partes de tu pipeline que habilita gobierno, análisis de impacto y ejecución ordenada. Tratarlo como tal cambia la forma en que diseñás y mantenés transformaciones.