Fabric Real-Time Intelligence: How to Build a Streaming Pipeline Step by Step

The build follows a clear path: bring data in, store it, query it, then act on it. Each step maps to one of the components above, so you can pause and verify before moving on. Working in this order also keeps troubleshooting simple, because you confirm one stage is healthy before adding the next. To follow the official walkthrough alongside this guide, see the Real-Time Intelligence tutorial introduction.

1. Create an Eventhouse with a KQL database. This is where your event data will land and where you will run KQL queries. Set it up first so the eventstream has a destination ready.
2. Create an Eventstream. Open the low-code canvas that handles ingestion and routing. The Microsoft Fabric eventstream is the front door for all incoming events.
3. Add a source. Start with sample data to test the flow quickly, or connect a live source like Azure Event Hubs. Other sources include Azure IoT Hub, Apache Kafka, and database change data capture.
4. Add the Eventhouse / KQL database as a destination. Point the stream at the storage you created in step one so events begin to accumulate.
5. Add optional processing steps. On the canvas, you can filter out noise, aggregate values, or join streams before the data lands. Keep this light at first.
6. Query the data with KQL and build a Real-Time Dashboard. Once events flow in, write KQL to shape the results, then pin them to a real-time dashboard in Fabric that auto-refreshes.
7. Set an Activator rule. Tell Activator to watch a metric and alert you when a threshold is crossed, so the system reacts without anyone staring at a screen.

A Short KQL Example

KQL reads top to bottom, with each line piping its result into the next. The query below pulls the last hour of telemetry and averages temperature in five-minute buckets per device. You can adapt the column names to your own schema.

Telemetry
| where Timestamp > ago(1h)
| summarize avg(Temperature) by bin(Timestamp, 5m), DeviceId

This pattern, filter then summarize then group, covers a large share of real-world streaming questions. The ago(1h) filter keeps the query light by scanning only recent records, which matters when an Eventhouse holds billions of rows. The bin() function groups timestamps into even windows, so the chart shows a clean trend rather than jittery raw points. Once the query returns what you expect, pin it to your dashboard so the view stays current.

As your needs grow, you can extend the same query with extra filters, additional aggregations, or joins to reference tables. Because Eventhouse KQL is built for time-series workloads, these queries stay fast even as data volume climbs. Keep each dashboard tile focused on one question; several small, fast tiles read better than one crowded chart.

Where the Eventstream Can Route Data

An eventstream is flexible about destinations. Besides an Eventhouse, it can route data to a lakehouse, which keeps your batch and streaming worlds close together. Many teams use both: an Eventhouse for fast queries on recent events, and a lakehouse for long-term storage and downstream modeling. Routing to more than one destination from a single stream means you do not have to choose between speed and history.

The low-code canvas also lets you shape data on its way through. A filter can drop noisy or irrelevant events early, an aggregation can pre-summarize high-frequency readings, and a join can attach reference data such as a device name or region. Keeping processing light at first makes the pipeline easier to debug, and you can add steps once the basic flow is proven. For more detail on sources and destinations, the Eventstream overview on Microsoft Learn is the reference to keep open while you build. If you are also working with batch and historical data, our note on the Microsoft Fabric lakehouse explains how the lakehouse pattern fits the wider platform.