Empezar con Real-Time Intelligence en Microsoft Fabric

¿Qué te enseña este módulo?

Este es el módulo de introducción a Real-Time Intelligence (RTI) — la parte más "diferente" de Fabric respecto a lo que hemos visto hasta ahora. Los objetivos oficiales:

1. Describir el real-time analytics, los streams y los events.
2. Entender los componentes de RTI en Fabric.
3. Ingestar y transformar datos en movimiento.
4. Almacenar y consultar datos en KQL databases.
5. Visualizar datos en streaming con Real-Time Dashboards.
6. Automatizar acciones con Activator.

Peso en el examen DP-700

Real-Time Intelligence aparece en los tres dominios, especialmente en el Dominio 2 (Ingest and transform) y en el Dominio 3 (Monitor and optimize):

Definición

Real-time analytics = la práctica de procesar, analizar y actuar sobre los datos según se generan, típicamente en segundos o minutos desde que ocurren los eventos.

A diferencia de la analítica tradicional (batch), que trabaja con snapshots históricos almacenados en bases de datos, la analítica en tiempo real opera sobre datos que fluyen activamente por tus sistemas.

Near real-time (matiz importante)

En realidad se llama near real-time analytics porque siempre hay cierta latencia de procesamiento y de red. No es 0 ms.

• Sub-segundo: milisegundos → real-time "real".
• 1-10 segundos: near real-time típico.
• Minutos: near real-time relajado.
• Horas o días: ya es batch.

Cuándo es útil el real-time

• ⚡ Responder inmediatamente a oportunidades o problemas.
• 🎯 Optimizar operaciones con datos actuales.
• 👤 Mejorar la experiencia de cliente con interacciones contextuales.
• 🛡️ Prevenir incidencias detectando anomalías antes de que sean crisis.

Casos de uso típicos

• 🚚 Seguimiento de entregas: alertar cuando los paquetes se retrasan.
• 🌡️ Monitorización de equipos: temperatura de las máquinas para prevenir fallos.
• 🕵️ Detección de fraude: bloquear transacciones sospechosas al instante.
• 🌐 Rendimiento web: monitorizar los tiempos de carga.
• 💚 Salud del sistema: errores de aplicación, fiabilidad del servicio.

Batch vs Real-time (comparativa mental)

Ambos son válidos y coexisten. No es "elegir uno": muchas empresas usan batch para BI y real-time para la monitorización operacional.

Events (eventos)

Un event es un registro de algo que ocurrió en un sistema. Captura un momento en el que algo ocurre, cambia o se completa.

Ejemplos: 🖱️ un click en una web, 📈 un cambio en el precio de una acción, 🛒 la compra de un cliente, 💓 un cambio en los signos vitales de un paciente, 🌡️ la lectura de un sensor.

Piénsalos como registros digitales o entradas de log que documentan la actividad de tus sistemas.

Streams (flujos)

Un stream es una secuencia de events, típicamente ordenados por la hora del evento. Cada evento del stream representa algo que ocurrió en un momento concreto, y los eventos fluyen continuamente por el stream según ocurren.

Ejemplo: un stream de temperatura de un sensor de equipamiento contiene lecturas de temperatura en muchos puntos del tiempo.

Este flujo continuo te permite detectar patrones a lo largo del tiempo, identificar oportunidades o riesgos y actuar inmediatamente después de que algo pase.

Para construir soluciones en tiempo real necesitas 5 capabilities integradas trabajando juntas:

Ingesta de datos en tiempo real

Recolectar datos de varias fuentes simultáneamente, según se generan. Ejemplos de fuentes: Change Data Capture de bases de datos, sensores IoT, aplicaciones, logs de sistema y APIs.

Stream processing

Transformar y analizar los datos mientras fluyen del origen al destino: filtrado, agregación, joins con otras fuentes y detección de patrones. Todo con latencia mínima, mientras los datos van pasando.

Low-latency storage

Bases de datos y sistemas de almacenamiento especializados para gestionar escrituras de alta velocidad y dar respuestas rápidas a las queries. Los sistemas OLTP normales no funcionan aquí: necesitas motores optimizados para tiempo real (el motor KQL/Kusto).

Dashboards interactivos

Visualizaciones que se actualizan automáticamente según llegan datos nuevos, mostrando el estado actual y las tendencias en tiempo real.

Toma de decisiones automatizada

Reglas y triggers orientados a eventos que pueden iniciar acciones, enviar alertas o lanzar workflows en función de condiciones en tiempo real.

Cómo lo hace Fabric

Real-Time Intelligence trae todo esto en una sola plataforma:

Los 6 componentes principales

RTI en Fabric es un conjunto integrado de componentes que trabajan juntos para gestionar los datos en streaming desde la captura hasta la respuesta automatizada:

1. Eventstreams 🚰 — ingestar datos en streaming de las fuentes, aplicar transformaciones en tiempo real y enrutar los datos a distintos destinos.

2. Eventhouse 🏛️ — contenedor que puede alojar varias KQL databases, compartiendo capacidad y recursos, con monitorización unificada.

3. KQL Database 💾 — almacén de datos optimizado para tiempo real. Contiene tablas, stored functions, materialized views, shortcuts y data streams. Optimizada para series temporales.

4. KQL Queryset 📝 — colecciones de queries KQL. Multi-tab, guardar queries, compartir. Soporta KQL y un subconjunto de T-SQL.

5. Real-Time Dashboard 📊 — conecta directamente a las KQL databases, se refresca automáticamente según llegan los datos y permite drill-down interactivo.

6. Activator 🔔 — acciones automatizadas basadas en eventos, con rules y umbrales, que disparan notificaciones, workflows, pipelines y notebooks.

Y transversalmente, 7. Real-Time Hub 🏢 — catálogo central de datos en streaming, para descubrir sources, azure events y fabric events.

Diagrama mental del flujo

Sistemas origen
  (IoT, apps, CDC, APIs)
        ↓
   Eventstream
   (ingesta + transformación + routing)
        ↓
   ┌────┴────┐
   ↓         ↓
KQL DB    Lakehouse
(Eventhouse)  (Delta)
   ↓
Queryset (KQL)
   ↓
   ┌────┴──────┬─────────┐
   ↓           ↓         ↓
Dashboard  Power BI  Activator
(RTI)      (reports)  (alertas)

¿Qué es?

El Real-Time Hub es la ubicación central donde puedes descubrir y gestionar toda la data-in-motion a la que tienes acceso. Es tu catálogo de datos en streaming: puedes ver qué está pasando en near real-time en toda tu organización.

Acceso

El icono Real-Time del menú principal de Fabric.

Categorías organizadas

A) Data sources — las fuentes de streaming disponibles: Microsoft sources, feeds de CDC y proveedores cloud externos.

B) Azure sources — descubrir y configurar fuentes de streaming de Azure: Azure IoT Hub, Azure Service Bus, Azure Data Explorer DB y muchas más.

C) Fabric events — eventos generados por el propio sistema de Fabric a los que tienes acceso: cambios de estado de jobs (pipelines succeeded/failed), eventos de ficheros y carpetas de OneLake, y cambios en los items del workspace.

D) Azure events — servicios de Azure que pueden disparar respuestas: eventos de Azure Blob Storage y otros.

¿Qué puedes hacer desde el Hub?

• 👀 Previsualizar y explorar los datos en streaming.
• 🔗 Navegar directamente a los eventstreams o KQL databases.
• 🔔 Construir respuestas automatizadas con rules de Activator.
• 📢 Suscribirte a eventos de Azure y de Fabric.

¿Qué es un Eventstream?

Un Eventstream es la forma de traer eventos en tiempo real a Fabric, transformarlos y enrutarlos a un destino. Es el componente de ingesta + procesamiento + routing de RTI.

Los 3 componentes de un Eventstream

1. Sources: de dónde vienen los eventos.
2. Transformations (opcional): el procesamiento aplicado a los datos.
3. Destinations: dónde se envían los datos procesados.

Los vemos uno por uno en la siguiente sección.

Cuándo usar Eventstream

• ✅ Ingesta en streaming con transformaciones declarativas.
• ✅ Cuando quieres enrutar a varios destinos.
• ✅ Cuando necesitas una experiencia low-code / no-code.
• ✅ Para enriquecer y filtrar en tiempo real antes de almacenar.

Cuándo NO usar Eventstream

• ❌ Cuando quieres ingesta directa a KQL sin transformación intermedia.
• ❌ Para transformaciones muy complejas que requieren código PySpark (usa Spark Structured Streaming en su lugar).

Data sources para eventstreams

Cuando creas un eventstream puedes conectarlo a una amplia gama de fuentes:

Microsoft sources: Azure Event Hubs, Azure IoT Hubs, Azure Service Bus, feeds de Change Data Capture (CDC) en servicios de base de datos y otros.

Azure events: eventos de Azure Blob Storage.

Fabric events: cambios en los items de un workspace de Fabric, cambios de datos en los data stores de OneLake y eventos asociados a los jobs de Fabric.

Fuentes externas: Apache Kafka, Google Cloud Pub/Sub y MQTT (Message Queuing Telemetry Transport) (Preview). Y otras de terceros vía conectores.

Transformaciones de eventos

Los datos raw rara vez llegan en el formato que quieres. Las transformaciones hacen que tus datos sean útiles y accionables: puedes transformarlos mientras fluyen para filtrar, resumir y reestructurar antes de almacenarlos.

Data destinations en eventstreams

Los destinos son donde tus datos procesados en tiempo real quedan disponibles para queries, reports, dashboards, alertas y acciones:

• KQL Database en un Eventhouse ✅ (el más común)
• Lakehouse (lo guarda como tabla Delta)
• Derived stream (para encadenar eventstreams)
• Fabric Activator (para triggers automáticos)
• Custom endpoint (para integraciones externas)

🎯 Patrón típico

Azure Event Hub (source)
        ↓
   Filter (descartar eventos inválidos)
        ↓
   Aggregate (suma por ventana de 1 min)
        ↓
   ┌────┴──────────┐
   ↓               ↓
KQL Database    Activator
(análisis)      (alertas)

Un mismo stream puede enrutarse a varios destinos desde el mismo eventstream. Muy potente.

¿Qué es un Eventhouse?

Un Eventhouse es un contenedor que puede alojar varias KQL databases, facilitando gestionar los datos relacionados de un proyecto. Beneficios: gestionar varias databases a la vez, compartir capacidad y recursos y tener monitorización y gestión unificadas a nivel global y por database.

Cuándo crear un Eventhouse

Usa un eventhouse para cualquier escenario con datos basados en eventos: telemetría y logs, series temporales y datos IoT, logs de seguridad y compliance, o registros financieros.

Estructura jerárquica

Eventhouse (contenedor)
├── KQL Database 1
│   ├── Table 1
│   ├── Table 2
│   ├── Stored Functions
│   ├── Materialized Views
│   └── Shortcuts
├── KQL Database 2
│   └── ...
└── Entorno compartido: capacidad, monitorización

Página System overview

La página de system overview de un eventhouse muestra: detalles del eventhouse, advisory findings, storage del eventhouse, recursos del sistema, uso de cómputo, actividad en minutos por aplicación, tasa de ingesta, databases más consultadas, databases con más ingesta y cambios de schema del eventhouse. Útil para la monitorización de salud desde una sola pantalla.

Compute optimizado

Los eventhouses tienen cómputo disponible para analítica en 5-10 segundos, y los recursos crecen con tus necesidades analíticas. Diferencia clave frente a los Spark pools: los pools del Eventhouse son más rápidos en el arranque porque están optimizados para streaming.

¿Qué es una KQL Database?

Una KQL Database es una base de datos optimizada para tiempo real, diseñada para 🕒 datos de series temporales, ⚡ ingesta rápida de datos en streaming y 🔍 queries rápidas sobre grandes volúmenes. Utiliza el motor Kusto, el mismo que Azure Data Explorer.

¿Qué contiene?

• Tables: donde viven los datos.
• Stored functions: lógica de query reutilizable.
• Materialized views: precalculadas para el rendimiento.
• Shortcuts: referencias a datos de otros sitios (como los shortcuts de OneLake).
• Data streams: definiciones de streams.

Integración con OneLake

Las KQL databases se integran con OneLake: los datos pueden estar disponibles en OneLake (vía la feature de OneLake availability) y otras herramientas de Fabric pueden consumirlos.

Standard database vs database shortcut

KQL database estándar: contiene datos propios. Database shortcut: referencia a otra KQL database (a menudo cross-workspace). Ideal para exponer datos sin duplicarlos.

Optimización para series temporales

Las KQL databases indexan los datos por hora de ingesta y los particionan para un rendimiento óptimo de las queries. Diseño perfecto para logs con timestamp, sensores con series temporales, datos de cotizaciones financieras y telemetría de aplicaciones.

Patrones de ingesta

• Streams de alta velocidad: lo optimizado, tu caso normal en RTI.
• Ingesta batch: también soportada (para cargas masivas).

Control de acceso granular

Soporta permisos granulares a nivel de objeto, columna y fila: Row-Level Security (RLS), Column-Level Security (CLS) y Object-Level Security (OLS).

¿Qué es?

Un KQL Queryset es una colección de queries que puedes usar para trabajar con los datos de las tablas de una KQL database. Piénsalo como un editor de queries con features de organización.

Capabilities

• ✅ Guardar queries para uso futuro.
• ✅ Multi-tab: organizar varias pestañas de query.
• ✅ Compartir queries con otros usuarios para colaborar.
• ✅ Soporta KQL y un subconjunto de T-SQL.
• ✅ Ejecutar queries y ver los resultados.
• ✅ Exportar resultados.

Ubicación

Cada KQL database viene con un queryset embebido. También puedes crear querysets standalone en el workspace.

KQL (Kusto Query Language) es el lenguaje para consultar las KQL databases. Es distinto de SQL pero muy intuitivo una vez le pillas el rollo.

Filosofía: pipes 🚰

KQL usa pipes (|) para encadenar operaciones, como bash o PowerShell. Los datos fluyen de una operación a la siguiente.

tabla
| operador1
| operador2
| operador3

Se lee de izquierda a derecha y de arriba a abajo.

Los operadores fundamentales

take — obtener N filas (sin orden garantizado)

stock
| take 10

"Dame 10 filas cualesquiera de stock."

where — filtrar filas

stock
| where symbol == "MSFT"

"Dame las filas donde symbol es 'MSFT'."

project — seleccionar columnas

stock
| project symbol, price, time

"Dame solo las columnas symbol, price y time."

summarize — agregar (equivalente a GROUP BY)

stock
| summarize avgPrice = avg(price) by symbol

"Agrupa por symbol y calcula el precio medio."

sort by / order by — ordenar

stock
| sort by price desc

extend — añadir columnas calculadas

stock
| extend totalValue = price * quantity

join — unir tablas

stock
| join kind=inner (companies) on symbol

Ejemplo end-to-end

stock
| where ["time"] > ago(5m)
| summarize avgPrice = avg(todouble(bidPrice)) by symbol
| project symbol, avgPrice

Traducción: toma la tabla stock, filtra por los eventos de los últimos 5 minutos, agrupa por symbol calculando el precio medio y proyecta solo symbol y avgPrice.

Funciones temporales muy útiles

| where timestamp > ago(1h)        // Última hora
| where timestamp > ago(7d)        // Últimos 7 días
| where timestamp between (datetime(2026-01-01) .. datetime(2026-01-31))

bin() para agrupar por bucket temporal:

stock
| summarize count() by bin(timestamp, 1m)
// Cuenta eventos por minuto

También now(), ago(x), startofday() y endofday().

KQL vs SQL — comparativa mental

Diferencias importantes: KQL usa == para la igualdad (no = como SQL), los strings van entre comillas dobles, los nombres reservados van entre corchetes ["..."] y el flujo de pipes va hacia la izquierda, no anidado como en SQL.

Por qué KQL

• 🚀 Optimizado para datasets grandes de series temporales.
• 🎯 Flujo lineal, más fácil de leer en queries analíticas complejas.
• 🌐 El mismo lenguaje en Azure Data Explorer, Azure Monitor, Log Analytics, Microsoft Sentinel y Fabric.
• 🌸 Kawaii friendly una vez le pillas el flow ✨

Las KQL databases soportan T-SQL

Para quienes ya están familiarizados con T-SQL, las KQL databases soportan un subconjunto de expresiones T-SQL:

SELECT TOP 10 * FROM stock;

Funciona directamente.

Limitaciones

Es un subconjunto, no T-SQL completo. Algunas features avanzadas de T-SQL no están disponibles.

Cuándo elegir cada uno

¿Qué hace?

Microsoft Fabric incluye Copilot para Real-Time Intelligence, que puede escribir queries KQL desde lenguaje natural, ayudar a extraer insights de los datos del Eventhouse, sugerir queries según el schema y explicar queries existentes.

Uso típico

En el editor del KQL Queryset: abres Copilot, describes lo que quieres ("Muéstrame las top 10 ventas del último día por región") y Copilot genera el KQL. Ideal si estás aprendiendo KQL o te bloqueas con la sintaxis.

Feature relacionada: NL2KQL

Natural Language to KQL es la funcionalidad específica que traduce lenguaje natural a KQL. Está integrada en Copilot para RTI.

Más allá de las queries, las KQL databases soportan management commands para automatizar el procesamiento:

Update policies

Las update policies son mecanismos de automatización que se disparan cuando se escriben datos nuevos en una tabla. Ejecutan una query para transformar los datos ingeridos y guardan el resultado en una tabla destino.

Ejemplo de uso: la tabla raw_logs recibe logs sin procesar, la update policy se dispara cuando llegan filas nuevas, transforma (parsea el JSON, extrae campos) y guarda en clean_logs.

Ventaja: automatización por diseño. No necesitas schedules externos.

Materialized views

Las materialized views en KQL precalculan y almacenan resultados para acelerar las queries. Ejemplo: precalcular las agregaciones por hora para los dashboards que las consultan constantemente.

Diferencia con las views normales de SQL: una view de SQL es una query que se ejecuta cada vez; una materialized view es un resultado persistido y actualizado de forma incremental.

⚠️ Muy parecido a las Materialized Lake Views que vimos en el módulo 7, pero específicas de KQL. Ambas siguen la misma filosofía.

Stored functions

Las stored functions guardan lógica de query reutilizable que puedes referenciar desde varias queries.

.create function GetActiveUsers() {
    users
    | where isActive == true
}

Luego, en tus queries:

GetActiveUsers()
| where region == "EU"

Ideal para encapsular la business logic común y evitar el copy-paste.

Cuándo usar cada uno

¿Qué son?

Los Real-Time Dashboards son visualizaciones interactivas que conectan directamente a las KQL databases y se refrescan automáticamente según llegan datos nuevos.

Estructura

Un dashboard es una colección de tiles. Cada tile muestra información basada en una query KQL, con un tipo concreto de visualización (chart, tabla, KPI...) y se puede explorar interactivamente (drill-down, filtro, agregación).

Cómo crearlos

Opción A: desde el workspace → New → Real-Time Dashboard → configurar el origen.

Opción B: desde un KQL queryset de un eventhouse, creándolo directamente.

Personalización de tiles

Por defecto, el resultado de la query se muestra como tabla. Puedes editar el tile para cambiar el tipo de visualización (bar chart, line, pie, KPI...), configurar colores, añadir títulos y etiquetas y dar formato a los números.

Interactividad al publicar

Cuando publicas el dashboard, los tiles permiten drill-down en los datos, filtrado dinámico, agregación interactiva y cambiar el tipo de visualización sobre la marcha.

Auto-refresh

No hay que hacer nada: se refresca automáticamente según llegan datos nuevos a la KQL database. Puedes configurar la frecuencia de refresh por tile o global.

Reports de Power BI sobre KQL

Puedes crear reports de Power BI conectados directamente a los datos de una KQL database.

Casos de uso: usuarios de negocio que ya usan Power BI y quieren ver datos en tiempo real, combinar datos KQL con otros semantic models, y aprovechar features avanzadas de Power BI (RLS, sensitivity labels, bookmarks).

Cómo conectar

Desde el editor de queries KQL → botón Create Power BI report → se abre Power BI Desktop o el Service con la conexión preconfigurada.

Modos de conexión

• DirectQuery: cada query de Power BI se ejecuta contra KQL en tiempo real. Los datos siempre están frescos.
• Import: snapshot de los datos. Menos overhead, pero los datos no son live.

Para reporting en tiempo real, típicamente DirectQuery.

Real-Time Dashboard vs report de Power BI

Suelen coexistir en la misma organización.

¿Qué es Activator?

Activator es la tecnología de Fabric que permite el procesamiento automatizado de eventos que disparan acciones. Ejemplo: notificar por email cuando un valor de un Eventstream se desvía de un rango concreto, o ejecutar un notebook cuando se actualiza un Real-Time Dashboard.

Los 4 conceptos core

1. Events 📬 — cada registro de un stream de datos representa un evento que ocurrió en un momento concreto.

2. Objects 🎯 — los datos de un registro de evento pueden representar un object: un pedido de venta, un sensor u otra entidad de negocio.

3. Properties 🏷️ — los campos de los datos del evento se mapean a propiedades del business object, representando aspectos de su estado. Ejemplo: el campo total_amount → propiedad "total del pedido"; el campo temperature → propiedad "temperatura del sensor".

4. Rules ⚡ — la clave de Activator: definir rules que establecen las condiciones bajo las que se dispara una acción según los valores de las propiedades. Ejemplo: "Si la temperatura del sensor supera los 80 °C, enviar un email al responsable de mantenimiento."

Acciones disponibles

Cuando se cumple una rule, Activator puede 📧 enviar notificaciones (email, Teams), ⚡ disparar workflows en Power Automate, 🚀 ejecutar data pipelines de Fabric y 💻 ejecutar notebooks de Fabric.

Casos de uso reales

• 📉 Acciones de marketing cuando bajan las ventas de un producto.
• 🌡️ Notificaciones cuando la temperatura puede afectar a productos perecederos.
• 🐛 Incidencias en tiempo real que afectan a la experiencia de usuario en las apps.
• 🚚 Alertas cuando un envío no se ha actualizado en el plazo esperado.
• 💰 Alertas cuando el saldo de la cuenta de un cliente cruza un umbral.
• 🐢 Responder a anomalías o fallos en los workflows de procesamiento de datos.
• 📱 Lanzar anuncios cuando caen las ventas de una misma tienda.
• ❄️ Avisar a los responsables de tienda para mover comida de congeladores que fallan antes de que se estropee.

Integración con eventstreams

Activator puede ser el destino de un eventstream. Cuando llega un evento a Activator, se evalúa contra las rules configuradas y, si las cumple, dispara la acción. Este patrón es súper potente para las alertas en tiempo real.

Los 2 approaches oficiales

A) Con Eventstream: source → eventstream → transformaciones → destination.

B) Ingesta directa a la KQL database: source → KQL database directamente.

Ingesta directa a una KQL database

Puedes ingestar datos directamente en una KQL database sin pasar por un eventstream. Fuentes típicas: ficheros locales, Azure Storage, Amazon S3, Azure Event Hubs, OneLake y más. Se configura con conectores o vía la opción Get data de la KQL database.

Cuándo elegir cada uno

Eventstream ✅ cuando necesitas transformaciones durante el streaming, necesitas enrutar a varios destinos, quieres filtrar o enriquecer antes de almacenar, o varios consumidores necesitan los mismos datos.

Ingesta directa a KQL ✅ cuando solo necesitas almacenar los datos de evento raw, no necesitas transformaciones intermedias, la simplicidad es prioritaria, o son cargas masivas / importaciones batch.

Transformaciones en cada modo

Con eventstream: las transformaciones ocurren durante el streaming, antes del routing al destino.

Con ingesta directa: los datos primero aterrizan en la KQL database y luego pueden transformarse con update policies (que se disparan cuando se escriben los datos).

¿Qué es?

La OneLake availability es una feature del Eventhouse que permite que los datos ingeridos en una KQL database estén disponibles en OneLake en formato Delta Parquet. Beneficio: otros workloads de Fabric (Lakehouse, Power BI Direct Lake, notebooks) pueden consultar los datos KQL vía shortcuts u otras técnicas.

Cómo funciona (arquitectura)

Cuando activas la OneLake availability en una KQL database o tabla:

1. Los datos ingeridos se guardan en el motor Kusto (para queries KQL rápidas).
2. Simultáneamente, se escribe una copia en formato Delta Parquet en OneLake.
3. Otras herramientas de Fabric pueden consumir esa copia.

Es como tener dos copias sincronizadas: una optimizada para KQL y otra para el resto de Fabric.

Adaptive parquet file batching

El eventhouse hace un batching inteligente de los datos en streaming para generar ficheros Parquet óptimos para analítica.

Por qué: escribir muchos ficheros Parquet pequeños en el lake es ineficiente (más costes, peor rendimiento de query). Cómo lo equilibra: retrasa las escrituras a OneLake si no hay datos suficientes para crear ficheros Parquet óptimos.

Ejemplo para poner el retardo de escritura en 5 minutos:

.alter-merge table <TableName> policy mirroring
    dataformat=parquet
    with (IsEnabled=true, TargetLatencyInMinutes=5)

Monitorizar la latencia de los datos

Comando para ver cuánto hace que se añadieron datos al lake:

.show table mirroring operations

Cuando la Latency devuelve 00:00:00 → todos los datos de la KQL database están disponibles en OneLake.

Cuándo activar la OneLake availability

SÍ activarla: cuando necesitas integrar los datos KQL con el Lakehouse, tienes reports de Power BI con Direct Lake sobre datos KQL, hay notebooks de Spark que consumen datos KQL, o buscas data mesh e interoperabilidad.

NO activarla (o dejar el default): si solo vas a usar KQL para consultar (vía KQL Queryset/Dashboard), no hay integración con otros workloads de Fabric, o quieres minimizar el overhead de escritura.

¿Qué es?

El Eventhouse endpoint es una feature (relativamente nueva) que permite consultar tablas de un Lakehouse o un Warehouse desde un Eventhouse con una velocidad excepcional, usando el potente motor KQL.

Beneficios

Al activar el Eventhouse endpoint sobre un Lakehouse o Warehouse:

1. Sync de schema instantáneo: sincroniza tablas y cambios de schema en segundos, sin setup manual.
2. Schema mirrored: acceso a los datos actuales y futuros vía un schema replicado en una vista dedicada de KQL database.
3. Consumo rico: punto de entrada unificado "Analyze data with" (SQL endpoint, notebook, Copilot, NL2KQL, dashboards, queries embebidas).
4. Reflejado en los árboles del workspace y del OneLake catalog.
5. Queries rápidas y escalables: analítica en KQL o SQL con operadores avanzados.
6. Insights avanzados: análisis de series temporales, detección de anomalías y procesamiento con Python.

Cómo funciona

Después de activar el endpoint: se rastrea el origen de datos (Lakehouse/Warehouse), se optimiza para el rendimiento del Eventhouse y su flexibilidad, y cada tabla origen se asocia a un shortcut de OneLake en el Eventhouse endpoint con políticas de query acceleration. Bajo el capó, aprovecha shortcuts + query acceleration para dar rendimiento KQL sobre datos Delta.

Rendimiento y consumo

En la inicialización: el endpoint crea las tablas y cachea los datos; en 10 segundos queda totalmente sincronizado. Durante el sync el rendimiento de query es más lento, y a medida que se cachea más, mejora. Puedes actualizar la cache policy para optimizarlo.

Consumo: usa una porción limitada de la capacidad disponible. Los datos están disponibles en segundos, pero el tiempo de ejecución de las queries puede ser algo mayor al principio.

Permisos

Los usuarios con permiso Contributor u Owner en el origen de datos padre obtienen permiso Contributor en el Eventhouse endpoint, y pueden gestionar los settings de caché y retención.

Prerequisitos

• Workspace en una Fabric capacity.
• Un Lakehouse o Data Warehouse con tablas en el workspace (o en el OneLake catalog).

Estados de sincronización

El estado de sync en la página System Overview o Databases indica si la caché o la sincronización están en curso. También puedes comprobar el estado de cada shortcut.

🎯 Caso de uso típico

Escenario: tienes un Lakehouse con datos históricos de ventas y quieres hacer análisis avanzado de series temporales con KQL.

Solución: activas el Eventhouse endpoint sobre el Lakehouse, todas las tablas aparecen en una KQL database replicada, y puedes ejecutar queries KQL con detección de anomalías, funciones de series temporales e integración con Python.

Beneficio: no duplicas datos (usa shortcuts) pero ganas el poder analítico de KQL sobre datos Delta.

El Eventhouse y las KQL databases operan en un motor totalmente gestionado. Vamos con la facturación.

Compute (Eventhouse UpTime)

El cómputo se factura por la operación Eventhouse UpTime, en función del SKU de Fabric. Está disponible para analítica en 5-10 segundos y los recursos crecen con las necesidades analíticas.

Storage: 2 tiers

El storage se factura por separado de las capacity units de Fabric. Los datos ingeridos en una KQL database se almacenan en dos tiers:

A) OneLake Cache Storage (premium) — se usa para los tiempos de respuesta más rápidos. Cuando configuras la cache policy, afectas a este tier. Ejemplo: si sueles consultar 7 días atrás → retención de caché de 7 días. Comparable al tier premium de Azure ADLS.

B) OneLake Standard Storage (standard) — storage estándar para persistir y almacenar todos los datos consultables. Cuando configuras la retention policy, afectas a este tier. Ejemplo: retención de 365 días → storage para todo un año. Comparable al tier hot de Azure ADLS.

Monitorizar el storage

La Microsoft Fabric Capacity Metrics app permite a los capacity admins monitorizar el OneLake Storage.

Capacity Scheduler

El Eventhouse soporta un schedule recurrente de 7 días en bloques de 60 minutos donde puedes establecer una capacidad mínima por bloque o ningún mínimo (autoscale libre). El autoscale sigue habilitado siempre.

Beneficio: alinear la capacidad garantizada con los patrones de workload — más cómputo base durante las horas punta y escalado libre en los periodos tranquilos. Cuando hay un mínimo configurado para una ventana temporal, el Eventhouse UpTime refleja al menos ese baseline programado durante esa ventana.

Los 3 niveles de throttling

Cuando se alcanzan los límites de capacidad, el eventhouse aplica throttling para proteger la estabilidad del sistema. Hay 3 niveles progresivos:

Nivel 1: Proactive ⚠️ — las queries se limitan, la ingesta continúa normal. Es el menos severo.

Nivel 2: Reactive 🛑 — se pausan tanto la ingesta como las queries. Sin pérdida de datos.

Nivel 3: Extreme reactive 🚨 — se pausan la ingesta y las queries, los datos se retienen durante un periodo, pero pueden perderse pasado cierto tiempo.

Comportamiento durante el throttling

Cuando el eventhouse entra en proactive, la capacidad se reduce para mantener la disponibilidad durante un periodo extendido para acciones modestas. El eventhouse mantiene la disponibilidad con rendimiento reducido.

• Trampa 1: "Real-time significa 0 ms de latencia" ❌ Es near real-time. Siempre hay latencia (segundos típicamente). El tiempo real absoluto no existe en la práctica.
• Trampa 2: "Eventstream y KQL database son lo mismo" ❌ Eventstream = ingesta + transformación + routing. KQL database = almacenamiento + motor de query. Un eventstream puede enrutar a una KQL database.
• Trampa 3: "La ingesta directa siempre es mejor por simplicidad" ❌ La ingesta directa no permite transformaciones antes de almacenar. Si necesitas filtrar o enriquecer, usa un eventstream.
• Trampa 4: "KQL es igual que SQL" ❌ Muy distintos. KQL usa pipes (|), operadores diferentes (== en vez de =) y una filosofía basada en flujo en vez de anidada.
• Trampa 5: "La OneLake availability está activa por defecto" ❌ Hay que activarla manualmente por database o por tabla.
• Trampa 6: "La OneLake availability es instantánea" ❌ Hay un retardo adaptativo de hasta 3 horas por defecto (por eficiencia). Configurable desde 5 minutos.
• Trampa 7: "Bajar TargetLatencyInMinutes siempre es mejor" ❌ Un valor muy bajo genera muchos ficheros pequeños → rendimiento de query ineficiente. La tabla resultante es read-only y NO se puede optimizar después.
• Trampa 8: "El Eventhouse endpoint requiere copiar datos" ❌ NO copia. Usa shortcuts + query acceleration.
• Trampa 9: "El Capacity Scheduler es obligatorio" ❌ Es opcional. Sin él, el autoscale funciona igual pero sin garantía de baseline.
• Trampa 10: "El throttling siempre pierde datos" ❌ Solo el nivel extreme reactive (nivel 3) puede perder datos. El proactive y el reactive NO pierden datos.
• Trampa 11: "Activator solo envía emails" ❌ Puede disparar pipelines, notebooks y workflows de Power Automate. Es mucho más que alertas.
• Trampa 12: "KQL Queryset y KQL Database son lo mismo" ❌ El queryset es el editor de queries; la database es donde viven los datos y las tablas.
• Trampa 13: "Las materialized views de KQL = las Materialized Lake Views del Lakehouse" ❌ Conceptos similares pero implementaciones distintas. Las materialized views de KQL viven en KQL databases; las Materialized Lake Views, en Lakehouses. No son intercambiables.
• Trampa 14: "Un Real-Time Dashboard puede consultar cualquier data source" ❌ Está diseñado específicamente para KQL databases. Para otros orígenes, usa Power BI.
• Trampa 15: "T-SQL funciona igual en KQL que en un Warehouse" ❌ Solo hay un subconjunto de T-SQL soportado. Las features avanzadas de T-SQL puede que no funcionen.

Batch vs Real-time

Eventstream vs ingesta directa a KQL

KQL vs T-SQL en una KQL Database

Update policies vs Materialized views vs Stored functions

Real-Time Dashboard vs report de Power BI

Los 6 componentes de RTI

Storage tiers en una KQL Database

Niveles de throttling

• Módulo Learn: get-started-kusto-fabric
• Real-Time Intelligence overview: real-time-intelligence/overview
• Eventhouse overview: eventhouse
• Eventhouse as endpoint (Lakehouse/Warehouse): eventhouse-as-endpoint
• OneLake availability in Eventhouse: event-house-onelake-availability
• Real-Time hub overview: real-time-hub-overview
• Eventstreams supported sources: add-manage-eventstream-sources
• Process events using event processor editor: process-events-using-event-processor-editor
• Eventhouse and KQL Database consumption: real-time-intelligence-consumption
• Capacity Scheduler / Smart Capacity Control: eventhouse-smart-capacity-control
• KQL overview: kusto/query
• Kusto cache policy: cachepolicy
• Data retention policy: data-policies
• Real-Time Dashboards create: dashboard-real-time-create
• Activator introduction: activator-introduction
• Choose analytical data store in Fabric: fabric-analytical-data-stores