3.4.1. Real-Time Intelligence Architecture
💡 First Principle: Real-Time Intelligence in Fabric provides purpose-built components for streaming analytics. Unlike batch processing, streaming requires handling continuous, unbounded data with minimal latency.
Scenario: An e-commerce platform needs to detect fraud within milliseconds, display real-time inventory, and analyze clickstream patterns. Each requires different latency and processing models.
Real-Time Intelligence Components
| Component | Purpose | Key Feature |
|---|---|---|
| Eventstream | Ingest and route events | No-code event processing |
| KQL Database | Store time-series data | Optimized for streaming queries |
| Eventhouse | Container for one or more KQL databases | Databases share its compute and storage capacity, with unified monitoring |
| Real-Time Dashboard | Visualize streaming data | Auto-refresh capabilities |
| Real-Time Hub | Monitor event flow | Centralized event catalog |
| Activator | Watch event data for conditions and act; rules come from an eventstream destination or Set alert on a stream in the Real-Time hub | Email/Teams alerts, run a pipeline or notebook, Power Automate |
Visual: Real-Time Intelligence Architecture
Choosing Storage in Real-Time Intelligence: Native vs. Mirrored vs. Shortcuts
This is a critical exam decision point. Real-Time Intelligence supports three storage approaches for data in KQL databases:
| Storage Approach | What It Means | Data Location | Latency | Cost |
|---|---|---|---|---|
| Native ingestion | Data ingested directly into Eventhouse | Eventhouse (local) | Lowest | Highest (full storage) |
| Mirrored storage | OneLake data mirrored into KQL database | Eventhouse (replicated) | Low | Medium (replicated copy) |
| Shortcuts | Reference external data without copying | External source | Variable | Lowest (no copy) |
Decision Framework:
| If You Need... | Use This | Why |
|---|---|---|
| Sub-second KQL queries on streaming data | Native ingestion | Data is local, fully indexed |
| KQL queries on existing OneLake data | Mirrored storage | Avoids separate ingestion pipeline |
| Occasional queries on external data | Non-accelerated shortcut | No storage cost, always current |
| Frequent queries on external data | Accelerated shortcut | Cached locally for faster queries |
| Real-time dashboards with low latency | Native ingestion | Fastest path from event to query |
| Historical analysis of lakehouse data via KQL | Shortcut or mirrored | Reuses existing data |
⚠️ Exam Trap: "Mirrored storage" in RTI is different from database mirroring (section 3.2.4). RTI mirroring makes OneLake data available to KQL queries; database mirroring replicates external databases into Fabric. Don't confuse the two.
Real-Time hub vs. Eventstream: the Real-Time hub is the tenant-wide catalog where you discover and connect to data streams and Fabric events; an Eventstream is the item that actually ingests, transforms, and routes events. You can create an eventstream directly in a workspace without starting from the hub.
OneLake availability: when streaming data already lands in an Eventhouse, turn on OneLake availability (database or table level) to expose a logical copy of the KQL data in Delta Lake format. Notebooks, lakehouses (through a shortcut), warehouses, and Direct Lake can then read it with no second ingestion path or export job, and the storage isn't charged twice.
Hot and cold history: an Eventhouse on its own serves both live and historical KQL queries: the hot cache answers recent-data queries in under a second, and older data ages into cheaper cold storage automatically (see 4.3.5). When the history must also feed Spark or ML, or be kept cheaply for years, route the same eventstream to a lakehouse Delta table as well (one stream, two consumers) instead of building a second pipeline. Don't size the hot cache to hold all history; that pays hot-cache prices for data you rarely query.
Real-Time Dashboards: every tile runs a KQL query against a data source such as an Eventhouse KQL database. Build order: a KQL table is receiving data → create the dashboard and add that database as a data source → add tiles with KQL queries → choose visuals, set auto-refresh, and save. The author sets a default refresh interval and a minimum interval that viewers can't go below.
Power BI over a KQL database: DirectQuery sends KQL queries when the report is viewed, at least one per visual, so a page with 8 visuals runs at least 8 queries. Import mode caches results at the last semantic-model refresh, so any report served from an Import model shows data as of that refresh, not live data.
