En Microsoft Fabric ya disponíamos de dos almacenes de datos, el lakehouse y el warehouse. Como no podía ser de otra manera, aparece otro house, el Eventhouse 🙂

El Eventhouse es un componente fundamental para gestionar y procesar datos en tiempo real. Es compatible con datos no estructurados, semi-estructurados y estructurados. Esencialmente, proporciona una estructura optimizada para manejar flujos de eventos muy continuos, lo que es crucial en aplicaciones que dependen de los datos en tiempo real, como la detección de fraudes o en monitorización de IoT.

Características principales

Optimizado para el flujo de datos sin intervención del usuario

Eventhouse está diseñado para ingerir datos en tiempo real de forma muy eficiente, con un almacenamiento optimizado para mantener una latencia mínima. No se requiere configuración adicional para optimizar o mejorar el rendimiento; basta con crearlo para que esté disponible y listo para su uso.

Serverless

Eventhouse está diseñado para optimizar costos al suspender automáticamente el servicio cuando no está en uso. Esto significa que, cuando no hay flujo de datos entrante, el servicio se suspende temporalmente. Al reactivarse, podría experimentarse una latencia de unos segundos. Para entornos donde esta latencia es crítica, se recomienda habilitar la configuración de consumo mínimo, lo cual garantiza que el servicio esté siempre activo en un nivel mínimo predefinido hasta que se reanude el flujo de datos y se restaure el consumo estándar. La siguiente imagen muestra los diferentes niveles de consumo mínimo disponibles:

Hot y Cold caché

Eventhouse dispone de dos modos de almacenamiento de los datos: almacenamiento en caché y almacenamiento estándar. Para garantizar un rendimiento rápido en las consultas, se utiliza el sistema de caché o hot tier, que guardan los datos en el almacenamiento SSD o incluso en RAM. Eso sí, lo que te da por un lado, te lo quita por el otro. Al tener los datos en caché, se pagará más por el alojamiento. Este nivel de almacenamiento es comparable al nivel premium de Azure Data Lake Storage.

Los datos que se encuentren en el almacenamiento estándar o cold tier, serán más baratos pero su acceso será más lento. Aquí lo importante es definir una buena directiva de caché para mover al almacenamiento estándar aquellos datos que no se van a analizar con frecuencia o no son tan críticos, y mantener en caché aquellos que son cruciales para su análisis y son lo más cercano a tiempo real.

Directivas de retención de datos y caché

La directiva de retención de datos elimina de manera automática los datos de tablas o vistas materializadas, lo cual resulta especialmente útil para borrar datos cuya relevancia disminuye con el tiempo.

La implementación de una directiva de retención es esencial al ingerir datos de manera continua, ya que permite gestionar costos eficientemente. Los datos que exceden del periodo definido por la directiva de retención se consideran elegibles para eliminación. Sin embargo, no existe una garantía exacta sobre cuándo se llevará a cabo dicha eliminación; los datos pueden permanecer incluso después de que se active la directiva.

La política de caché permite especificar qué datos deben mantenerse en caché, diferenciando entre datos calientes y fríos. Al establecer una política de caché para los datos calientes, estos se guardan en almacenamiento local SSD, lo cual acelera las consultas, mientras que los datos fríos permanecen en un almacenamiento estándar, que resulta más económico pero con un acceso más lento.

El rendimiento óptimo de las consultas se alcanza cuando todos los datos ingeridos están en caché. Sin embargo, no todos los datos justifican el costo de mantenerse en caché.

Base de datos KQL

Eventhouse trabaja con bases de datos KQL. Una base de datos KQL es un tipo de base de datos optimizada para el análisis de grandes volúmenes de datos en tiempo real, utilizando Kusto Query Language (KQL), que es un lenguaje de consulta desarrollado por Microsoft para trabajar con grandes volúmenes de datos, especialmente en contextos de análisis en tiempo real. Fue creado para interactuar con bases de datos como Azure Data Explorer y ahora con Microsoft Fabric, que están diseñadas para almacenar y analizar datos masivos de series temporales, eventos de telemetría, registros de aplicaciones y otros datos generados en tiempo real.

Un Eventhouse puede contener varias bases de datos KQL.

Para realizar consultas sobre los datos de una base de datos KQL se utilizan las KQL Queryset con el lenguage Kusto Query Language.

Disponibilidad en OneLake

Una de las características más importantes de KQL es la de la disponibilidad en OneLake. Activando esta característica, los datos de KQL están disponibles en OneLake y se pueden consultar los datos en formato Delta Lake mediante otros motores de Fabric, como Direct Lake en Power BI, Warehouse, Lakehouse, Notebooks, etc.

También tienes la posibilidad de crear un acceso directo de OneLake desde un Lakehouse o Warehouse.

Hay que tener en cuenta que esta característica evita escribir muchos archivos Parquet pequeños, lo que puede retrasar las operaciones de escritura horas si no hay suficientes datos para crear archivos Parquet óptimos. Esto garantiza que los archivos Parquet sean óptimos en tamaño y no haya problemas de rendimiento a la hora de consultarlos.

Acceso directo (shortcut)

Los accesos directos son referencias dentro de OneLake que apuntan a ubicaciones de otros archivos sin mover los datos originales. En una base de datos KQL también se pueden crear accesos directos que apunten a orígenes externos o internos de Fabric.

Una vez creado el acceso directo, en la consulta de datos se hace referencia a él mediante la función external_table()

Actualmente, los accesos directos permitidos son:

OneLake

Azure Data Lake Storage Gen2

Amazon S3

Dataverse

Google Cloud Storage

¿Por qué no lakehouse?

En un eventstream podemos seleccionar entre un Lakehouse o un Eventhouse como destino de datos, donde siempre aparece la duda cual elegir en un proyecto de tiempo real. Hay que tener en cuenta varias cosas si elegimos Lakehouse como destino:

Configuración

En el eventstream deberemos configurar el rendimiento del lakehouse como destino desde la pestaña avanzada

En esta parte debemos configurar como se van a escribir los ficheros en la tabla delta.

Mínimo de filas: Se especifica el número de filas como mínimo que se ingerirá en un único archivo. El valor mínimo es 1 y el máximo es de 2 millones por archivo. Cuanto menor sea el número, más archivos se crearán durante la ingesta.
Duración máxima: Se especifica la duración máxima que se tarda en ingerir datos en un archivo. El mínimo es de 1 minuto y el máximo es de 2 horas. Cuanto mayor sea la duración, más fila se ingerirán en un archivo.

Optimización / Mantenimiento

Cuando se ha completado la configuración, en el lakehouse aparecerá un botón para crear un notebook y optimizar la tabla delta del Lakehouse

¿Por qué ocurre esto? Esto es debido a que, aún configurando lo mejor que podamos el lakehouse como destino, se van a crear muchos ficheros parquet y esto provoca un mal rendimiento sobre la tabla delta. Para ello, este notebook realiza una optimización para compactar los ficheros pequeños y mejorar el rendimiento.

# Run the below script or schedule it to run regularly to optimize your Lakehouse table 'tickets'
from delta.tables import *
deltaTable = DeltaTable.forName(spark, "tickets")
deltaTable.optimize().executeCompaction()
# If you only want to optimize a subset of your data, you can specify an optional partition predicate. For example:
#
#     from datetime import datetime, timedelta
#     startDate = (datetime.now() - timedelta(days=3)).strftime('%Y-%m-%d')
#     deltaTable.optimize().where("date > '{}'".format(startDate)).executeCompaction()

Además de realizar la compactación con el comando optimize, también se deberá ejecutar el comando vacuum para limpiar aquellos ficheros que no hacen referencia a la tabla delta.

Conclusión

Lakehouse en algunas ocasiones puede ser un destino válido para tiempo real (Spark Structured Streaming) pero poniendo todas las cartas sobre la mesa, el destino ideal es el Eventhouse. Además de todo lo expuesto anteriormente, a la hora de analizar los datos, con Lakehouse debes hacerlo con Direct Lake, y si es un escenario que se necesita una baja latencia y análisis al segundo, no lo veo viable puesto que hay cierto delay en la actualizando de datos, provocado en cierta medida por los puntos anteriores de configuración y optimización. Además, a lo largo del tiempo se va a almacenar mucha información histórica que realmente no es necesaria para su análisis, ya que, se estaría analizando en tiempo real con datos históricos que no son relevantes.

Por otro lado, Eventhouse te permite analizar en Direct Query con un tiempo de respuesta muy bajo aun habiendo gran cantidad de datos en las tablas. También te permite crear shortcuts a tablas de un Lakehouse y crear un escenario híbrido con dimensiones en Import y los hechos en tiempo real en Direct Query contra la base de datos KQL. Incluso se puede aprovechar la potencia de los cuadros de mando en tiempo real, ya que sus gráficos son el resultado de una consulta KQL sobre la tabla, consiguiendo una actualización rapidísima de los datos y una evolución fluida de los gráficos.