Trend analysis is one of the most powerful applications of KQL — it lets you move beyond simple metrics and start understanding how your data evolves over time.
Most trend analysis begins with the make-series operator. This operator constructs a time-series dataset by grouping values into evenly spaced time intervals. You might, for instance, calculate the average response time or error count every minute, hour, or day.
Here’s a simple example:
2026-06-26
Anomaly detection is a key use case for real-time analytics — it’s about automatically identifying when something unusual or unexpected happens in your data.
In most systems, normal behavior forms a fairly predictable pattern. For example, transactions follow a steady daily rhythm, CPU usage fluctuates within a typical range, and sensor readings stay within expected bounds.
Anomalies are the data points that break from those patterns — a sudden spike in temperature, a large payment outside normal limits, or a sudden burst of failed login attempts.
2026-06-24
Another Fabric Down Under podcast is out the door.
Andrew is the Founder & CEO at Blue Badge Insights, and writes about Data & Analytics. He does independent analyst work with Gigaom.
Andrew is a fellow long-term MVP and member of the Microsoft Regional Director program and he’s co-chair of SQL Server Live! and Artificial Intelligence Live!
In the podcast, we discussed semantic models and ontologies, from the beginning to the current state of Fabric IQ. Andrew also shared interesting details from the competitive (data-related) industry landscape.
2026-06-23
KQL provides a comprehensive library of functions that make it incredibly flexible for analytics. You’ll find functions across several categories — from simple text operations to advanced time-series analysis.
First, there’s a wide range of built-in functions. These include string functions like substring(), tolower(), and replace(); mathematical functions such as round(), sqrt(), and abs(); and datetime functions like now(), ago(), and datetime_diff(). These make it easy to clean, transform, and standardize your data right inside your query.
2026-06-22
When you start working with real telemetry data, you’ll quickly notice that not everything fits neatly into tables and columns. Much of it is semi-structured — think JSON payloads, arrays, and nested fields.
KQL provides a set of advanced operators that make handling this kind of data easy and powerful.
| Operator | Purpose / Description |
|---|---|
| parse, parse_json | Extract fields from strings, logs, or JSON content |
| mv-expand | Expand or flatten arrays into individual rows |
| top-nested | Find top results within grouped categories |
| union | Combine results from multiple tables or streams |
| (Advanced tools) | Ideal for semi-structured or nested data |
The parse and parse_json operators let you extract values directly from text or JSON fields. For example, if your logs contain a JSON blob, you can pull out fields like deviceId or errorCode as first-class columns you can filter and aggregate on.
2026-06-20
Like SQL, KQL supports joins that let you combine data from multiple tables. This is a powerful way to bring together different data sources — for example, matching real-time events with reference or lookup data to give them more context.
The join operator works much like you’d expect, combining rows based on a matching key. KQL supports several join types, including inner, leftouter, rightouter, and fullouter.
Here’s a simple example:
2026-06-18
When you’re dealing with real-time or high-volume event data, one of the first challenges is scale — there’s simply too much information to interpret at the individual event level. That’s where aggregations come in. Aggregations are the process of summarizing large numbers of rows into meaningful metrics that humans can easily interpret.
For example, if you’re collecting IoT sensor readings from thousands of devices, it doesn’t make sense to inspect each data point individually. Instead, you might calculate the average temperature per minute, the total number of readings received, or the maximum pressure recorded in the last hour. Those aggregated values turn a flood of raw data into something you can analyze and act on.
2026-06-16
In KQL, time is one of the most important concepts — it’s central to how telemetry and log data are analyzed.
Most KQL datasets include a Timestamp column, and nearly every query begins by filtering to a specific time range.
You can do that using a where clause, such as:
| where Timestamp between (ago(1h) .. now())
This filters your events to just those that occurred within the last hour. It’s an efficient way to narrow down large datasets quickly.
2026-06-14
In KQL, projections are how you shape your dataset — deciding which columns to keep, how to name them, and even adding new ones on the fly.
The main operator for this is project. It lets you select only the columns you need, and at the same time, you can rename columns using aliases to make your results more meaningful or easier to read. For example:
Events
| project Time = Timestamp, User = UserId, Message
Here, the column Timestamp is renamed to Time, and UserId becomes User. This makes your results cleaner and easier to understand — especially when you’re building queries for dashboards or reports.
2026-06-12
When we start working with large volumes of data, one of the first and most important things we need to do is filter. Filtering is all about reducing noise — narrowing down the data that we really need so that we only keep the rows that are relevant to our analysis or our business needs.
In most systems, rows contain a mix of everything: normal activity, background data, edge cases, and sometimes even junk messages. If we tried to process or visualize all of it, our queries would slow down, and costs would rise, and the signal we care about would get buried in the noise. Filtering allows us to focus only on what matters.
2026-06-10