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

João Barros 22 de September de 2026 6 min de lectura

Automatizar la ejecución de Spark Jobs en Microsoft Fabric es útil para pipelines ETL, preparación de datos y tareas recurrentes. Este tutorial muestra cómo crear un Spark Job, configurarlo con parámetros, programarlo y gestionar errores para garantizar ejecuciones fiables. Cubriremos el motivo de cada opción y daremos ejemplos prácticos con números plausibles (memoria, cores, retries) para que puedas aplicar directamente.

Prerequisitos

Cuenta con acceso a un workspace en Microsoft Fabric y permisos de contributor. Sin este permiso no puedes crear Jobs ni programar triggers.
Un Notebook Spark funcional en el workspace (PySpark o Spark SQL). Si ya tienes un notebook que lee de OneLake/Lakehouse y escribe parquet, estás casi listo.
Conocimientos básicos de PySpark / Spark SQL y de la UI del Fabric. Saber leer logs y ajustar memory/cores ayuda a evitar OOM.
Recomendación práctica: prueba con un dataset de ejemplo (10k–100k filas) antes de pasar a producción con millones de filas.

Paso 1: Preparar un Notebook con parámetros

Explicación del porqué: usar parámetros permite reutilizar el mismo Notebook para diferentes inputs, fechas o entornos (dev/prod). También hace el debug más sencillo: cambias solo los argumentos en el Job UI, no el código.

# Exemplo PySpark no Notebook
from pyspark.sql import SparkSession
from datetime import datetime

# widgets para parametrização no Fabric
dbutils.widgets.text("input_path", "/lakehouse/default/mydata")
input_path = dbutils.widgets.get("input_path")

dbutils.widgets.text("output_root", "/lakehouse/default/output")
output_root = dbutils.widgets.get("output_root")

spark = SparkSession.builder.getOrCreate()
df = spark.read.format("parquet").load(input_path)
# pequena transformação
df2 = df.filter("value IS NOT NULL")

out_path = f"{output_root}/{datetime.now().strftime('%Y%m%d_%H%M%S')}"
df2.write.mode("overwrite").parquet(out_path)
print(f"Wrote to {out_path}")

Ejemplo concreto: en un entorno de pruebas define input_path = /lakehouse/dev/sample (≈50k filas) y output_root = /lakehouse/dev/out. En un entorno de producción usa rutas con particiones por fecha.

Paso 2: Crear un Spark Job en el workspace

Explicación simple: un Spark Job es un recurso gestionado que ejecuta un Notebook con una pool de ejecución. En la Fabric UI, abre la sección Jobs / Spark y elige "Create new job". Indica el Notebook y la Spark pool (p. ej.: pool con 2 workers, cada uno con 4 vCPU y 8 GB RAM).

Ejemplo práctico: para un dataset medio (1–10M filas) empieza con driverMemory=4g, executorCores=2 y 4 executors; luego ajusta según la utilización real. Registra la configuración inicial para comparar costes.

Paso 3: Definir parámetros y configuraciones del Job

Por qué: parametrizar el Job permite cambiar input_path u otras opciones sin editar el Notebook. En el formulario del Job, añade los widgets/args correspondientes — por ejemplo input_path y output_root. Aquí también defines configs de Spark (driverMemory, executorMemory, executorCores) y tags para billing.

# Exemplo de parâmetros no Job UI
input_path = /lakehouse/default/mydata
output_root = /lakehouse/default/output
-- Spark configs --
driverMemory = 4g
executorMemory = 8g
executorCores = 2
numExecutors = 4

Nota: documenta las elecciones (p. ej.: "executorMemory 8g para 2 vCPU por executor"), porque eso afecta costes y rendimiento. Si observas GC excesivo, aumenta memoria o reduce particiones del shuffle.

Paso 4: Configurar la programación (schedule)

Explicación: define cuándo se ejecuta el Job automáticamente — diario, horario o cron. En el Job, elige "Schedule" y configura un trigger recurrente. Para evitar superposición, activa "Max concurrent runs = 1" o define políticas de retries y backoff.

# Exemplos de opções comuns no UI
Schedule: Recurring daily at 02:00
Timezone: Europe/Lisbon
Retry policy: 2 retries, backoff 5 minutes (exp. backoff opcional)
Max concurrent runs: 1

Ejemplo concreto: programa una ejecución diaria a las 02:00 para jobs ETL que procesan datos del día anterior. Para pipelines cada hora usa cron (p. ej.: "0 * * * *" para al inicio de cada hora). Si el tiempo esperado por run es 30–45 min, evita un trigger cada 15 minutos.

Paso 5: Añadir notificaciones y estrategias de fallo

Por qué: recibir alertas y tener retries mejora la fiabilidad operativa. En el Job, configura e‑mail/webhook en Notifications y define la política de retries. Registra también el estado del job en OneLake para auditoría y reconciliación.

# Boas práticas
- Enable email on failure para a equipa de operações
- Set 2 retries com exponential backoff (ex.: 5m, 15m)
- Write job status to /lakehouse/default/job_status as parquet/json

Ejemplo de escritura de estado en el Notebook (simple): escribe un fichero JSON con status, start_time, end_time y rows_processed para permitir dashboards de monitorización.

Paso 6: Probar manualmente antes de programar

Explicación: ejecuta el Job manualmente con parámetros de prueba para confirmar que el Notebook y las conexiones a OneLake/Lakehouse funcionan. Observa el tiempo de ejecución (por ejemplo 12 min en la primera corrida, 8 min en rerun) y ajusta recursos según sea necesario.

Verificar el resultado

Confirma que el Job se ejecutó y produjo output:

En la sección Jobs ve el historial de runs y status (Success/Failed). Verifica tiempos de start/end y duration (útiles para SLAs).
Revisa los logs para mensajes, warnings y exceptions; copia stack traces relevantes al sistema de incidentes.
Confirma que los ficheros/parquet se escribieron en la ruta especificada en OneLake/Lakehouse y valida tamaño/particiones (p. ej.: 3 ficheros parquet, 120 MB en total).
Verifica notificaciones/e‑mail de fallo si están configuradas y el registro en /lakehouse/default/job_status.

Conclusión

Al crear un Spark Job programado en Microsoft Fabric con parámetros, programación y notificaciones, automatizas tareas ETL repetitivas de forma robusta. Próximos pasos: integrar el Job en una pipeline más amplia, añadir tests unitarios en el Notebook y usar métricas de ejecución para optimizar costes. Consejo práctico: empieza por programar en horarios fuera de pico, monitoriza las primeras 7–14 ejecuciones y ajusta recursos y retries según el patrón de fallos y latencias observadas.