Datos de Eventhouse a OneLake: integración real en Microsoft Fabric

En el despliegue de soluciones analíticas modernas, uno de los mayores problemas es la fragmentación. Por un lado, tenemos los datos de telemetría, logs y sensores fluyendo hacia motores de tiempo real (KQL); por otro, los datos maestros y transaccionales descansando en el Lakehouse o Warehouse. Hasta ahora, unir estos dos mundos implicaba procesos de ETL redundantes que aumentaban la latencia y el coste. Con la funcionalidad de disponibilidad en OneLake de Eventhouse en Microsoft Fabric, esta barrera desaparece.

Habilitar esta opción no es simplemente marcar un checkbox. Implica entender cómo Fabric gestiona los metadatos y cómo el motor de Kusto convierte internamente sus fragmentos de datos en archivos Delta Parquet legibles por el resto del ecosistema. Como consultor, mi prioridad no es solo que el dato llegue, sino que sea eficiente. No tiene sentido exponer trillones de filas de logs si no hay un caso de negocio que justifique el coste de computación de esa conversión en segundo plano.

En este artículo analizaremos cómo configurar esta exposición, qué ocurre bajo el capó y cómo consultar estos datos desde Spark y SQL para unirlos con nuestras dimensiones de negocio. Si quieres profundizar en la base de esta arquitectura, te recomiendo revisar OneLake y el ecosistema de Microsoft Fabric: Novedades y su impacto técnico real.

¿Qué es la disponibilidad en OneLake para Eventhouse?

La disponibilidad en OneLake (OneLake availability) es una característica de las bases de datos KQL en Fabric que permite que las tablas almacenadas en el motor de Real-Time Intelligence se reflejen automáticamente como tablas Delta en OneLake. Esto permite que herramientas que no hablan KQL, como los notebooks de Spark, los Power BI Semantic Models en modo Direct Lake o el motor de SQL analítico, puedan leer esos datos sin que el usuario tenga que moverlos manualmente.

Es fundamental entender que el almacenamiento primario sigue siendo el motor de KQL. El sistema crea una «vista» de esos datos en formato Delta. Esta duplicación lógica es transparente para el usuario, pero consume recursos de computación de la capacidad de Fabric, ya que el motor debe empaquetar los datos entrantes en archivos Parquet y generar los logs de transacciones Delta correspondientes.

En proyectos de industria o energía, donde manejamos miles de señales por segundo, esta característica permite que el equipo de ciencia de datos use Python en un notebook para entrenar modelos sobre datos que acaban de entrar hace escasos minutos, integrándolos con tablas de activos (Assets) que residen en un Lakehouse estándar.

Configuración y activación del mirroring

Para activar esta funcionalidad, tenemos dos niveles de control: a nivel de base de datos y a nivel de tabla. Mi recomendación técnica es habilitarla a nivel de base de datos solo si vas a consumir la mayoría de las tablas, de lo contrario, hazlo de forma granular para optimizar el uso de la capacidad.

1. Accede a tu KQL Database dentro del Eventhouse.
2. En el menú de configuración, activa el interruptor de «OneLake availability».
3. Si prefieres control granular, usa comandos de control (.alter table) para activar o desactivar la exposición de tablas específicas.

Una vez activado, verás que en el explorador de archivos de OneLake (o mediante el OneLake File Explorer) aparece una estructura de carpetas que representa tu base de datos KQL y sus tablas. Cada tabla expuesta contendrá los archivos _delta_log y los archivos .parquet.

Consultando datos desde Spark y SQL

Una vez que los datos de Eventhouse están en OneLake, se vuelven ciudadanos de primera clase en el ecosistema. Esto es especialmente útil para enriquecer datos de telemetría con dimensiones Kimball tradicionales. Por ejemplo, podemos unir una tabla de TelemetriaSensores (en Eventhouse) con una tabla de MaestroMaquinaria (en Lakehouse).

Lectura desde un Notebook de Spark

En un entorno de ingeniería de datos, es habitual usar Spark para transformaciones pesadas. Al estar en formato Delta, la lectura es directa:

# Definición de la ruta en OneLake
# El formato suele ser: abfss://workspace@onelake.dfs.fabric.microsoft.com/KQLDatabase.Kusto/Tables/TelemetriaSensores

path = "abfss://MiWorkspace@onelake.dfs.fabric.microsoft.com/MiKQLDB.Kusto/Tables/VentasRealTime"

# Lectura del dataframe
df_ventas = spark.read.format("delta").load(path)

# Filtrado y agregación
resumen_ventas = df_ventas.filter("Importe > 100") \
 .groupBy("ID_Tienda") \
 .sum("Importe")

display(resumen_ventas)

Este enfoque es ideal para escenarios de Machine Learning. Si necesitas preparar estos datos para modelos predictivos, consulta nuestro artículo sobre Preparación de datos para aprendizaje automático en el Lakehouse de Microsoft Fabric.

Lectura desde SQL Analytics Endpoint

Si prefieres el stack de SQL, puedes crear un shortcut en tu Lakehouse que apunte a la carpeta de la tabla en OneLake. Una vez creado el shortcut, el motor de SQL de Fabric lo tratará como una tabla más, permitiendo joins complejos:

-- Consulta uniendo datos de Eventhouse (vía shortcut) con tablas locales
SELECT 
 t.NombreTienda,
 SUM(v.Importe) AS TotalVentasRealTime
FROM [MiLakehouse].[dbo].[Tiendas] t
INNER JOIN [MiLakehouse].[dbo].[Shortcut_VentasRealTime] v 
 ON t.ID_Tienda = v.ID_Tienda
WHERE v.Fecha >= CAST(GETDATE() AS DATE)
GROUP BY t.NombreTienda;

Consideraciones de coste y rendimiento

No todo es gratuito en términos de rendimiento. La exposición de datos a OneLake conlleva un proceso de «re-empaquetado». Kusto optimiza los datos para búsquedas indexadas y comprimidas en su propio formato, mientras que OneLake requiere Delta Parquet. Este proceso de conversión consume unidades de capacidad (CU) de Fabric.

En mis proyectos, he observado que el retraso (latency) entre que un dato entra en KQL y está disponible en OneLake suele oscilar entre 1 y 5 minutos, dependiendo del volumen de datos y la presión sobre la capacidad. No es tiempo real puro (sub-segundo), pero es suficiente para la inmensa mayoría de casos de uso analíticos.

Si el volumen de ingestión es extremadamente alto y la cardinalidad de las columnas es salvaje, el proceso de conversión a Delta puede volverse costoso. En esos casos, es preferible pre-agregar los datos en KQL usando Materialized Views y exponer solo la vista materializada a OneLake. Para aprender más sobre cómo optimizar estas consultas antes de exponerlas, puedes leer sobre KQL en Microsoft Fabric: parse, extract y optimización de datos dinámicos.

Errores frecuentes en la implementación

• Ignorar el esquema: KQL es muy flexible con los datos dinámicos (tipo dynamic). Sin embargo, al exportar a Delta, si no defines bien el esquema o no parseas los JSON, podrías acabar con columnas de tipo string masivas que degradan el rendimiento en Spark/SQL.
• No monitorizar las Capacity Metrics: El proceso de escritura en OneLake es una carga de fondo. Si tu capacidad está al 90%, este proceso se ralentizará, aumentando la latencia de los datos en el lago.
• Intentar escribir desde OneLake: Los datos expuestos por Eventhouse en OneLake son de solo lectura. No intentes realizar un UPDATE o DELETE desde Spark sobre esas carpetas; corromperás los metadatos de sincronización.
• Exponer tablas de staging: Evita marcar la disponibilidad en tablas temporales de ingesta. Solo expón tablas finales o refinadas para ahorrar costes de procesamiento.

Estrategia recomendada para arquitecturas híbridas

En el sector público o en grandes retail, solemos aplicar un patrón de «doble vía». Los cuadros de mando operativos, que necesitan saber qué está pasando ahora mismo (ej. stock en estantería), atacan directamente al motor de KQL mediante KQL Querysets. Los cuadros de mando tácticos o estratégicos, que comparan el hoy con el histórico de los últimos 5 años, atacan al Lakehouse donde los datos de Eventhouse están integrados vía OneLake.

Este enfoque respeta la naturaleza de cada motor. No fuerces a SQL a hacer el trabajo de Kusto, ni pidas a Kusto que gestione relaciones de integridad referencial complejas que el Warehouse maneja mejor. La clave está en el Shortcutting. No copies datos. Si necesitas los datos de una exportación previa de SQL para comparar, recuerda que hay métodos eficientes como se explica en Exportación de SQL Server a archivos de texto: eficiencia frente a complejidad, aunque en Fabric lo ideal es mantener todo en formato Delta siempre que sea posible.

Por último, recuerda la importancia del gobierno. Al exponer tablas de Eventhouse a OneLake, estás abriendo la puerta a que usuarios de otros workspaces puedan acceder a esos datos mediante shortcuts. Asegúrate de que las etiquetas de sensibilidad y los permisos de OneLake están alineados con las políticas de tu organización. Para profundizar en esto, consulta Gobierno de datos para IA generativa en Microsoft Fabric: Calidad y Trazabilidad.

Checklist de implementación

• Verificar que la capacidad de Fabric tiene recursos suficientes (Monitor de Capacidad).
• Identificar qué tablas de la KQL Database requieren ser consumidas por Spark/SQL/Power BI.
• Habilitar «OneLake availability» solo en las tablas seleccionadas (o a nivel de DB si es necesario).
• Validar la latencia de aparición de archivos Parquet en el OneLake File Explorer.
• Configurar shortcuts en el Lakehouse o Warehouse de destino para facilitar el acceso a los analistas.

Preguntas frecuentes

¿Los datos en OneLake ocupan el doble de espacio?

Técnicamente, sí hay una duplicación del almacenamiento físico (el formato nativo de Kusto y el formato Delta Parquet). Sin embargo, el almacenamiento en OneLake es extremadamente económico comparado con el coste de computación, por lo que el impacto en la factura suele ser despreciable frente al beneficio de la integración.

¿Puedo usar Direct Lake de Power BI con estas tablas?

Sí, una vez que la tabla está disponible en OneLake y has creado un shortcut en un Lakehouse, puedes incluir esa tabla en un modelo semántico de Power BI y utilizar el modo Direct Lake. Esto ofrece un rendimiento excepcional al evitar el modo Import o DirectQuery tradicional.

¿Qué pasa si cambio el esquema de la tabla en KQL?

El proceso de disponibilidad en OneLake admite cierta evolución del esquema, como añadir columnas. Sin embargo, cambios disruptivos (como cambiar el tipo de datos de una columna) pueden requerir que desactives y vuelvas a activar la disponibilidad para regenerar los metadatos Delta correctamente.

¿Es compatible con tablas externas de KQL?

No, la disponibilidad en OneLake solo funciona para tablas nativas (tablas que almacenan datos dentro del motor de Kusto). Las tablas externas, que ya apuntan a archivos fuera de Kusto, no se vuelven a exponer.