Si alguna vez te tocó desarrollar o mantener pipelines de datos, seguramente te encontraste con algo así: una red de archivos SQL, stored procedures, scripts en Python y quién sabe qué más. Todo ejecutándose como una especie de caja negra. Nadie sabe con certeza qué está ocurriendo, pero ahí está, funcionando más o menos y con suerte.
Ese escenario rara vez se resuelve cambiando de herramienta. El problema suele ser de disciplina.
El problema de fondo
La transformación de datos es la etapa donde convertís datos crudos en algo útil para análisis. En un pipeline ELT, es la T: lo que ocurre después de que los datos ya están en tu data warehouse o data lake.
El problema es que durante años la transformación se trató como "escribir SQL". Y escribir SQL suelto, sin estructura, sin versionado, sin dependencias explícitas, escala muy mal.
Cuando tenés 5 queries, podés tenerlas en la cabeza. Cuando tenés 50, necesitás un documento que nadie actualiza. Cuando tenés 200, nadie sabe qué depende de qué, y modificar una columna puede romper cosas que ni sabías que existían.
A escala, se vuelve imposible entender qué modelo depende de qué. Terminás con la famosa caja negra.
Qué significa tratar la transformación como disciplina
Tratar la transformación como disciplina implica aplicar las mismas prácticas que funcionan en desarrollo de software:
Código versionado: las transformaciones viven en un repositorio. Podés ver quién cambió qué, cuándo, y por qué. Podés hacer rollback si algo se rompe.
Modularización: cada transformación es una unidad independiente que podés reutilizar. Si algo cambia, lo cambiás en un lugar.
Dependencias explícitas: el sistema sabe qué transformación depende de qué otra. No está en tu cabeza ni en un documento que nadie lee.
Testing integrado: podés validar suposiciones sobre tus datos como parte del mismo proceso de desarrollo. No como un paso separado que nadie hace.
Documentación junto al código: la documentación vive con el código y se actualiza cuando el código cambia. No en un wiki que quedó desactualizado hace seis meses.
Estas prácticas son las que diferencian un pipeline que podés mantener de uno que se vuelve inmanejable.
El grafo de dependencias
El concepto más importante de esta disciplina es el linaje: saber qué depende de qué. Cuando declarás explícitamente que una transformación usa el resultado de otra, estás construyendo un grafo de dependencias que habilita ejecución ordenada, análisis de impacto y documentación visual.
Pero el linaje merece su propio artículo. Por ahora, lo importante es entender que sin dependencias explícitas, a escala se vuelve imposible razonar sobre el pipeline.
Herramientas que implementan esta disciplina
Existen varias herramientas que implementan estos principios: dbt, SQLMesh, Dataform, entre otras. Cada una tiene sus particularidades, pero comparten el mismo enfoque:
- Transformaciones como archivos de código en un repositorio.
- Dependencias declaradas explícitamente.
- Grafo de linaje generado automáticamente.
- Testing y documentación integrados al workflow.
La herramienta específica importa menos que el enfoque. Si entendés la disciplina, podés aplicarla con cualquier framework declarativo.
Lo que viene en esta colección
Esta colección cubre los conceptos fundamentales de transformación de datos desde la perspectiva de las decisiones que tenés que tomar.
Los temas:
- Este artículo: el marco conceptual de la transformación como disciplina.
- Linaje como contrato: cómo las dependencias explícitas habilitan gobierno y mantenibilidad.
- Materializaciones: tabla, vista, incremental. Cuándo usar cada una y qué trade-offs tiene cada decisión.
- Datos externos vs datos estáticos: la diferencia entre lo que viene de afuera y lo que versionás con tu proyecto.
- Abstracción y templating: cuándo la abstracción ayuda y cuándo genera código que nadie entiende.
- El DAG acíclico: por qué el grafo no puede tener ciclos y qué hacer cuando tu diseño los pide.
Cada artículo es independiente, pero construyen sobre el mismo marco. Si entendés la disciplina, los detalles de implementación son triviales.