En Microsoft Fabric la transformación se elige por lógica, volumen y capacidad del equipo, no por preferencia. Usa Dataflow Gen2 para preparación tabular de bajo código, SQL para transformaciones relacionales, Notebooks para reglas complejas en Python o PySpark, y Spark Job Definition para procesos de producción programados. La regla base: la opción más simple que pueda probarse, versionarse y operarse sin esconder lógica crítica.
¿Por qué la transformación es el corazón de la arquitectura?
En una arquitectura medallion, los datos viajan por tres capas. La capa Bronze preserva el dato tal como llega, para dar trazabilidad, recuperación y auditoría. La capa Silver limpia, une, estandariza, deduplica y corrige problemas conocidos. La capa Gold organiza los datos para el consumo analítico: modelos, informes, Excel y agentes. Antes de elegir motor conviene tener claro qué es la transformación de datos en Fabric y para qué sirve, porque esa base define cómo viaja el dato entre capas.
El motor de transformación es lo que mueve el dato de una capa a la siguiente. Si esa lógica está mal elegida o mal operada, el resto de la casa se resiente. Por eso la decisión no es cosmética: define si tu equipo podrá versionar, probar y mantener las reglas del negocio con el tiempo, o si quedarán atrapadas en un notebook que solo una persona entiende.
La regla práctica es simple: criterio antes que herramienta. La herramienta correcta aparece cuando ya sabes qué métrica quieres, con qué grano y para quién. Y si la lógica de base es débil, cualquier capa de IA que pongas encima solo hará más visibles sus errores.
¿Qué motores ofrece Fabric y para qué sirve cada uno?
Fabric no impone un único camino de transformación. Data Engineering completa la arquitectura medallion con varios motores concretos, cada uno con un encaje distinto según la lógica que necesitas expresar y el volumen que manejas.
- Dataflow Gen2: ideal para preparación tabular con lógica Power Query y equipos que necesitan bajo código. Da consultas legibles, destino explícito y actualización monitoreada.
- SQL: la mejor opción para transformaciones relacionales, uniones, agregaciones y modelos estructurados en Lakehouse o Warehouse. Se apoya en scripts versionados y pruebas de reconciliación.
- Notebook: Python o PySpark para exploración, reglas complejas, consumo de APIs, ciencia de datos o procesamiento que supera lo que Power Query puede hacer con comodidad.
- Spark Job Definition: procesos Spark de producción, por lotes o streaming, que deben ejecutarse como trabajos programados.
- Environment: no transforma datos por sí mismo, pero fija las mismas librerías, configuración de Spark y recursos para que notebooks y trabajos sean reproducibles.
¿Cómo elegir el motor correcto según tu caso?
La decisión se ordena por tres ejes: la lógica que necesitas expresar, el volumen de datos y la capacidad real de tu equipo. Un equipo de negocio que vive en Excel avanzará más rápido con Dataflow Gen2; un equipo con perfiles de datos aprovechará SQL o Notebooks. Para el dilema más frecuente, esta comparación de cuándo conviene Dataflow Gen2 o un Notebook como motor de transformación ayuda a decidir con criterio. La tabla resume el encaje y el control de implementación que exige cada motor.
| Motor | Mejor encaje | Control de implementación |
|---|---|---|
| Dataflow Gen2 | Modelado en columnas y filas con pasos de Power Query, cuando el perfil del equipo es de bajo código | Nombres de consulta claros, destino declarado, refresco con seguimiento y contrato de esquema sin sorpresas |
| SQL | Transformaciones relacionales, uniones, agregaciones, modelos en Lakehouse o Warehouse | Scripts versionados, pruebas de reconciliación, grano documentado, rendimiento medido |
| Notebook | Python o PySpark, reglas complejas, APIs, ciencia de datos | Código reproducible, parámetros, salida persistente, registros, separar experimento y producción |
| Spark Job Definition | Cargas productivas sobre Spark que corren en tandas o de forma continua bajo calendario | Punto de entrada, parámetros de invocación, lakehouse enlazado, ventana de ejecución, observabilidad y política ante reintentos |
| Environment | Notebooks y trabajos que comparten librerías y configuración | Versiones de dependencias, configuración compartida, promoción controlada entre entornos |
No se trata de usar el motor más potente, sino el más simple que resuelva el problema y que tu equipo pueda operar. Un proceso relacional que cabe en SQL no gana nada por moverse a PySpark, y sí pierde legibilidad.
¿Cuándo un notebook deja de ser un experimento y se vuelve producción?
Aquí está la trampa más común. Un notebook interactivo es excelente para descubrir la solución: exploras, pruebas hipótesis, ajustas reglas. Pero descubrir la solución no es lo mismo que operarla.
Un notebook no es un pipeline de producción hasta que tiene:
- Parámetros, para que no dependa de valores escritos a mano.
- Dependencias fijadas, idealmente vía un Environment reproducible.
- Salida definida, persistida en una ubicación conocida.
- Ejecución repetible, que cualquiera pueda lanzar con el mismo resultado.
- Observabilidad, con registros que permitan saber qué pasó.
- Un responsable claro de mantenerlo.
Mientras falte cualquiera de estos seis elementos, tienes un experimento útil, no un proceso listo para operar. La distinción importa: el pipeline coordina la orquestación, pero el motor es el que transforma. Confundir el notebook exploratorio con el proceso productivo es cómo la lógica crítica termina escondida y sin dueño.
¿Qué buenas prácticas sostienen la transformación en el tiempo?
Más allá de elegir el motor, hay disciplinas que separan un flujo frágil de un sistema confiable:
- Respeta el propósito de cada capa medallion. No mezcles limpieza de Silver con lógica de negocio de Gold. Cada capa tiene un contrato.
- Versiona la lógica. Scripts SQL, notebooks y flujos deben vivir en control de versiones, no solo en la interfaz.
- Documenta el grano. Saber a qué nivel de detalle vive cada tabla evita agregaciones incorrectas aguas abajo.
- Prueba con reconciliación. Compara totales entre origen y destino para detectar pérdidas o duplicados antes de que lleguen a un informe.
- Separa experimento y producción. El código que explora no debería ser el mismo que corre programado sin supervisión.
- Usa Environments para reproducibilidad. Fijar dependencias evita el clásico funciona en mi máquina.
Estas prácticas conectan con la idea del modelo semántico como contrato: la transformación existe para alimentar métricas consistentes, no para producir tablas sueltas. Cuando la lógica es legible, versionada y probada, dirección y equipo ven los mismos números en Excel, Power BI o cualquier agente de IA.
¿Cuál es el siguiente paso?
Elegir bien el motor de transformación es una decisión de criterio, no de herramienta. El objetivo es siempre el mismo: que la lógica sea legible, versionada y probada, y que dirección y equipo trabajen sobre las mismas cifras en lugar de discutirlas en cada reunión. Si quieres ver cómo aplicamos estos criterios sobre Fabric, Power BI y la arquitectura medallion en casos reales, mira la demo gratuita y evalúa qué camino de formación o consultoría encaja con tu equipo.
Preguntas relacionadas
¿Cuál es el mejor motor de transformación en Microsoft Fabric?
No hay uno mejor de forma absoluta. Se elige por lógica, volumen y capacidad del equipo: Dataflow Gen2 para preparación tabular de bajo código, SQL para transformaciones relacionales, Notebooks para reglas complejas en Python o PySpark, y Spark Job Definition para procesos de producción programados. La regla es usar la opción más simple que pueda probarse, versionarse y operarse.
¿Cuándo debo usar un Notebook en lugar de Dataflow Gen2?
Usa un Notebook cuando necesites Python o PySpark para exploración, reglas complejas, consumo de APIs, ciencia de datos o procesamiento que supera lo que Power Query resuelve con comodidad. Dataflow Gen2 encaja mejor en preparación tabular con lógica Power Query y equipos que necesitan bajo código.
¿Cuándo un notebook se convierte en un pipeline de producción?
Solo cuando tiene parámetros, dependencias fijadas, salida definida, ejecución repetible, observabilidad y un responsable claro. Mientras falte alguno de esos elementos, sigue siendo un experimento útil para descubrir la solución, no un sistema productivo. El pipeline coordina y el motor transforma.
¿Para qué sirve un Environment en Fabric?
Un Environment fija las mismas librerías, configuración de Spark y recursos para que notebooks y trabajos sean reproducibles. No transforma datos por sí mismo, pero permite promover dependencias de forma controlada entre entornos y evitar que un proceso funcione en una máquina y falle en otra.
¿Cómo se relaciona la transformación con la arquitectura medallion?
El motor de transformación mueve el dato entre capas: Bronze preserva el dato como llega, Silver limpia, une, estandariza y deduplica, y Gold organiza los datos para consumo analítico, modelos, informes, Excel y agentes. Cada capa tiene un contrato distinto y la transformación debe respetarlo.