no colapses de la noche a la mañana. Crecen lentamente, consulta tras consulta.
“¿Qué se rompe cuando cambio una mesa?”
Un panel necesita una nueva métrica, por lo que alguien escribe una consulta SQL rápida. Otro equipo necesita una versión ligeramente diferente del mismo conjunto de datos, por lo que copian la consulta y la modifican. Aparece un trabajo programado. Se agrega un procedimiento almacenado. Alguien crea una tabla derivada directamente en el almacén.
Meses después, el sistema no se parece en nada al simple conjunto de transformaciones que alguna vez fue.
La lógica empresarial se encuentra dispersa en scripts, paneles y consultas programadas. Nadie está completamente seguro de qué conjuntos de datos dependen de qué transformaciones. Hacer incluso un pequeño cambio parece arriesgado. Un puñado de ingenieros se convierten en los únicos que realmente entienden cómo funciona el sistema porque no hay documentación.
Muchas organizaciones eventualmente se encuentran atrapadas en lo que sólo puede describirse como una jungla SQL.
En este artículo exploramos cómo los sistemas terminan en este estado, cómo reconocer las señales de advertencia y cómo devolver la estructura a las transformaciones analíticas. Analizaremos los principios detrás de una capa de transformación bien administrada, cómo encaja en una plataforma de datos moderna y los antipatrones comunes que se deben evitar:
Cómo surgió la jungla SQL Requisitos de una capa de transformación Dónde encaja la capa de transformación en una plataforma de datos Antipatrones comunes Cómo reconocer cuándo su organización necesita un marco de transformación
1. Cómo surgió la jungla SQL
Para comprender la “jungla SQL”, primero debemos observar cómo evolucionaron las arquitecturas de datos modernas.
1.1 El cambio de ETL a ELT
Históricamente, los ingenieros de datos construían canalizaciones que seguían una estructura ETL:
Extraer –> Transformar –> Cargar
Los datos se extrajeron de los sistemas operativos, se transformaron utilizando herramientas de canalización y luego se cargaron en un almacén de datos. Las transformaciones se implementaron en herramientas como SSIS, Spark o Python pipelines.
Debido a que estos canales eran complejos y requerían mucha infraestructura, los analistas dependían en gran medida de los ingenieros de datos para crear nuevos conjuntos de datos o transformaciones.
Las arquitecturas modernas han invertido en gran medida este modelo.
Extraer –> Cargar –> Transformar
En lugar de transformar los datos antes de cargarlos, las organizaciones ahora cargan datos sin procesar directamente en el almacén y allí se producen las transformaciones. Esta arquitectura simplifica drásticamente la ingesta y permite a los analistas trabajar directamente con SQL en el almacén.
También introdujo un efecto secundario no deseado.
1.2 Consecuencias del ELT
En la arquitectura ELT, los analistas pueden transformar los datos ellos mismos. Esto desbloqueó una iteración mucho más rápida pero también introdujo un nuevo desafío. La dependencia de los ingenieros de datos desapareció, pero también lo hizo la estructura que proporcionaban los canales de ingeniería.
Ahora cualquier persona (analistas, científicos de datos, ingenieros) puede crear transformaciones en cualquier lugar (herramientas de BI, cuadernos, tablas de almacén, trabajos SQL).
Con el tiempo, la lógica empresarial creció orgánicamente dentro del almacén. Transformaciones acumuladas como scripts, procedimientos almacenados, disparadores y trabajos programados. En poco tiempo, el sistema se convirtió en una densa jungla de lógica SQL y mucho (re)trabajo manual.
En resumen:
Lógica de transformación centralizada ETL en ductos de ingeniería.
ELT democratizó las transformaciones trasladándolas al almacén.
Sin estructura, las transformaciones se vuelven incontrolables, lo que da como resultado un sistema que se vuelve indocumentado, frágil e inconsistente. Un sistema en el que diferentes paneles pueden calcular la misma métrica de diferentes maneras y la lógica empresarial se duplica en consultas, informes y tablas.
1.3 Recuperar la estructura con una capa de transformación
En este artículo utilizamos una capa de transformación para gestionar las transformaciones dentro del almacén de forma eficaz. Esta capa combina la disciplina de ingeniería de las canalizaciones ETL al tiempo que preserva la velocidad y flexibilidad de la arquitectura ELT:
La capa de transformación aporta la disciplina de la ingeniería a las transformaciones analíticas.
Cuando se implementa con éxito, la capa de transformación se convierte en el único lugar donde se define y mantiene la lógica empresarial. Actúa como la columna vertebral semántica de la plataforma de datos, cerrando la brecha entre los datos operativos sin procesar y los modelos analíticos orientados al negocio.
Sin la capa de transformación, las organizaciones suelen acumular grandes cantidades de datos pero tienen dificultades para convertirlos en información confiable. La razón es que la lógica empresarial tiende a extenderse por toda la plataforma. Las métricas se redefinen en paneles, cuadernos, consultas, etc.
Con el tiempo, esto conduce a uno de los problemas más comunes en análisis: múltiples definiciones contradictorias de la misma métrica.
2. Requisitos de una capa de transformación
Si el problema central son las transformaciones no gestionadas, la siguiente pregunta lógica es:
¿Cómo serían las transformaciones bien gestionadas?
Las transformaciones analíticas deben seguir los mismos principios de ingeniería que esperamos en los sistemas de software, desde scripts ad-hoc dispersos en bases de datos hasta "transformaciones como componentes de software mantenibles".
En este capítulo, analizamos qué requisitos debe cumplir una capa de transformación para gestionar adecuadamente las transformaciones y, al hacerlo, dominar la jungla SQL.
2.1 De scripts SQL a componentes modulares
En lugar de grandes scripts SQL o procedimientos almacenados, las transformaciones se dividen en modelos pequeños que se pueden componer.
Para ser claros: un modelo es solo una consulta SQL almacenada como un archivo. Esta consulta define cómo se construye un conjunto de datos a partir de otro conjunto de datos.
Los siguientes ejemplos muestran cómo la herramienta de modelado y transformación de datos dbt crea modelos. Cada herramienta tiene su propio camino, el principio de convertir scripts en componentes es más importante que la implementación real.
Ejemplos:
–modelos/staging/stg_orders.sql seleccione order_id, customer_id, cantidad, order_date de raw.orders
Cuando se ejecuta, esta consulta se materializa como una tabla (staging.stg_orders) o vista en su almacén. Luego, los modelos se pueden construir uno encima del otro haciendo referencia entre sí:
— modelos/intermedio/int_customer_orders.sql seleccione customer_id, suma(cantidad) como total_gastado de {{ ref('stg_orders') }} grupo por customer_id
Y:
— models/marts/customer_revenue.sql seleccione c.customer_id, c.name, o.total_spent de {{ ref('int_customer_orders') }} o únase a {{ ref('stg_customers') }} c usando (customer_id)
Esto crea un gráfico de dependencia:
stg_orders ↓ int_customer_orders ↓ customer_revenue
Cada modelo tiene una única responsabilidad y se basa en otros modelos haciendo referencia a ellos (por ejemplo, ref('stg_orders')). Este enfoque tiene importantes ventajas:
Puedes ver exactamente de dónde provienen los datos. Sabe qué se romperá si algo cambia. Puede refactorizar las transformaciones de forma segura. Evita duplicar la lógica entre consultas.
Este sistema estructurado de transformaciones hace que el sistema de transformación sea más fácil de leer, comprender, mantener y evolucionar.
2.2 Transformaciones que viven en el código
Un sistema administrado almacena transformaciones en repositorios de código controlados por versiones. Piense en esto como un proyecto que contiene archivos SQL en lugar de SQL almacenado en una base de datos. Es similar a cómo un proyecto de software contiene código fuente.
Esto permite prácticas que son bastante familiares en ingeniería de software pero históricamente raras en las canalizaciones de datos:
solicitudes de extracción revisiones de código historial de versiones implementaciones reproducibles
En lugar de editar SQL directamente en bases de datos de producción, los ingenieros y analistas trabajan en un flujo de trabajo de desarrollo controlado, pudiendo incluso experimentar en sucursales.
2.3 Calidad de datos como parte del desarrollo
Otra capacidad clave que debe proporcionar un sistema de transformación gestionado es la capacidad de definir y ejecutar pruebas de datos.
Los ejemplos típicos incluyen:
asegurar que las columnas no sean nulas verificar la unicidad de las claves primarias validar las relaciones entre tablas hacer cumplir los rangos de valores aceptados
Estas pruebas validan las suposiciones sobre los datos y ayudan a detectar problemas de manera temprana. Sin ellos, las canalizaciones a menudo fallan silenciosamente y los resultados incorrectos se propagan hacia abajo hasta que alguien nota un panel roto.
2.4 Linaje y documentación claros
Un marco de transformación gestionado también proporciona visibilidad del propio sistema de datos.
Esto normalmente incluye:
gráficos de linaje automáticos (¿de dónde provienen los datos?) documentación del conjunto de datos descripciones de modelos y columnas seguimiento de dependencia entre transformaciones
Esto reduce drásticamente la dependencia del conocimiento tribal. Los nuevos miembros del equipo pueden explorar el sistema en lugar de depender de una sola persona que "sabe cómo funciona todo".
2.5 Capas de modelado estructurado
Otro patrón común introducido por los marcos de transformación gestionados es la capacidad de separar capas de transformación.
Por ejemplo, podría utilizar las siguientes capas:
mercados intermedios de puesta en escena cruda
Estas capas suelen implementarse como esquemas separados en el almacén.
Cada capa tiene un propósito específico:
sin procesar: datos ingeridos de los sistemas de origen puesta en escena: tablas limpias y estandarizadas intermedio: mercados lógicos de transformación reutilizables: conjuntos de datos orientados al negocio
Este enfoque en capas evita que la lógica analítica quede estrechamente acoplada a las tablas de ingesta sin procesar.
3. Dónde encaja la capa de transformación en una plataforma de datos
Con los capítulos anteriores, queda claro dónde encaja un marco de transformación gestionada dentro de una arquitectura de datos más amplia.
Una plataforma de datos moderna simplificada suele tener este aspecto:
Sistemas operativos/API ↓ 1. Ingestión de datos ↓ 2. Datos sin procesar ↓ 3. Capa de transformación ↓ 4. Capa de análisis
Cada capa tiene una responsabilidad distinta.
3.1 Capa de ingestión
Responsabilidad: trasladar datos al almacén con una transformación mínima. Las herramientas suelen incluir scripts de ingesta personalizados, Kafka o Airbyte.
3.2 Capa de datos sin procesar
Responsable de almacenar datos lo más cerca posible del sistema fuente. Prioriza la integridad, reproducibilidad y trazabilidad de los datos. Aquí debería ocurrir muy poca transformación.
3.3 Capa de transformación
Aquí es donde ocurre el principal trabajo de modelado.
Esta capa convierte conjuntos de datos sin procesar en modelos analíticos estructurados y reutilizables. Las tareas típicas consisten en limpiar y estandarizar datos, unir conjuntos de datos, definir la lógica empresarial, crear tablas agregadas y definir métricas.
Esta es la capa donde operan marcos como dbt o SQLMesh. Su función es garantizar que estas transformaciones sean
versión estructurada controlada comprobable documentada
Sin esta capa, la lógica de transformación tiende a fragmentarse en los paneles de consultas y los scripts.
3.4 Capa de análisis
Esta capa consume los conjuntos de datos modelados. Los consumidores típicos incluyen herramientas de BI como Tableau o PowerBI, flujos de trabajo de ciencia de datos, canales de aprendizaje automático y aplicaciones de datos internos.
Estas herramientas pueden depender de definiciones consistentes de métricas comerciales, ya que las transformaciones están centralizadas en la capa de modelado.
3.5 Herramientas de transformación
Varias herramientas intentan abordar el desafío de la capa de transformación. Dos ejemplos bien conocidos son dbt y SQLMesh. Estas herramientas hacen que sea muy accesible comenzar a aplicar estructura a sus transformaciones.
Solo recuerde que estas herramientas no son la arquitectura en sí, son simplemente marcos que ayudan a implementar la capa arquitectónica que necesitamos.
4. Antipatrones comunes
Incluso cuando las organizaciones adoptan almacenes de datos modernos, los mismos problemas suelen reaparecer si las transformaciones no se gestionan.
A continuación se muestran antipatrones comunes que, individualmente, pueden parecer inofensivos, pero juntos crean las condiciones para la jungla SQL. Cuando la lógica empresarial está fragmentada, los canales son frágiles y las dependencias no están documentadas, la incorporación de nuevos ingenieros es lenta y los sistemas se vuelven difíciles de mantener y evolucionar.
4.1 Lógica de negocio implementada en herramientas de BI
Uno de los problemas más comunes es el paso de la lógica empresarial a la capa de BI. Piense en "calcular los ingresos en un panel de Tableau".
Al principio, esto parece conveniente ya que los analistas pueden realizar cálculos rápidamente sin esperar soporte de ingeniería. Sin embargo, a largo plazo esto genera varios problemas:
Las métricas se duplican en los paneles. Las definiciones divergen con el tiempo. Dificultad para la depuración.
En lugar de centralizarse, la lógica empresarial se fragmenta entre las herramientas de visualización. Una arquitectura saludable mantiene la lógica empresarial en la capa de transformación, no en los paneles.
4.2 Consultas SQL gigantes
Otro antipatrón común es escribir consultas SQL extremadamente grandes que realizan muchas transformaciones a la vez. Piense en consultas que:
unir docenas de tablas contiene subconsultas profundamente anidadas implementar múltiples etapas de transformación en un solo archivo
Estas consultas rápidamente se vuelven difíciles de leer, depurar, reutilizar y mantener. Idealmente, cada modelo debería tener una única responsabilidad. Divida las transformaciones en modelos pequeños y componibles para aumentar la capacidad de mantenimiento.
4.3 Mezclar capas de transformación
Evite mezclar responsabilidades de transformación dentro de los mismos modelos, como:
unir tablas de ingesta sin procesar directamente con la lógica empresarial mezclar la limpieza de datos con definiciones de métricas crear conjuntos de datos agregados directamente a partir de datos sin procesar
Sin separación entre capas, las tuberías quedan estrechamente acopladas a las estructuras de origen en bruto. Para remediar esto, introduzca capas claras como las comentadas anteriormente crudas, de puesta en escena, intermedias o martas.
Esto ayuda a aislar responsabilidades y hace que las transformaciones sean más fáciles de desarrollar.
4.4 Falta de pruebas
En muchos sistemas, las transformaciones de datos se ejecutan sin ningún tipo de validación. Las canalizaciones se ejecutan correctamente incluso cuando los datos resultantes son incorrectos.
La introducción de pruebas de datos automatizadas ayuda a detectar problemas como claves primarias duplicadas, valores nulos inesperados y relaciones rotas entre tablas antes de que se propaguen a informes y paneles.
4.5 Editar transformaciones directamente en producción
Uno de los patrones más frágiles es la modificación de SQL directamente dentro del almacén de producción. Esto causa muchos problemas donde:
los cambios no están documentados los errores afectan inmediatamente a los sistemas posteriores las reversiones son difíciles
En una buena capa de transformación, las transformaciones se tratan como código con versión controlada, lo que permite revisar y probar los cambios antes de la implementación.
5. Cómo reconocer cuándo su organización necesita un marco de transformación
No todas las plataformas de datos necesitan un marco de transformación completamente estructurado desde el primer día. En sistemas pequeños, un puñado de consultas SQL pueden ser perfectamente manejables.
Sin embargo, a medida que crece el número de conjuntos de datos y transformaciones, la lógica SQL no administrada tiende a acumularse. En algún momento, el sistema se vuelve difícil de entender, mantener y evolucionar.
Hay varias señales de que su organización puede estar llegando a este punto.
El número de consultas de transformación sigue creciendo
Piense en docenas o cientos de tablas derivadas. Las métricas comerciales se definen en varios lugares.
Ejemplo: definición diferente de “usuarios activos” entre equipos Dificultad para comprender el sistema
La incorporación de nuevos ingenieros lleva semanas o meses. Conocimiento tribal necesario para preguntas sobre orígenes, dependencias y linaje de datos. Los pequeños cambios tienen consecuencias impredecibles.
Cambiar el nombre de una columna puede dañar varios conjuntos de datos o paneles posteriores. Los problemas de datos se descubren demasiado tarde.
Los problemas de calidad surgen después de que un cliente descubre números incorrectos en un tablero; el resultado de datos incorrectos que se propagan sin control a través de varias capas de transformaciones.
Cuando estos síntomas empiezan a aparecer, suele ser el momento de introducir una capa de transformación estructurada. Los marcos como dbt o SQLMesh están diseñados para ayudar a los equipos a introducir esta estructura y al mismo tiempo preservar la flexibilidad que brindan los almacenes de datos modernos.
Conclusión
Los almacenes de datos modernos han hecho que el trabajo con datos sea más rápido y accesible al pasar de ETL a ELT. Los analistas ahora pueden transformar datos directamente en el almacén utilizando SQL, lo que mejora enormemente la velocidad de iteración y reduce la dependencia de complejos procesos de ingeniería.
Pero esta flexibilidad conlleva un riesgo. Sin estructura, las transformaciones se fragmentan rápidamente en scripts, paneles, cuadernos y consultas programadas. Con el tiempo, esto conduce a una lógica empresarial duplicada, dependencias poco claras y sistemas difíciles de mantener: la jungla SQL.
La solución es introducir la disciplina de la ingeniería en la capa de transformación. Al tratar las transformaciones de SQL como componentes de software mantenibles (versión controlada, modulares, probadas y documentadas), las organizaciones pueden crear plataformas de datos que sigan siendo comprensibles a medida que crecen.
Marcos como dbt o SQLMesh pueden ayudar a implementar esta estructura, pero el cambio más importante es adoptar el principio subyacente: gestionar las transformaciones analíticas con la misma disciplina que aplicamos a los sistemas de software.
Con esto podemos crear una plataforma de datos donde la lógica empresarial es transparente, las métricas son consistentes y el sistema sigue siendo comprensible incluso a medida que crece. Cuando eso sucede, la jungla SQL se convierte en algo mucho más valioso: una base estructurada en la que toda la organización puede confiar.
Espero que este artículo haya sido tan claro como pretendía, pero si este no es el caso, hágame saber qué puedo hacer para aclararlo más. Mientras tanto, consulte mis otros artículos sobre todo tipo de temas relacionados con la programación.
¡Feliz codificación!
—Mike