Overview#
The streaming analytics pattern serves two needs at once: a hot path for operational monitoring and automated action, and a cold path for long-history analysis through OneLake [S1] [S2]. Fabric supports this with Eventstreams for ingestion and routing, Eventhouses and KQL databases for hot query, Activator for actions, and OneLake availability for cross-engine reuse [S1] [S2].
Core concepts#
Eventstreams collect, transform, and route real-time data to one or more destinations [S1]. Eventhouses hold KQL databases optimized for high-volume event data, with hot cache and standard storage tiers governed by caching and retention policies [S2]. Activator can monitor supported event, KQL, and Power BI conditions and trigger notifications, Fabric jobs, functions, or Power Automate flows [S1].
OneLake availability exposes KQL table data as Delta data for other Fabric engines, which turns the same event stream into a cold-path source for lakehouse, warehouse, Spark, Direct Lake, and Power BI scenarios [S2] [S3].
How it works and best practices#
Route by latency requirement. Operational dashboards, anomaly investigation, and alerting should use the hot KQL path, while historical reporting and cross-domain joins should use the OneLake cold path [S1] [S2] [S3]. Size the cache window for the data that truly needs hot query, and use OneLake availability batching settings carefully because fresher cold-path writes can produce smaller files [S2].
Implementation example#
A streaming analytics implementation should state which path owns each latency target. KQL/Eventhouse handles the operational hot path; OneLake availability handles the historical/cross-engine cold path [S1] [S2].
// Illustrative hot-path query for an operations dashboard.
SensorReadings
| where Timestamp > ago(10m)
| summarize AvgTemperature = avg(Temperature), MaxTemperature = max(Temperature)
by SensorId, bin(Timestamp, 1m)
| where MaxTemperature > 80
Inference: the query is illustrative; the sourced mechanics are KQL/Eventhouse query over real-time data and RTI's event analytics surface [S1] [S2].
hot_cold_contract:
hot_path:
destination: eventhouse_kql_database
purpose:
- live_dashboard
- activator_rule
cold_path:
destination: onelake_delta
purpose:
- historical_power_bi
- lakehouse_join
- spark_notebook_analysis
The contract is grounded in Eventstream/Eventhouse, Activator, and OneLake availability behavior; exact freshness should be tested against the configured batching and capacity conditions [S1] [S2] [S3].
What goes wrong#
Streaming adds cost and operational shape that batch workloads do not need. If the business requirement is daily freshness, a lakehouse or warehouse pipeline is usually a better fit than keeping a hot event path [S1] [S2]. Enabling OneLake availability before schema and security decisions are stable can also force backfill or change-management friction [S2].
Internals#
Architecture & design#
The pattern is a split path: Eventstream routes incoming events, Eventhouse/KQL serves the hot operational store, and OneLake availability creates a Delta-form cold path for other engines [S1] [S2].
How it works internally#
Eventhouse storage separates a premium cache tier from standard storage, and OneLake availability writes batches of KQL table data into Delta format for downstream Fabric workloads [S2]. Activator evaluates live conditions and routes actions to supported automation targets [S1].
Performance characteristics#
Hot-path query behavior depends on cache residency and Eventhouse capacity, while cold-path freshness and downstream file quality depend on OneLake availability batching [S2]. Under pressure, Eventhouse throttling and surge protection choices determine how the workload degrades [S2].
Worked example#
A logistics team can stream vehicle events through Eventstreams, store them in an Eventhouse for live location dashboards and Activator alerts, and expose the same data to OneLake so historical trips can be joined with warehouse dimensions and reported in Power BI [S1] [S2] [S3].