Ingeniería de datos en Fabric: Notebooks, Apache Spark y Jobs de alto rendimiento

En el ecosistema de Microsoft Fabric, el motor de Apache Spark es el corazón de las operaciones de ingeniería de datos a escala. Aunque muchos usuarios provienen de un entorno visual como Dataflows Gen2, la realidad de los proyectos empresariales en sectores como el retail o la industria exige un control más fino sobre los recursos, la computación distribuida y la gestión del código. Pasar de una interfaz low-code a un enfoque code-first no es solo una cuestión de preferencia, sino de supervivencia técnica cuando el volumen de datos supera las capacidades de los motores relacionales tradicionales.

El uso de Spark en Fabric permite desacoplar el almacenamiento de la computación, aprovechando el formato Delta Lake para mantener la integridad ACID. Sin embargo, no basta con escribir código Python; es imperativo entender cómo Fabric gestiona las sesiones de Spark, cómo se distribuyen las tareas en los ejecutores y cuándo es el momento de mover un prototipo de un Notebook a un Spark Job Definition (SJD) para su despliegue en producción. En este artículo, analizaremos las decisiones críticas de arquitectura que marcan la diferencia entre un proceso eficiente y uno que consume excesivos recursos de capacidad.

Antes de profundizar, es vital recordar que la elección entre herramientas depende del caso de uso. Si aún tienes dudas sobre dónde almacenar tus datos procesados, te recomiendo consultar nuestra comparativa sobre Lakehouse vs Data Warehouse en Microsoft Fabric: Matriz de Decisión.

Notebooks en Fabric: Entorno de desarrollo y colaboración

Los Notebooks en Fabric no son simples editores de texto para Python o Scala. Son entornos interactivos que permiten la exploración de datos inmediata gracias a la integración nativa con el Lakehouse. La principal ventaja competitiva frente a otros entornos es el V-Order, una técnica de optimización de escritura propietaria de Microsoft que acelera drásticamente la lectura de archivos Parquet por parte del motor de SQL y Power BI.

Al desarrollar en un Notebook, el ingeniero de datos debe gestionar la sesión de Spark de forma consciente. Fabric asigna dinámicamente nodos según la configuración del espacio de trabajo, pero podemos sobrescribir estos parámetros mediante comandos mágicos (magics). Un error común que veo en consultorías es dejar la configuración por defecto para cargas de trabajo pesadas, lo que resulta en tiempos de espera innecesarios mientras el clúster escala.

# Configuración de la sesión de Spark para optimizar el barajado de datos (shuffling)
from pyspark.sql import SparkSession

spark.conf.set("spark.sql.shuffle.partitions", "200") # Ajustar según el tamaño de los datos
spark.conf.set("spark.sql.adaptive.enabled", "true") # Habilitar Adaptive Query Execution

# Lectura de una tabla Bronze en formato Delta
df_ventas = spark.read.table("Lakehouse_Bronze.Ventas_Retail")

# Ejemplo de filtrado y limpieza básica
df_limpio = df_ventas.filter(df_ventas["Importe"] > 0).dropDuplicates(["ID_Transaccion"])

La colaboración en tiempo real permite que varios ingenieros trabajen sobre el mismo Notebook, con control de versiones integrado mediante Git. No obstante, el Notebook debe verse como una herramienta de experimentación y desarrollo de la Capa Silver en Fabric. Para procesos recurrentes y críticos, debemos evolucionar hacia estructuras más robustas.

Spark Job Definitions (SJD): Producción y orquestación

Cuando el código de transformación está validado, mantenerlo en un Notebook para su ejecución programada suele ser una mala práctica. Los Notebooks tienen un overhead de interfaz y gestión de estado que no es necesario en procesos batch. Aquí es donde entran los Spark Job Definitions (SJD).

Un SJD permite subir archivos .py (Python), .jar (Java/Scala) o .ipynb, pero con una diferencia fundamental: se ejecutan como un trabajo de Spark puro, con parámetros definidos externamente y un control total sobre el clúster. Al usar SJDs, podemos definir:

• Main definition file: El punto de entrada de nuestra aplicación Spark.
• Argumentos de línea de comandos: Para parametrizar fechas de carga, nombres de tablas o entornos (Dev/Prod).
• Reference files: Librerías personalizadas o archivos de configuración adicionales.

En proyectos de alta disponibilidad, los SJD se integran mejor en los Pipelines de Fabric, permitiendo reintentos automáticos y una gestión de errores más limpia que la simple ejecución de celdas en un Notebook. Además, los SJD permiten una mejor observabilidad a través de la interfaz de Spark UI, facilitando la detección de cuellos de botella en etapas específicas del grafo acíclico dirigido (DAG).

Gestión de librerías y entornos personalizados

Uno de los mayores dolores de cabeza en ingeniería de datos es la gestión de dependencias. Fabric soluciona esto mediante los «Environments». En lugar de instalar librerías con %pip install en cada ejecución (lo cual es ineficiente y lento), creamos un entorno preconfigurado que incluya todas las bibliotecas de Python o archivos JAR necesarios.

Este enfoque garantiza que todos los Notebooks y Jobs de un mismo Workspace utilicen las mismas versiones de librerías, evitando el clásico «en mi entorno funciona». Es recomendable separar los entornos por tipo de carga: uno ligero para ETL estándar y uno más pesado para tareas de Machine Learning que requieran PyTorch o TensorFlow. Para profundizar en esta última faceta, puedes leer sobre Data Science en Microsoft Fabric: Gestión de Experimentos y MLflow.

Escalado automático y optimización de costes

Fabric utiliza un modelo de capacidad compartida (F-SKUs). El rendimiento de Spark depende directamente de cómo configuramos el «Autoscale» y el «Dynamic Allocation». Si configuramos un clúster demasiado pequeño, Spark recurrirá al derrame a disco (spilling to disk), lo que penaliza el rendimiento. Si es demasiado grande, consumiremos CUs (Capacity Units) de forma innecesaria.

Un aspecto crítico es la limpieza de metadatos y versiones. Spark en Fabric genera múltiples versiones de los archivos Delta para permitir el Time Travel. Sin una estrategia de mantenimiento, el almacenamiento y el rendimiento de lectura se degradan. Es obligatorio programar tareas de Limpieza de versiones antiguas con VACUUM para mantener el Lakehouse saludable.

Patrones de diseño: Ingesta y transformación distribuida

Para lograr un alto rendimiento, el código debe aprovechar la naturaleza distribuida de Spark. Un error típico de ingenieros que vienen de Pandas es intentar iterar por filas (loops). En Spark, siempre debemos pensar en operaciones vectorizadas sobre DataFrames.

# MAL: Iterar por filas (Antipatrón)
# for row in df.collect(): 
# procesar(row)

# BIEN: Operaciones distribuidas con funciones integradas
from pyspark.sql import functions as F

df_resultado = df_limpio.withColumn(
 "Importe_Total", 
 F.col("Unidades") * F.col("Precio_Unitario")
).withColumn(
 "Categoria_Gasto",
 F.when(F.col("Importe_Total") > 1000, "Alto").otherwise("Estándar")
)

# Escritura optimizada para Direct Lake
df_resultado.write.format("delta").mode("overwrite").saveAsTable("Ventas_Procesadas")