Preparación de datos para aprendizaje automático en el Lakehouse de Microsoft Fabric
En la consultoría de Business Intelligence, solemos centrar nuestros esfuerzos en la limpieza y el modelado en estrella para facilitar la analítica descriptiva. Sin embargo, cuando un proyecto en Microsoft Fabric evoluciona hacia el aprendizaje automático (Machine Learning), las reglas del juego cambian drásticamente. No basta con tener datos limpios; necesitamos datos estructurados para el entrenamiento que respeten la cronología de los eventos y eviten errores metodológicos que invaliden el modelo antes de llegar a producción.
El error más común que veo en implementaciones de Fabric es intentar alimentar un modelo de ML directamente desde las tablas de la capa Gold diseñadas para Power BI. Esas tablas están optimizadas para agregaciones y filtros rápidos, no para capturar el estado de una entidad en un punto exacto del pasado. Si no adaptamos nuestra arquitectura en el Lakehouse, acabaremos con modelos que prometen una precisión del 99% en desarrollo pero fallan estrepitosamente al enfrentarse a datos reales.
En este artículo abordamos cómo transformar la lógica de negocio en conjuntos de entrenamiento robustos, centrándonos en el particionado temporal, la prevención de la fuga de datos (data leakage) y el uso eficiente de Notebooks para la ingeniería de características.
Del modelo dimensional al conjunto de entrenamiento
Un modelo dimensional clásico (Kimball) busca eliminar la redundancia y facilitar la navegación. Para el aprendizaje automático, buscamos lo contrario: la desnormalización controlada. Necesitamos una tabla plana (o un conjunto de ellas) donde cada fila represente una observación y cada columna sea una característica (feature) conocida en el momento de la predicción.
Si ya has seguido nuestra Guía Práctica: Creando un Lakehouse en Microsoft Fabric, sabrás que la capa Silver es el lugar ideal para realizar estas transformaciones. Mientras que para Power BI crearíamos una dimensión Cliente y una tabla de hechos Ventas, para un modelo de predicción de abandono (Churn) necesitamos una foto fija de cada cliente mes a mes, incluyendo su comportamiento histórico acumulado hasta ese momento.
El desafío aquí es el rendimiento. Transformar millones de filas de transacciones en vectores de características requiere una capacidad de cómputo que el motor de SQL de Fabric puede manejar, pero que a menudo es más flexible resolver mediante Spark Notebooks, especialmente cuando necesitamos funciones de ventana complejas o transformaciones estadísticas avanzadas.
El peligro de la fuga de datos (Data Leakage)
La fuga de datos ocurre cuando el conjunto de entrenamiento contiene información que no estará disponible en el momento en que el modelo deba realizar una predicción real. Es el equivalente a dejar que un estudiante vea las respuestas del examen mientras estudia.
En entornos de retail o industria, esto suele suceder por tres motivos principales:
- Inclusión de variables futuras: Usar el total de ventas anuales para predecir si un cliente comprará en marzo.
- Estadísticas globales: Normalizar una variable (como el precio medio) usando el máximo y el mínimo de todo el dataset en lugar de usar solo los datos disponibles hasta la fecha de la observación.
- Identificadores con significado: Usar IDs correlacionados con el tiempo o el resultado que el modelo puede memorizar.
Para evitar esto en Fabric, es imperativo diseñar un proceso de ingeniería de características que sea ciego al futuro. Si estamos prediciendo la demanda de energía para mañana, nuestras variables solo pueden nutrirse de datos históricos cerrados hasta hoy a las 23:59. Cualquier dato posterior inyectado en el set de entrenamiento inflará artificialmente las métricas de rendimiento del modelo.
Particionado temporal: Por qué el muestreo aleatorio no sirve
La mayoría de los tutoriales básicos de ciencia de datos sugieren usar train_test_split de Scikit-Learn con un muestreo aleatorio. En Business Intelligence, esto suele ser un error grave. Los datos de negocio tienen dependencias temporales: las ventas de diciembre dependen de las de noviembre y de la estacionalidad anual.
Si realizas un muestreo aleatorio, el modelo «verá» días de 2024 para predecir días de 2023. Esto no es una predicción, es una interpolación. La estrategia correcta en el Lakehouse es el Time-Series Split o particionado por bloques temporales. Debemos entrenar con el pasado y validar con el futuro más reciente.
# Ejemplo de particionado temporal en un Notebook de Fabric
from pyspark.sql import functions as F
# Supongamos una tabla de ventas en el Lakehouse
df_ventas = spark.read.table("lh_ventas_silver")
# Definimos el punto de corte (ej. los últimos 3 meses para test)
fecha_corte = "2023-10-01"
train_df = df_ventas.filter(F.col("Fecha") < fecha_corte)
test_df = df_ventas.filter(F.col("Fecha") >= fecha_corte)
print(f"Registros entrenamiento: {train_df.count()}")
print(f"Registros test: {test_df.count()}")Esta estructura garantiza que el modelo se evalúe en condiciones reales. Además, al trabajar con grandes volúmenes de datos, es fundamental considerar las Estrategias para escalar Microsoft Fabric para asegurar que estas particiones no penalicen el tiempo de ejecución del Notebook.
Ingeniería de características con Spark y SQL
La ingeniería de características es el proceso de crear nuevas variables que ayuden al modelo a entender el problema. En un entorno de fabricación, esto podría ser la media móvil de la temperatura de una máquina en las últimas 4 horas. En retail, el número de veces que un cliente ha devuelto un producto en el último trimestre.
En Microsoft Fabric, tenemos la ventaja de poder combinar el motor de Spark con la potencia de las consultas Delta. Si vienes del mundo de Power Query, te interesará revisar el Plegado de consultas en Power Query para entender cómo Fabric intenta empujar el trabajo hacia el origen, aunque para ML masivo, Spark suele ser la opción más eficiente debido a su capacidad de paralelización nativa.
-- Ejemplo de creación de características temporales usando SQL en el Lakehouse
CREATE OR REPLACE TABLE Gold_ML_Features AS
SELECT
ClienteID,
Fecha,
Importe,
-- Media móvil de los últimos 3 meses
AVG(Importe) OVER (
PARTITION BY ClienteID
ORDER BY UNIX_DATE(Fecha)
RANGE BETWEEN 90 PRECEDING AND 1 PRECEDING
) AS Media_Importe_3M,
-- Días desde la última compra
DATEDIFF(Fecha, LAG(Fecha) OVER (PARTITION BY ClienteID ORDER BY Fecha)) AS Dias_Desde_Ultima_Venta
FROM Silver_Ventas;Este enfoque permite que los analistas que dominan SQL puedan contribuir directamente al pipeline de Machine Learning sin necesidad de ser expertos en Python. Además, si estamos trabajando con fuentes externas o sistemas legados, podemos aprovechar el Consumo de bases de datos espejadas en Fabric con Notebooks y SQL para integrar datos en tiempo real en nuestras características.
Comparativa de herramientas para preparación de datos
No siempre está claro qué herramienta usar dentro del ecosistema Fabric para preparar estos datasets. La siguiente tabla resume los criterios de decisión basados en mi experiencia en proyectos reales:
| Criterio | Data Factory (Pipelines) | Power Query (Dataflows Gen2) | Spark Notebooks |
|---|---|---|---|
| Volumen de datos | Muy alto (Orquestación) | Bajo / Medio | Muy alto (Transformación) |
| Complejidad lógica | Baja (ETL lineal) | Media (UI amigable) | Muy alta (Python/Scala/R) |
| Funciones de ML | Nula | Básica | Nativa (MLlib, Scikit-learn) |
| Perfil de usuario | Ingeniero de datos | Analista de BI | Científico de datos |
Para la mayoría de los casos de ML en Fabric, el flujo recomendado es orquestar con Data Factory, pero ejecutar la lógica pesada en Notebooks. El uso de Dataflows Gen2 es excelente para la ingesta rápida, pero suele quedarse corto cuando necesitamos validaciones cruzadas o transformaciones matriciales.
Errores frecuentes en la preparación de datos para ML
Tras años auditando modelos, estos son los fallos que más dinero cuestan a las empresas por decisiones basadas en datos incorrectos:
- Ignorar los nulos con significado: En BI solemos filtrar los nulos o ponerlos como «N/A». En ML, que un dato falte puede ser una señal en sí misma (ej. un cliente que no rellena su perfil tiene un comportamiento distinto).
- No reescalar variables: Los modelos basados en gradiente (como las redes neuronales o la regresión logística) sufren si una variable tiene un rango de 0 a 1 y otra de 0 a 1.000.000.
- Confundir correlación con causalidad en las features: Incluir variables que son consecuencia del evento que queremos predecir, no su causa.
- No versionar el dataset: Entrenar un modelo hoy y no poder reproducir exactamente el mismo dataset mañana porque los datos de origen en el Lakehouse han cambiado (aquí es donde entra en juego el Time Travel de Delta Lake).
Checklist de preparación para producción
- ¿Se ha separado el conjunto de test respetando la cronología temporal?
- ¿Se han eliminado todas las columnas que contienen información del «futuro» respecto a la observación?
- ¿Están los tipos de datos optimizados para el consumo (ej. floats de 32 bits en lugar de doubles si la precisión lo permite)?
- ¿Se ha verificado el linaje de datos desde el origen hasta el set de entrenamiento?
- ¿Se han manejado los valores atípicos (outliers) de forma coherente con la lógica de negocio?
Preguntas frecuentes
¿Puedo usar el SQL Endpoint del Lakehouse para entrenar modelos?
Sí, puedes usar el SQL Endpoint para consultas rápidas y validación de datos, pero para el entrenamiento masivo es preferible usar Spark. El SQL Endpoint tiene limitaciones de concurrencia y no soporta todas las librerías de ciencia de datos que sí están integradas en los runtimes de Spark en Fabric.
¿Cómo manejo la estacionalidad en mis datos de entrenamiento?
La mejor forma es crear características explícitas: componentes de seno y coseno para el día del año, indicadores de festivos o variables booleanas de «fin de semana». No confíes en que el modelo detecte la estacionalidad solo con una columna de fecha en formato texto.
¿Es mejor normalizar los datos en el Lakehouse o dentro del modelo?
Mi recomendación es realizar las transformaciones de negocio en el Lakehouse (capa Gold) y las transformaciones puramente estadísticas (como el escalado o el One-Hot Encoding) dentro del pipeline del modelo (usando Scikit-learn Pipelines o Spark ML). Esto facilita que el modelo sea portable y que los datos en el Lakehouse sigan siendo legibles por humanos.
¿Qué impacto tiene el tamaño de los archivos Parquet en el rendimiento de ML?
Un impacto crítico. Archivos demasiado pequeños provocan el problema del «small file syndrome», ralentizando la lectura en Spark. Asegúrate de ejecutar operaciones de V-Order u OPTIMIZE en tus tablas Delta de Fabric antes de iniciar procesos de entrenamiento intensivos.
