La decisión no es cuál motor es mejor, sino qué transformación pertenece a cada uno. Dataflow Gen2 encaja cuando la lógica es tabular y el equipo trabaja mejor con bajo código; Notebook encaja cuando la regla supera lo que Power Query puede expresar con claridad. En muchas arquitecturas la respuesta madura es usar los dos, cada uno donde rinde.
Elegir motor de transformación en Microsoft Fabric suele plantearse como una pelea entre Dataflow Gen2 y Notebook. Es una pregunta mal formulada. El motor se elige por lógica, volumen y capacidad del equipo, no por preferencia. La regla útil es usar la opción más simple que pueda probarse, versionarse y operarse sin esconder lógica crítica. Este artículo compara ambos por habilidades, mantenimiento, escala y trazabilidad, y explica cuándo combinarlos es más sensato que elegir uno de forma exclusiva.
Qué resuelve bien cada motor
Dataflow Gen2 es el motor de preparación tabular con lógica Power Query. Su mejor encaje son equipos que necesitan bajo código y consultas legibles, con un destino explícito, actualización monitoreada y un esquema de salida estable. Es rápido para estandarizar columnas, tipar datos y dejar una tabla lista sin escribir código imperativo.
Notebook usa Python o PySpark y encaja cuando la exploración, las reglas complejas, el consumo de APIs, la ciencia de datos o el procesamiento superan lo que Power Query puede expresar con claridad. Aquí importa el código reproducible, los parámetros, la salida persistente, los registros y una separación firme entre experimento y producción.
La documentación oficial ordena estas piezas: Data Engineering en Fabric sitúa Spark, notebooks y lakehouses como el núcleo de código, mientras Dataflow Gen2 cubre la transformación de bajo código. No compiten por el mismo trabajo: cubren tramos distintos del mismo camino.
Habilidades del equipo: la variable que casi nadie mide
La capacidad del equipo pesa tanto como el volumen de datos. Un motor que nadie puede mantener no es una solución, es deuda futura. Si quienes operan la transformación piensan en columnas, filtros y pasos visibles, Dataflow Gen2 conserva la lógica cerca de su forma mental. Si el equipo escribe y prueba código, Notebook les da expresividad y control que Power Query no alcanza.
El error costoso es elegir el motor por moda. Un Notebook en manos de un equipo sin práctica de código produce scripts frágiles sin pruebas ni parámetros. Un Dataflow Gen2 forzado a expresar reglas que no le corresponden se vuelve una maraña de pasos ilegibles. El criterio antes que la herramienta evita ambos extremos.
Mantenimiento y trazabilidad: dónde se paga la deuda
La transformación se mantiene durante años, no durante el sprint en que se escribe. En Dataflow Gen2 la trazabilidad vive en consultas legibles, un destino explícito y un esquema de salida estable que no cambia sin aviso. En Notebook la trazabilidad depende de disciplina: código en control de versiones, parámetros en vez de valores fijos, salida definida y registros que expliquen qué corrió y con qué resultado.
Aquí aparece la regla de producción que separa un descubrimiento de un sistema vivo. Un notebook interactivo puede ayudar a encontrar la solución, pero no es un pipeline de producción hasta que tiene parámetros, dependencias, salida definida, ejecución repetible, observabilidad y un responsable. El pipeline coordina; el motor transforma. Saltarse esa frontera es la fuente más común de procesos que funcionan una vez y nadie puede volver a ejecutar con confianza.
Escala: cuándo Power Query se queda corto
El volumen y el tipo de procesamiento marcan un límite natural. Dataflow Gen2 rinde en preparación tabular de tamaño razonable con lógica que Power Query expresa bien. Cuando el procesamiento supera esa expresividad, cuando hay reglas complejas, integración con APIs, o cargas que piden el motor distribuido, Notebook con PySpark es el encaje correcto.
Hay un escalón más para producción sostenida: cuando un proceso Spark debe ejecutarse programado, por lotes o en streaming, la forma madura es una Spark Job Definition con archivo principal, argumentos, lakehouse asociado, agenda y criterio de reejecución. Y cuando varios notebooks y trabajos necesitan las mismas librerías y configuración, un Environment fija dependencias reproducibles y promueve esa configuración de forma controlada. Escalar no es solo mover más datos: es hacer que la ejecución sea repetible y gobernada.
Dónde vive esta decisión en la arquitectura
La elección de motor no ocurre en el vacío. Ocurre dentro de la arquitectura medallion. Bronze preserva el dato como llega y da trazabilidad. Silver limpia, une, estandariza y deduplica. Gold organiza los datos para consumo analítico, informes, Excel y agentes. La capa donde más se decide entre motores suele ser Silver, porque ahí se corrigen problemas de calidad, se homogeneizan reglas y se unen fuentes.
Muchos conflictos que parecen pedir un motor potente son en realidad problemas de reglas compartidas. Si dos áreas calculan el mismo indicador de forma distinta, casi nunca se arregla con una visual ni cambiando de motor: se arregla en Silver y en el modelo semántico, donde las reglas quedan como contrato común. Elegir Notebook para forzar una regla que debería vivir en el modelo semántico solo esconde el problema en código. Si estás definiendo esas capas, conviene revisar primero la arquitectura medallion en Fabric y la preparación de datos en Lakehouse, que muestra cómo materializar esas transformaciones.
Cuándo combinar los dos rinde más
Elegir de forma exclusiva es una falsa disciplina. Una combinación sensata reparte el trabajo por su naturaleza. Un patrón frecuente: Dataflow Gen2 hace la preparación tabular de entrada, estandariza columnas y deja tablas limpias en Silver; un Notebook toma esas tablas para las reglas complejas, el enriquecimiento con APIs o el procesamiento que Power Query no expresa bien. Cada motor hace lo que domina y ninguno carga con lo que no le corresponde.
La condición para que esa combinación no se vuelva un laberinto es la misma regla de producción: cada tramo con su parámetro, su salida definida, su responsable y su lugar en el pipeline que coordina. Combinar no significa mezclar; significa asignar cada transformación al motor que la sostiene mejor.
La decisión, en concreto
Antes de abrir Fabric, escribe en una línea qué hace la transformación, cuánto volumen mueve y quién la va a mantener. Si es preparación tabular que Power Query expresa con claridad y el equipo trabaja mejor con bajo código, empieza en Dataflow Gen2. Si la regla supera Power Query o el volumen pide procesamiento distribuido, escribe un Notebook y llévalo a estándar de producción antes de considerarlo terminado. Y si el caso tiene ambos tramos, divídelo: prepara en Dataflow Gen2, procesa en Notebook, y deja documentado en el pipeline qué motor corre en cada paso y por qué. Si quieres ver cómo aterrizar estos criterios en tu propia arquitectura de datos, mira la demo gratuita.
Preguntas relacionadas
¿Puedo migrar una transformación de Dataflow Gen2 a Notebook más adelante?
Sí, pero trátalo como un cambio de producción, no como una copia. Antes de migrar, define parámetros, salida persistente, registros y responsable, porque un Notebook sin esa disciplina pierde la trazabilidad que el Dataflow Gen2 tenía por defecto.
¿Una Spark Job Definition reemplaza al Notebook?
No, cumplen roles distintos. El Notebook sirve para descubrir y desarrollar la lógica; la Spark Job Definition ejecuta un proceso Spark de producción programado, con archivo principal, argumentos, agenda y criterio de reejecución. Suelen usarse en secuencia, no como alternativas.
¿Por qué necesito un Environment si ya tengo el Notebook funcionando?
El Environment fija las mismas librerías y configuración de Spark para varios notebooks y trabajos, y permite promover esa configuración de forma controlada. Sin él, cada proceso puede correr con dependencias distintas y volverse difícil de reproducir entre entornos.
¿En qué capa medallion se decide normalmente entre motores?
Con más frecuencia en Silver, donde se corrigen problemas de calidad, se estandariza y se unen fuentes. Es la capa donde la lógica se vuelve compleja, así que ahí es donde el tipo de regla suele inclinar la decisión hacia bajo código o hacia código.
¿Elegir el motor equivocado tiene arreglo sin rehacer todo?
Depende de si respetaste la frontera de producción. Si la salida de cada tramo está definida y persistida, puedes reemplazar el motor de un paso sin tocar los demás. Si la lógica está escondida sin parámetros ni salida clara, el costo de cambiar sube mucho.