Dataflow Gen2 vs Notebook en Fabric: cuál elegir | Acadevor
·8 min de lectura
Dataflow Gen2 o Notebook: qué motor de transformación conviene
Guía de decisión para elegir entre Dataflow Gen2 y Notebook en Microsoft Fabric según lógica, volumen y capacidad del equipo, con criterios claros y citables.
Elige Dataflow Gen2 cuando la transformación es preparación tabular, cabe en Power Query y tu equipo trabaja mejor con bajo código. Elige Notebook cuando la lógica es compleja, involucra Python o PySpark, consume APIs o supera lo que Power Query resuelve con claridad. No es una guerra de motores: es elegir la opción más simple que puedas probar, versionar y operar sin esconder lógica crítica.
La pregunta correcta no es cuál es mejor
En Microsoft Fabric la transformación de datos se elige por tres variables: la lógica que necesitas aplicar, el volumen que procesas y la capacidad real de tu equipo. No existe un motor superior en abstracto. Existe el motor que tu gente puede leer, mantener y explicar dentro de seis meses.
Esto es parte de la arquitectura medallion, donde el dato viaja de Bronze a Silver a Gold. Bronze preserva el dato como llega, con trazabilidad y auditoría. Silver limpia, une, estandariza y corrige problemas conocidos. Gold organiza los datos para consumo analítico, informes, Excel y agentes. El motor de transformación es la herramienta que mueve el dato entre esas capas, sobre todo en Silver.
La regla de fondo es simple: criterio antes que herramienta. Primero defines qué transformación necesitas y quién la va a mantener. Después eliges el motor.
Cuándo conviene Dataflow Gen2
Dataflow Gen2 es el motor de bajo código de Fabric. Se apoya en Power Query, el mismo lenguaje visual que ya usan quienes vienen de Excel y Power BI. Conviene cuando:
La transformación es tabular: filtrar, combinar columnas, cambiar tipos, dar forma a tablas.
Demo gratuita
Mira cómo construir tu sistema de datos e IA
Un recorrido práctico de principio a fin para unificar fuentes dispersas en un modelo semántico que alimenta Excel, Power BI, Copilot y tus agentes.
La lógica se expresa bien en Power Query sin trucos ni pasos ocultos.
El equipo necesita autonomía sin escribir código.
Quieres consultas legibles, con un destino explícito y un esquema de salida estable.
Su fortaleza es el control de implementación al alcance de perfiles de negocio: consultas que se leen, un destino claro y una actualización que se puede monitorear. Cuando la preparación cabe en Power Query, forzar un notebook solo agrega complejidad que después nadie quiere mantener.
Cuándo conviene un Notebook
El Notebook usa Python o PySpark. Si todavía no tienes claro qué es un Notebook en Fabric y para qué sirve, conviene partir de ahí. Es el motor para exploración, reglas complejas, consumo de APIs, ciencia de datos y procesamiento que supera lo que Power Query resuelve con orden. Conviene cuando:
La lógica es demasiado ramificada o específica para expresarse limpio en Power Query.
Necesitas llamar APIs externas o aplicar librerías de análisis.
El volumen o el tipo de cómputo pide la potencia de Spark.
Estás explorando y todavía no sabes cuál es la solución final.
El control de implementación aquí es distinto: código reproducible, parámetros, salida persistente, registros y una separación clara entre experimento y producción. Esa última parte es la que más se descuida y la que más cuesta después.
La regla de producción que evita el pipeline fantasma
Un notebook interactivo puede ayudar a descubrir la solución, pero no es un pipeline de producción hasta que cumple seis condiciones. Esta es la lista que separa un experimento de un proceso en producción:
Parámetros, para que no dependa de valores escritos a mano.
Dependencias fijadas, para que corra igual mañana.
Salida definida, con un destino y un esquema claros.
Ejecución repetible, no un clic manual.
Observabilidad, con registros que muestren qué pasó.
Un responsable con nombre y apellido.
Mientras falte cualquiera de esas seis, tienes un cuaderno de descubrimiento, no un proceso operativo. La distinción importa: el pipeline coordina, el motor transforma. Confundir el notebook exploratorio con el pipeline de producción es una de las fuentes más comunes de deuda técnica en Fabric. Aplicar buenas prácticas para la transformación de datos en Fabric desde el inicio ayuda a evitar ese salto.
Tabla de decisión: los cinco motores de Fabric
Dataflow Gen2 y Notebook son las dos opciones más comparadas, pero Fabric ofrece cinco motores. Elegir bien empieza por conocerlos todos.
Motor
Mejor encaje
Control de implementación
Dataflow Gen2
Modelado de tablas con pasos de Power Query, cuando el mantenimiento queda en manos sin perfil de código
Que cada consulta se entienda al leerla, con destino declarado, refresco bajo seguimiento y columnas sin sorpresas
SQL
Transformaciones relacionales, uniones, agregaciones en Lakehouse o Warehouse
Scripts versionados, pruebas de reconciliación, grano documentado, rendimiento medido
Notebook
Python o PySpark para exploración, reglas complejas, APIs, ciencia de datos
Código reproducible, parámetros, salida persistente, registros, experimento separado de producción
Spark Job Definition
Cargas Spark ya productivas que corren en tandas o en flujo continuo bajo una programación fija
Definir el archivo de entrada y sus parámetros, el lakehouse de destino, cuándo se dispara, cómo se observa y qué justifica volver a correrlo
Environment
Notebooks y trabajos que comparten librerías, configuración de Spark y recursos
Versiones de dependencias, configuración compartida, promoción controlada entre entornos
Una lectura útil: SQL suele ser la mejor opción para transformaciones relacionales puras, incluso más que un notebook. Spark Job Definition es el paso natural cuando un notebook probado tiene que convertirse en un trabajo programado y confiable. Y Environment no transforma datos: fija las dependencias reproducibles que un notebook o un trabajo necesitan para correr igual siempre.
Cómo decidir en tres preguntas
Cuando dudes entre Dataflow Gen2 y Notebook, respóndete esto en orden:
¿La lógica cabe limpia en Power Query? Si la respuesta es sí, Dataflow Gen2 casi siempre gana por simplicidad y por quién puede mantenerlo.
¿Necesitas Python, PySpark, APIs o reglas que Power Query volvería ilegibles? Si es así, el Notebook es el camino, con la disciplina de producción arriba.
¿Quién va a mantener esto? Un proceso que solo una persona entiende es un riesgo, sin importar el motor. La capacidad del equipo es criterio de decisión, no un detalle.
Elige siempre la opción más simple que puedas probar, versionar y operar. La potencia extra que no puedes mantener no es una ventaja, es un pasivo.
El modelo semántico sigue siendo el contrato
Cualquiera sea el motor, el objetivo no cambia: llevar el dato hasta Gold, listo para que el modelo semántico exponga métricas consistentes. Ese modelo funciona como acuerdo compartido sobre las métricas del negocio, la misma definición que dirección y equipo miran en Excel, Power BI o un agente. La IA no arregla un modelo pobre, lo amplifica. Elegir bien el motor de transformación es parte de cuidar ese contrato desde la base.
Siguiente paso
Si quieres ver cómo se aplica este criterio sobre un caso real, con Dataflow Gen2, notebooks y el resto de los motores de Fabric trabajando juntos, mira la demo gratuita. El criterio se entrena viendo y practicando sobre casos reales, no memorizando tablas.
Preguntas frecuentes
¿Cuándo debo usar Dataflow Gen2 en lugar de un Notebook?
Usa Dataflow Gen2 cuando la transformación es tabular y cabe limpia en Power Query, y tu equipo trabaja mejor con bajo código. Es la opción más simple de leer y mantener para perfiles de negocio.
¿Cuándo conviene un Notebook en Microsoft Fabric?
Conviene cuando la lógica es compleja, usa Python o PySpark, consume APIs o supera lo que Power Query resuelve con orden. También es útil para exploración y ciencia de datos, siempre separando el experimento de la producción.
¿Un notebook interactivo ya es un pipeline de producción?
No. Un notebook interactivo ayuda a descubrir la solución, pero solo es producción cuando tiene parámetros, dependencias fijadas, salida definida, ejecución repetible, observabilidad y un responsable asignado.
¿Qué otros motores de transformación ofrece Fabric además de estos dos?
Fabric incluye SQL para transformaciones relacionales, Spark Job Definition para procesos Spark programados y Environment para fijar dependencias reproducibles. Dataflow Gen2 y Notebook son solo dos de las cinco opciones.
¿Cómo elijo el motor si dudo entre varias opciones?
Responde en orden: si la lógica cabe limpia en Power Query, elige Dataflow Gen2; si necesitas Python o reglas complejas, elige Notebook; y evalúa siempre quién mantendrá el proceso. La regla es usar la opción más simple que puedas probar, versionar y operar.
