Data Science en Microsoft Fabric: Gestión de Experimentos y MLflow

Microsoft Fabric no es solo una evolución de Power BI; es una plataforma de datos unificada que elimina la fricción entre la ingeniería de datos y la ciencia de datos. En mis años como consultor, uno de los mayores cuellos de botella ha sido el trasvase de datos entre entornos: extraer de un SQL, limpiar en local, entrenar en una instancia de computo externa y volver a subir los resultados. Fabric resuelve esto manteniendo los datos en OneLake y permitiendo que los Notebooks de Spark accedan directamente a la información sin latencia de red ni procesos ETL intermedios.

El enfoque de Data Science en Fabric se apoya en tres pilares: la capacidad de computación de Spark, el seguimiento de experimentos mediante MLflow y la potencia de SynapseML. Sin embargo, no basta con saber escribir Python. Para que un modelo predictivo sea útil en una organización de tamaño medio, debe integrarse en una arquitectura medallón en Fabric, garantizando que el modelo consume datos de la capa ‘Oro’ (limpios y modelados) y no basura de la capa ‘Bronce’.

En este artículo, desglosaremos cómo configurar un flujo de trabajo real, desde la exploración automatizada hasta el despliegue del modelo en el registro centralizado, evitando los errores de rendimiento que suelen lastrar los proyectos de IA en producción.

Exploración de datos y AutoEDA con Data Wrangler

Antes de lanzar un entrenamiento masivo, debemos entender la calidad del dato. En proyectos de retail o industria, es habitual encontrar valores nulos en columnas de sensores o fechas de entrega mal formateadas. En lugar de escribir cientos de líneas de código para histogramas y matrices de correlación, Fabric integra Data Wrangler.

Data Wrangler es una herramienta de interfaz gráfica que genera código Python (Pandas o Spark) de forma automática. Lo considero el ‘Power Query’ para científicos de datos. Permite visualizar distribuciones de datos, identificar valores atípicos y aplicar transformaciones complejas con un clic. La ventaja clave aquí no es solo la rapidez, sino la consistencia: el código generado es limpio y se inserta directamente en el Notebook, lo que facilita el linaje de datos.

De la visualización al preprocesamiento

Cuando trabajamos con grandes volúmenes de datos, el error común es intentar cargar todo en un DataFrame de Pandas. Si tu dataset supera los pocos gigabytes, la sesión de Spark colapsará por falta de memoria en el driver. En estos casos, debemos usar Data Wrangler sobre DataFrames de Spark. Esto nos obliga a tomar una decisión de arquitectura: ¿necesitamos procesamiento distribuido para la limpieza? Si la respuesta es sí, debemos quedarnos en el ecosistema Spark y evitar las conversiones a Pandas que rompen la escalabilidad.

Seguimiento de experimentos con MLflow

Uno de los mayores fallos que veo en departamentos técnicos es la falta de trazabilidad. Se entrenan modelos, se ajustan hiperparámetros y, tres meses después, nadie sabe qué versión de los datos o qué configuración produjo el mejor resultado. Aquí es donde entra MLflow, que en Fabric viene preconfigurado y listo para usar.

El registro de experimentos en Fabric permite capturar automáticamente parámetros, métricas (como el RMSE o el F1-Score) y, lo más importante, los artefactos (el modelo entrenado). Al usar mlflow.autolog(), muchas librerías como Scikit-Learn o XGBoost registran toda la información sin intervención manual.

import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestRegressor
from sklearn.metrics import mean_squared_error

# Iniciamos el experimento en Fabric
mlflow.set_experiment("Prediccion_Ventas_Retail")

with mlflow.start_run():
 # Habilitamos el registro automático
 mlflow.sklearn.autolog()

 # Definición y entrenamiento del modelo
 rf = RandomForestRegressor(n_estimators=100, max_depth=10)
 rf.fit(X_train, y_train)

 # Predicciones y métricas adicionales
 predictions = rf.predict(X_test)
 mse = mean_squared_error(y_test, predictions)

 # Registro manual de métricas personalizadas si fuera necesario
 mlflow.log_metric("mse_final", mse)

 print(f"Modelo registrado con éxito. MSE: {mse}")

Este bloque de código no solo entrena un modelo; crea una entrada en la interfaz de Fabric donde cualquier analista puede comparar visualmente las distintas ejecuciones. Es vital para la toma de decisiones basada en datos, especialmente cuando se decide entre un modelo más simple (interpretable) o uno más complejo (caja negra).

SynapseML: Machine Learning a escala

Para escenarios de Big Data, como el análisis de logs en tiempo real o predicciones de inventario en miles de tiendas simultáneamente, las librerías tradicionales de Python se quedan cortas. SynapseML (anteriormente conocida como MMLSpark) es la respuesta de Microsoft para extender las capacidades de Spark MLlib.

SynapseML simplifica tareas complejas como el entrenamiento de modelos de LightGBM distribuido, el uso de servicios cognitivos (como traducción o análisis de sentimiento) directamente en una tabla de Spark, y la creación de modelos de búsqueda vectorial. Lo que antes requería orquestar múltiples servicios de Azure, ahora se ejecuta dentro de un mismo Workspace. Es fundamental elegir correctamente el tipo de entorno de computación; para esto, recomiendo revisar la gestión de Workspaces en Fabric para ajustar las capacidades según la carga de trabajo.

Comparativa: MLflow vs Model Registry

Es común confundir el experimento con el modelo registrado. En la siguiente tabla detallo las diferencias críticas para la gestión del ciclo de vida (MLOps):

Despliegue y consumo: Del Notebook al informe

El valor real del Data Science no está en el Notebook, sino en cómo el negocio consume la predicción. En Fabric, una vez que el modelo está en el Model Registry, podemos utilizar la función PREDICT. Esta función permite realizar inferencia de baja latencia directamente en un Warehouse o Lakehouse utilizando T-SQL, sin necesidad de levantar un clúster de Spark.

Esto cambia las reglas del juego. Podemos tener un modelo de propensión a la compra entrenado en Python y consumido por un analista de SQL que no sabe nada de código, simplemente ejecutando una consulta. Para que este flujo sea seguro, es imperativo implementar correctamente el gobierno de datos para IA generativa y predictiva, asegurando que solo los perfiles autorizados puedan ejecutar predicciones sobre datos sensibles.

Ejemplo de registro de modelo para producción

# Registrar el modelo desde un run exitoso de MLflow
model_uri = f"runs:/{run_id}/model"
registered_model = mlflow.register_model(model_uri, "Modelo_Demanda_Energia")

print(f"Modelo registrado: {registered_model.name} Versión: {registered_model.version}")

Una vez registrado, el modelo aparece como un artefacto más en el Workspace. Desde ahí, podemos generar un informe de Power BI que llame a este modelo para predecir valores futuros basándose en los datos actuales del Lakehouse. Es la integración total entre el mundo del BI y el Data Science.

Errores frecuentes en proyectos de ML en Fabric

• No limpiar metadatos de Delta: Los experimentos generan muchos datos temporales. No realizar una limpieza de versiones antiguas con VACUUM puede disparar los costes de almacenamiento innecesariamente.
• Sobrecarga del Spark Driver: Intentar procesar grandes volúmenes con librerías no distribuidas (como Scikit-Learn puro) en lugar de aprovechar SynapseML o Spark ML.
• Ignorar el linaje: No conectar el experimento con la tabla de origen, lo que impide saber si el modelo se entrenó con datos actualizados o con una foto fija obsoleta.
• Falta de monitoreo de capacidad: Los Notebooks consumen unidades de capacidad (CU). Un bucle mal diseñado en Python puede agotar la capacidad del Workspace y detener los refrescos de Power BI.

Conclusión y Checklist

Implementar Data Science en Microsoft Fabric requiere un cambio de mentalidad. Ya no somos islas tecnológicas; somos parte de un ecosistema donde la arquitectura del dato (Lakehouse vs Warehouse) influye directamente en la eficiencia del modelo. Para profundizar en esta elección, recomiendo leer sobre Lakehouse vs Data Warehouse en Microsoft Fabric antes de empezar a ingestar datos para entrenamiento.

Checklist de implementación:

• [ ] Datos validados y limpios en la capa ‘Oro’ del Lakehouse.
• [ ] Experimento de MLflow creado con autolog habilitado.
• [ ] Evaluación de métricas comparativa realizada en la interfaz de Fabric.
• [ ] Modelo registrado con versionado claro en el Model Registry.
• [ ] Inferencia probada mediante la función PREDICT en SQL o Power BI.

Preguntas frecuentes

¿Es necesario saber Spark para hacer Data Science en Fabric?

No es estrictamente obligatorio para datasets pequeños, ya que puedes usar Pandas. Sin embargo, para entornos empresariales con grandes volúmenes, conocer Spark y SynapseML es la única forma de garantizar la escalabilidad y el rendimiento del sistema.

¿Puedo usar mis librerías personalizadas de Python?

Sí, Fabric permite crear ‘Environments’ donde puedes instalar librerías específicas mediante archivos YAML o desde el gestor de librerías del Workspace, asegurando que todos los Notebooks usen las mismas versiones de paquetes.

¿Cómo se factura el uso de Data Science en Fabric?

El consumo se basa en las Unidades de Capacidad (CU) asignadas a tu capacidad de Fabric. Tanto la ejecución de Notebooks como la inferencia de modelos consumen estas unidades de forma dinámica durante su ejecución.