Microsoft-Fabric

Let’s look at where this feature fits in practice.

The first major category is IoT telemetry - monitoring physical equipment. Think of a manufacturing plant where each machine sends readings for vibration, current draw, and temperature. Sudden spikes or drifts in these metrics may indicate wear, imbalance, or failure. The anomaly detector can continuously flag these irregularities before they cause downtime.

Another use case is application or system performance. If you’re monitoring throughput, error rates, or latency across multiple services, anomalies may indicate deployment issues, scaling problems, or outages. Because detection runs continuously and in near real time, operations teams can be notified within seconds.

2026-09-30

The AI Anomaly Detector in Microsoft Fabric Real-Time Intelligence uses a combination of time-series analysis and machine learning models. You don’t need to choose the model manually-Fabric evaluates the data and automatically selects the most appropriate approach.

Behind the scenes, it can use classical models like seasonal decomposition or ARIMA for steady, predictable series, or neural network–based models for more complex and irregular data. It also supports hybrid methods that adapt to both short-term trends and cope with long-term seasonality.

2026-09-28

The workflow is straightforward once you know the moving parts. You begin in your Eventhouse - that’s where data from your event streams is stored.

First, ensure that the Python plugin is enabled. This plugin provides the AI runtime used to train and run anomaly models. It can take up to an hour to enable for the first time, so plan that in advance.

2026-09-26

This new capability in Microsoft Fabric Real-Time Intelligence brings true AI-driven anomaly detection into the streaming environment. Traditionally, anomaly detection required a fair amount of data-science work - building models, testing parameters, and maintaining code. Fabric now handles much of that automatically.

The service examines incoming time-series or streaming data to look for unusual patterns - things that differ significantly from what’s been observed before. It supports both univariate detection, where you track a single metric such as temperature, latency, or transaction volume, and multivariate detection, which handles correlated signals - for example, temperature, pressure, and vibration from the same machine.

2026-09-24

Machine learning plays an increasingly important role in real-time analytics. Instead of only using models in batch workflows, many systems now apply them directly to streaming data - allowing predictions, classifications, or anomaly detection as events occur.

In this model, each incoming event - such as a transaction, sensor reading, or social media post - can be scored in-flight by a machine learning model. For example, a transaction can be classified as potentially fraudulent, an IoT signal can be checked for signs of equipment failure, or a social post can be analyzed for sentiment.

2026-09-22

Update policies in KQL (and thus in Fabric) are a mechanism to automatically transform ingested data as it arrives.

Rather than separately ingesting raw data and then running background jobs to clean, route, or enrich it, an update policy allows you to declare a transformation query that runs whenever new data lands in a source table.

The transformation query writes its output into a target table. The source and target must exist in the same database. The schema (column types and order) of the transformation output must match what the target table expects.

2026-09-20

KQL offers a wide range of specialized functions designed to handle advanced analytical tasks — particularly useful in real-time and large-scale telemetry environments.

Some of the most important belong to three broad groups:

• Anomaly and pattern detection: Functions like series_decompose_anomalies() and series_outliers() identify unusual trends or values within time series data. These are often used in monitoring, fraud detection, or IoT scenarios where unexpected changes may signal issues.
• Time series and multivalue operations: Functions such as make-series and mv-expand let you group data into time bins and expand array-like columns for further analysis. These help with trend visualization, forecasting, and interval-based reporting.
• Geospatial and temporal enrichment: The geo_* family (e.g., geo_distance_2points(), geo_point_to_h3cell()) allows spatial analysis, such as tracking asset locations or mapping activity by region.

2026-09-18

In KQL, the union operator can combine results from multiple tables, even when those tables follow a naming pattern. This is particularly useful in environments where data is split across many similar tables — for example, logs_2024_01, logs_2024_02, and so on.

You can use wildcards with the union operator to simplify these queries. Instead of listing each table individually, you can write:

union withsource=TableName logs_*

This automatically brings together all tables whose names begin with logs_.

2026-09-16

In Fabric, KQL supports querying across multiple databases or even across different clusters.

This feature is especially valuable when data is distributed across teams, regions, or functional domains — for example, separate clusters for telemetry, transactions, and logs.

A cross-database query allows you to access tables in more than one KQL database within the same cluster. This is often used when analytical data and operational data are stored separately but need to be correlated — such as linking user activity logs with transaction histories.

2026-09-14

Partitioning is one of the most effective ways to improve scalability and performance in event-driven systems. It works by dividing a single event stream into multiple independent subsets, or partitions, that can be processed in parallel.

Each partition operates independently, which allows multiple consumers or processing nodes to work simultaneously without interfering with one another. This parallelism increases throughput and helps maintain low latency even as data volumes grow.

The partition key determines how events are distributed among partitions. Common choices include device ID, user ID, or region, depending on the data model and access patterns. The key should be selected carefully:

2026-09-12