Cómo crear un Notebook Spark Job en Microsoft Fabric: paso a paso

João Barros 13 de August de 2026 5 min de lectura

Este tutorial muestra cómo crear un Notebook y publicarlo como Spark Job en Microsoft Fabric para programar la ejecución recurrente de PySpark. Es útil para automatizar ETL/ELT, transformaciones y pipelines sin intervención manual —por ejemplo, procesar 1–10 GB de archivos diarios o agregar millones de filas para informes. Explicaré el porqué de las decisiones y daré ejemplos concretos para pruebas y producción.

Requisitos previos

Cuenta con acceso a un workspace en Microsoft Fabric con permisos de autor (o superiores).
Un Lakehouse o OneLake para leer/escribir archivos (p. ej.: CSV/Parquet). Idealmente tienes una carpeta para raw y otra para processed.
Conocimientos básicos de Python/PySpark y del entorno de Notebooks de Fabric. Saber interpretar logs y métricas de ejecución es una ventaja.

Paso 1: Crear un nuevo Notebook en el workspace

Abre tu workspace en Microsoft Fabric y crea un nuevo Notebook. Elige el kernel PySpark adecuado: Serverless Spark para cargas pequeñas/ocasionales o un Spark Pool asociado al Warehouse/Lakehouse para cargas mayores. Pon un nombre identificable, por ejemplo: process_sales_notebook, junto con una breve descripción: "Agrega ventas diarias". Mantén un estándar de nombres (prefijo, propósito, entorno) para gestionar múltiples jobs con facilidad.

Paso 2: Escribir código PySpark mínimo y listo para producción

Escribe código que lea datos del Lakehouse, haga una transformación simple y escriba el resultado. Mantén el código modular y con rutas relativas a OneLake/Lakehouse para portabilidad entre dev y prod. Ejemplos de buenas prácticas: validación de esquema, partición por fecha y uso de coalesce al escribir para controlar el número de archivos.

from pyspark.sql import functions as F

# Caminhos no OneLake/Lakehouse
input_path = 'one:///lakehouse/sales/raw/sales.csv'
output_path = 'one:///lakehouse/sales/processed/sales_agg.parquet'

# Ler CSV (ajusta opções conforme necessário)
df = spark.read.option('header', 'true').option('inferSchema', 'true').csv(input_path)

# Exemplo de transformação: agregação por dia
df2 = (df
  .withColumn('date', F.to_date('order_date'))
  .groupBy('date')
  .agg(F.sum(F.col('amount')).alias('total_amount'), F.count('*').alias('orders'))
)

# Gravar em Parquet (substituir)
df2.write.mode('overwrite').parquet(output_path)

Para datasets mayores, considera particionar por date y usar repartition(10) o un número de particiones equivalente al número de cores disponibles (p. ej.: 8–32). Si procesas 5 GB diariamente, 8–16 cores suelen ser suficientes para mantener tiempos de ejecución por debajo de 10–20 minutos, dependiendo de las transformaciones.

Paso 3: Probar el Notebook manualmente

Ejecuta las celdas en el Notebook para validar que el código se ejecuta sin errores y que los archivos se leen/escriben en OneLake/Lakehouse. Prueba con un subconjunto del 1–10% de los datos para reducir tiempo y coste. Corrige problemas comunes: credenciales, rutas, opciones de lectura (delimiter/header), permisos e incompatibilidades de tipo (string vs numeric).

Paso 4: Ajustar configuraciones para ejecución como Spark Job

Antes de publicar, asegúrate de que el Notebook no dependa de variables interactivas. Sustituye valores hardcoded por parámetros cuando sea necesario. En la parte superior del Notebook, añade un bloque para leer parámetros cuando se ejecute como job. Esto permite reutilizar el mismo Notebook entre entornos (dev/prod) y datasets diarios.

import os
# Parâmetros com valores por defeito
input_path = os.environ.get('INPUT_PATH', input_path)
output_path = os.environ.get('OUTPUT_PATH', output_path)

Verifica también el kernel y la versión de Spark deseada. Confirma dependencias (bibliotecas externas) y añade instrucciones para instalarlas en el entorno del job si es necesario.

Paso 5: Publicar el Notebook como Spark Job

En el menú del Notebook, elige "Publish as Spark Job" (Publicar como Spark Job). Define un nombre de Job, la descripción y elige el bundle del Notebook. Configura el tipo de cluster (Serverless Spark o un Spark Pool/ Warehouse) y la dimensión (CPU/memoria). Ejemplo: para 5 GB diarios, elige 8 cores y 32 GB RAM; para cargas pequeñas usa 2 cores y 8 GB. Estas elecciones impactan directamente en el coste y el tiempo de ejecución.

Paso 6: Definir parámetros y variables del Job

En la configuración del Spark Job, añade parámetros de entorno o argumentos que el Notebook espera (por ejemplo INPUT_PATH, OUTPUT_PATH). Esto hace que el job sea reutilizable para diferentes entornos (dev/prod) y fechas. Usa convenciones de nombres e incluye valores por defecto para pruebas rápidas.

{
  "INPUT_PATH": "one:///lakehouse/sales/raw/sales_2026-08-01.csv",
  "OUTPUT_PATH": "one:///lakehouse/sales/processed/sales_2026-08-01.parquet"
}

Paso 7: Programar y configurar reintentos/alertas

En la sección de scheduling del Spark Job, crea una recurrence (diaria, horaria o CRON). Por ejemplo, usa daily at 02:00 UTC para cargas nocturnas. Define políticas de retry (p. ej.: 3 intentos con backoff exponencial) y notificaciones (correo electrónico o integración con herramientas de monitorización). Confirma la zona horaria y la ventana de ejecución para evitar solapamientos con otras ventanas de mantenimiento.

Verificar el resultado

Tras la ejecución del Spark Job, comprueba: 1) el estado del Job en el panel de Jobs (Succeeded/Failed), 2) los logs del run para mensajes, número de tasks y tiempo de ejecución (por ejemplo: 12 min, 8 executors), 3) la presencia e integridad del archivo de salida en OneLake/Lakehouse. Abre el Parquet con un Notebook o usa la vista del Lakehouse para confirmar schema y conteos (count() / sample()).

Conclusión

Ahora tienes un Notebook transformado en Spark Job en Microsoft Fabric, listo para ejecutarse de forma automática con parámetros y programación. Próximos pasos recomendados: añadir tests unitarios de datos, usar secrets para credenciales, versionar Notebooks e integrar con un Pipeline para orquestación. Consejo práctico: comienza por programar ejecuciones reducidas (muestra del 1%) para validar costes y rendimiento antes de pasar a producción completa.