Para implementar Spark en Microsoft Fabric, empieza en un notebook con PySpark asociado a un Lakehouse para explorar y descubrir la lógica, luego promueve ese trabajo a un Spark Job Definition con parámetros, salida definida y agenda, y fija las dependencias con un Environment para que la ejecución sea reproducible. La regla es usar la opción más simple que pueda probarse, versionarse y operarse sin esconder lógica crítica.
¿Cuándo conviene usar Spark en Microsoft Fabric?
Spark no es el primer motor que debes elegir en Fabric, es el que eliges cuando la transformación supera lo que resuelven las herramientas de bajo código o SQL. Data Engineering en Fabric completa la arquitectura medallion con motores concretos, y cada uno tiene un mejor encaje.
Spark, a través de notebooks con PySpark o de Spark Job Definition, es la opción correcta cuando necesitas:
- Reglas de transformación complejas que superan lo que Power Query puede expresar con claridad.
- Procesamiento de grandes volúmenes por lotes o en streaming.
- Integración con APIs, lógica de ciencia de datos o código Python reutilizable.
- Exploración y descubrimiento de una solución antes de operarla en producción.
Si tu transformación es tabular y de bajo código, Dataflow Gen2 encaja mejor. Si es relacional (uniones, agregaciones, modelos estructurados en Lakehouse o Warehouse), SQL es más directo. Spark entra cuando la lógica pide un lenguaje de programación completo.
¿Qué motor de transformación elegir en Fabric?
Antes de escribir la primera línea de PySpark, conviene confirmar que Spark es la herramienta correcta. El criterio de Acadevor es siempre el mismo: criterio antes que herramienta. Esta tabla resume el encaje de cada motor.
| Motor | Mejor encaje | Control de implementación |
|---|---|---|
| Dataflow Gen2 | Preparación tabular y lógica Power Query, equipos de bajo código | Consultas legibles, destino explícito, actualización monitoreada |
| SQL | Transformaciones relacionales, uniones y agregaciones en Lakehouse o Warehouse | Scripts versionados, pruebas de reconciliación, grano documentado |
| Notebook | Python o PySpark para exploración, reglas complejas, APIs y ciencia de datos | Código reproducible, parámetros, salida persistente y registros |
| Spark Job Definition | Procesos Spark de producción, por lotes o streaming, programados | Archivo principal, argumentos, lakehouse asociado, agenda y monitoreo |
| Environment | Notebooks y trabajos que comparten librerías y configuración de Spark | Versiones de dependencias, configuración compartida, promoción controlada |
La señal de que necesitas Spark es simple: si la lógica ya no cabe con claridad en Power Query o SQL, un notebook con PySpark te da el control que falta.
¿Cómo empezar con un notebook y PySpark?
El notebook es el punto de entrada natural. Data Engineering en Fabric sitúa Spark, notebooks y lakehouses en un mismo lugar, y el tutorial oficial de preparación de datos en un Lakehouse sigue esa misma ruta: primero asocias el notebook a un Lakehouse para leer y escribir datos.
Una secuencia ordenada para arrancar:
- Crea un notebook en tu área de trabajo y asócialo al Lakehouse donde viven tus datos.
- Lee la capa Bronze, que preserva el dato como llega y te da trazabilidad y recuperación.
- Construye la lógica de la capa Silver: limpia, une, estandariza, deduplica y corrige problemas conocidos.
- Escribe la salida en tablas persistentes, no solo en variables en memoria de la sesión.
- Separa con claridad lo que es experimento de lo que será producción.
Si quieres detenerte en este punto de entrada, revisa cómo implementar los notebooks en Fabric paso a paso antes de seguir. En esta fase el notebook interactivo es ideal para descubrir la solución. Pero descubrir no es operar. Un notebook que corre bien una vez todavía no es un pipeline.
¿Cuándo un notebook se convierte en producción?
Aquí está la frontera que más equipos cruzan sin darse cuenta. Un notebook interactivo puede ayudar a descubrir la solución, pero no es un pipeline de producción hasta que reúne seis condiciones:
- Parámetros: el trabajo recibe entradas en lugar de tener valores fijos en el código.
- Dependencias: las librerías y la configuración están declaradas y controladas.
- Salida definida: se sabe qué escribe, con qué grano y en qué destino.
- Ejecución repetible: corre igual hoy y dentro de tres meses, sin intervención manual.
- Observabilidad: deja registros y se puede monitorear cuándo falla y por qué.
- Responsable: hay alguien a cargo de que siga funcionando.
Mientras falte cualquiera de estas piezas, tienes un experimento útil, no un proceso que pueda operarse. Convertir el experimento en producción es lo que da estabilidad a los datos de los que la empresa depende cada día.
¿Cómo promover el trabajo a un Spark Job Definition?
Cuando la lógica ya está probada, toca empaquetarla como Spark Job Definition, la forma de ejecutar procesos Spark de producción de manera programada. A diferencia del notebook interactivo, un Spark Job Definition se define para ejecutarse solo.
Elementos que configuras al promover el trabajo:
- Archivo principal: el script Spark que contiene la transformación probada.
- Argumentos: los parámetros que antes eran valores fijos en el notebook.
- Lakehouse asociado: el origen y destino de los datos que procesa el trabajo.
- Agenda: la programación por lotes o el flujo de streaming según el caso.
- Monitoreo y criterio de reejecución: cómo se observa el trabajo y qué se hace si falla.
Una distinción clave del método: pipeline coordina, el motor transforma. El Spark Job Definition transforma; si necesitas orquestar varios pasos y dependencias entre ellos, eso lo resuelve un pipeline que invoca el trabajo.
¿Por qué usar un Environment para las dependencias?
El último paso para que la implementación sea confiable es fijar las dependencias con un Environment. Los notebooks y los trabajos que necesitan las mismas librerías, la misma configuración de Spark y los mismos recursos deben compartir un entorno reproducible.
Un Environment te permite:
- Declarar versiones concretas de las dependencias para que no cambien sin aviso.
- Compartir una misma configuración de Spark entre varios notebooks y trabajos.
- Promover cambios de forma controlada entre entornos de desarrollo y producción.
Sin esto, un trabajo que corría bien puede romperse cuando una librería cambia de versión en silencio. Fijar el entorno es una de las buenas prácticas para Spark en Microsoft Fabric que hacen que la ejecución repetible sea real y no una expectativa.
Del criterio a la implementación
Implementar Spark en Fabric es, en el fondo, una decisión de criterio: empezar con la opción más simple que pueda probarse, versionarse y operarse, y subir de motor solo cuando la lógica lo exige. Ese mismo criterio ordena toda la arquitectura medallion, desde Bronze hasta Gold, donde los datos quedan listos para informes, Excel y agentes.
Si quieres ver cómo aplicar este criterio a los datos de tu empresa, con ejemplos concretos de pipelines y arquitectura medallion en Fabric, mira la demo gratuita y evalúa el punto de partida de tu equipo antes de implementar.
Preguntas relacionadas
¿Cuándo debo usar Spark en lugar de Dataflow Gen2 en Fabric?
Usa Spark cuando la transformación supera lo que Power Query puede expresar con claridad: reglas complejas, grandes volúmenes, integración con APIs o ciencia de datos. Si la preparación es tabular y de bajo código, Dataflow Gen2 encaja mejor.
¿Un notebook de Spark ya es un pipeline de producción?
No. Un notebook interactivo sirve para descubrir la solución, pero solo es producción cuando tiene parámetros, dependencias declaradas, salida definida, ejecución repetible, observabilidad y un responsable a cargo.
¿Qué diferencia hay entre un notebook y un Spark Job Definition?
El notebook es interactivo y sirve para explorar. El Spark Job Definition empaqueta el trabajo probado con archivo principal, argumentos, lakehouse asociado y agenda para ejecutarse de forma programada, por lotes o en streaming.
¿Para qué sirve un Environment en Fabric?
Un Environment fija las versiones de las librerías y la configuración de Spark que comparten notebooks y trabajos, para que la ejecución sea reproducible y las dependencias no cambien en silencio entre desarrollo y producción.
¿Spark reemplaza a los pipelines en Fabric?
No. En el método, el pipeline coordina y el motor transforma. Spark ejecuta la transformación; si necesitas orquestar varios pasos con dependencias entre ellos, un pipeline invoca el trabajo Spark.