M365Con 2027 – conferencia online gratuita · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Cuándo usar un notebook de Fabric o un dataflow: guía para no desarrolladores

By ·

Compara los notebooks y los dataflows de Microsoft Fabric. Descubre cuándo usar dataflows de bajo código o notebooks de Spark según tus habilidades y tus necesidades de datos.

Automatically translated with AI from the original post. Read the English original

Cover: Fabric Notebooks - Simply Explained

Decidir entre un notebook de Spark de Microsoft Fabric y un dataflow puede intimidar a los analistas que son nuevos en el ecosistema de datos en la nube. Esta guía te ayuda a elegir la herramienta adecuada de transformación de datos de Microsoft Fabric, comparando los dataflows de bajo código con los notebooks con mucho código según la complejidad, la escala y las necesidades de mantenimiento.

Puntos clave

Entender el panorama de datos de Fabric

Cuando entras por primera vez en Microsoft Fabric, la cantidad de elementos del espacio de trabajo puede abrumarte. Ingenieros de datos, científicos de datos y analistas de business intelligence comparten de repente una plataforma de análisis unificada. Una de las confusiones más habituales es elegir el motor principal para la preparación de datos: ¿deberías crear un dataflow visual o abrir un notebook con mucho código?

Durante décadas, los profesionales de datos han lidiado con esta división. Por un lado, tenemos interfaces gráficas que ocultan el motor subyacente. Por otro, tenemos el lienzo en blanco de un editor de texto, a la espera de código Python o Scala. En Fabric, esto se traduce directamente en la elección entre Dataflows Gen2 y notebooks de Spark. Entender cuándo usar cada uno es fundamental para mantener un patrimonio de datos limpio y escalable sin agotar a tus analistas.

¿Qué es un Dataflow Gen2?

Los Dataflows Gen2 de Microsoft Fabric son la evolución nativa en la nube de Power Query. Si alguna vez has creado informes en Power BI, seguramente te has encontrado con el editor de Power Query. Los dataflows toman esa experiencia de transformación tan familiar y la escalan para ejecutarse de forma nativa dentro de Fabric.

Son fundamentalmente visuales. Haces clic en botones para eliminar columnas, combinar tablas, cambiar tipos de datos y filtrar filas. Por debajo, Power Query traduce estas acciones a código M, pero rara vez tienes que mirarlo, a menos que quieras. Esto hace que los dataflows resulten muy accesibles para analistas de negocio y usuarios avanzados que ya saben dar forma a los datos para los informes.

El poder y la complejidad de los notebooks

Por otro lado, los notebooks están diseñados para Apache Spark. Cuando abres un notebook de Fabric por primera vez, te recibe lo que parece un entorno de pruebas para desarrolladores: celdas de código, mensajes de error extraños y opciones de configuración para los grupos de Spark.

Los notebooks te dan control total. Puedes escribir scripts personalizados en Python, ejecutar algoritmos de machine learning, procesar archivos no estructurados y gestionar lógica iterativa compleja que las herramientas visuales simplemente no pueden soportar. Sin embargo, ese poder tiene una curva de aprendizaje pronunciada. Si tu trabajo principal es limpiar una tabla de ventas estándar, entrar en un notebook puede sentirse como intentar construir el motor de un coche cuando solo necesitabas un cambio de aceite.

Matriz de decisión: Dataflows vs. notebooks

Para elegir la herramienta adecuada para tu próxima canalización de datos, necesitas evaluar tu escenario concreto frente a las fortalezas de cada herramienta. Vamos a desglosar los criterios clave que debes considerar antes de escribir tu primera línea de código o hacer clic en tu primer paso de transformación.

Consideraciones sobre volumen y escala

Aunque Dataflows Gen2 puede manejar grandes cantidades de datos aprovechando las capacidades de back-end de Fabric', los conjuntos de datos extremadamente masivos o las tareas de computación distribuida complejas son donde los notebooks de Spark realmente destacan. Si procesas terabytes de archivos de registro, transmites telemetría en tiempo real o ejecutas uniones distribuidas pesadas entre múltiples fuentes dispares, un notebook proporciona la potencia de cálculo necesaria.

Por el contrario, para datos transaccionales y dimensionales empresariales estándar que residen en bases de datos relacionales o aplicaciones SaaS, los dataflows ofrecen rendimiento más que suficiente sin la sobrecarga de iniciar y administrar sesiones de cómputo de Spark.

Perfiles del equipo y mantenimiento

Uno de los factores más pasados por alto en las decisiones de arquitectura es el mantenimiento a largo plazo. ¿Quién va a dar soporte a esta canalización dentro de seis meses? Si construyes una canalización compleja con código Python personalizado dentro de un notebook, pero el equipo que la mantiene solo conoce SQL y Power Query, habrás creado un cuello de botella operativo.

La facilidad de mantenimiento favorece la simplicidad. Si una tarea se puede resolver de forma limpia en un dataflow, suele ser prudente quedarte con el enfoque de bajo código. Reserva los notebooks para los escenarios en los que la lógica de negocio realmente exija capacidades avanzadas de programación o integración con ciencia de datos.

Cerrar la brecha: un flujo de trabajo pragmático

No tienes que elegir una sola herramienta para toda tu organización. De hecho, las arquitecturas maduras de Fabric suelen usar ambas en armonía. Una buena práctica para los no desarrolladores es empezar por la exploración.

Usa dataflows para ingerir, limpiar y cargar tus tablas dimensionales principales en un Lakehouse. Una vez que tus datos estén estructurados y sean fiables, puedes incorporar notebooks específicamente para analítica avanzada, entrenamiento de modelos de machine learning o tareas especializadas de ciencia de datos que requieran control programático.

Al compartimentar tu arquitectura, garantizas que los analistas de negocio puedan trabajar con comodidad dentro de sus habilidades, mientras que los ingenieros de datos y los profesionales avanzados aprovechan toda la potencia de Spark cuando sea necesario.

Conclusión

Elegir entre un notebook de Fabric y un dataflow se reduce a ajustar tu herramienta al requisito de negocio real, en lugar de optar por la opción más compleja disponible. Empieza evaluando el volumen de datos, las habilidades de tu equipo y la complejidad de tus transformaciones. Si quieres profundizar en cómo superar la intimidación inicial de las herramientas basadas en código, no dejes de escuchar el episodio completo del podcast, con orientación experta para dominar tus flujos de trabajo de datos en Microsoft Fabric.

Preguntas frecuentes

¿Pueden los no desarrolladores usar notebooks de Fabric con éxito?

Sí, pero requiere paciencia y disposición para aprender la sintaxis básica de Python o PySpark. Se recomienda empezar con tareas más sencillas o con dataflows de bajo código antes de pasar al desarrollo de notebooks a gran escala.

¿Son los Dataflows Gen2 más lentos que los notebooks de Spark?

No necesariamente. Para transformaciones estándar de inteligencia de negocio y volúmenes de datos moderados, los Dataflows Gen2 se ejecutan con una velocidad excepcional y abstraen el ajuste de rendimiento.

¿Cuándo debo dejar de usar un dataflow y pasar a un notebook?

Deberías considerar el cambio a un notebook cuando la lógica de transformación requiera bucles iterativos, bibliotecas de machine learning, análisis de archivos no estructurados complejos o un rendimiento de computación distribuida que supere las capacidades estándar de Power Query.

¿Puedo ejecutar un dataflow y un notebook en el mismo pipeline de Fabric?

Por supuesto. Los pipelines de Fabric te permiten orquestar dataflows y notebooks en secuencia, lo que te permite combinar la ingesta de bajo código con transformaciones programáticas avanzadas.

Microsoft Fabric Power Query Fabric notebooks Fabric workspace Power BI

Related articles

RSS