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 |
| Real-Time Dashboard | Visualize streaming data | Auto-refresh capabilities |
| Real-Time Hub | Monitor event flow | Centralized event catalog |
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.
