How KQL Processes Data

0.1 What the tabular execution model is and why it defines every query you write

KQL is not a search language. It is a data transformation language built on a single architectural principle: everything is a table. Every query begins with a table, every operator consumes a table and produces a table, and the final output is a table. A query that counts sign-in failures returns a table with one column and one row. A query that matches zero events returns an empty table with column headers and zero rows. There is no scalar mode, no single-value return, no mixed output type. The tabular model is absolute.

This matters because it determines how you think about queries. In SQL, you declare what you want and the engine decides how to retrieve it. In KQL, you describe a sequence of transformations, and each transformation operates on the tabular output of the previous one. The pipe character connects those transformations into a pipeline. The analyst who understands this pipeline can predict the output of any query by tracing the table shape through each operator. The analyst who does not understand it writes queries that produce unexpected results and cannot explain why.

The execution model also explains KQL's performance characteristics. The Kusto engine was built for analytical workloads against massive telemetry datasets. It processes columns independently (columnar storage), parallelizes operator execution across distributed nodes, and prunes data early in the pipeline when it can determine that rows will not survive later filters. An analyst who places where TimeGenerated > ago(1h) at the top of the pipeline lets the engine skip scanning data outside that window entirely. An analyst who places it after a summarize forces the engine to aggregate all data first, then discard most of the result. Same output, different performance. The tabular model is not just a mental model for reading queries. It is the execution model that determines whether your query finishes in two seconds or times out after ten minutes.

This module teaches the five concepts that make the tabular model concrete: the table structure itself (rows, columns, schemas), the pipeline that chains operators together, the data types that govern what each column can contain, the conversion functions that bridge type mismatches, and the null handling rules that cause the most common class of silent query failures.

0.2 What you will learn

Five sections, each building a layer of the data processing foundation.

Section 1.1: The Tabular Data Model. What a KQL table is, how rows and columns map to security events and their attributes, why the output of every operation is another table, and what that means for chaining operators. You will examine real table schemas from Sentinel and learn to use getschema and take to explore any unfamiliar table before writing queries against it.

Section 1.2: The Query Pipeline. How the pipe operator chains transformations left to right, how each operator's output becomes the next operator's input, and why execution order changes results. You will trace a multi-operator query step by step, see how row counts and column sets change at each stage, and learn the operator ordering rules that prevent the most common query mistakes.

Section 1.3: Data Types in Depth. Every data type you encounter in security log tables: string, datetime, int, long, real, bool, dynamic, timespan, and guid. How each type governs which operators and comparisons are valid. You will see why ResultType is a string that looks like an integer, why Location is a dynamic object that requires extraction operators, and why TimeGenerated arithmetic works differently from numeric arithmetic.

Section 1.4: Type Conversion and Coercion. The conversion functions that transform data between types: tostring(), todatetime(), toint(), tolong(), todouble(), tobool(), todynamic(), and parse_json(). You will learn when KQL performs implicit conversion, when it fails silently, and how to write explicit conversions that make your queries type-safe.

Section 1.5: Null Handling. How null values appear in security data (missing fields, failed conversions, outer join non-matches), why null comparisons produce unexpected results, and the functions that handle nulls correctly: isempty(), isnotempty(), isnull(), isnotnull(), coalesce(). You will learn why a where clause on a null field silently drops the row instead of erroring, and how to write defensive queries that account for missing data.

0.3 Why the execution model is the prerequisite for every module that follows

Modules 2 through 13 teach operators, patterns, and investigation techniques. Every one of those modules assumes you understand the five concepts in this module. Without the tabular model, joins are unpredictable because you cannot visualize two tables combining into one. Without pipeline ordering, your summarize aggregates the wrong rows because the where filter that should have preceded it came after. Without data type awareness, your comparisons match zero rows because you compared a string to an integer. Without type conversion, you cannot extract nested fields from dynamic columns. Without null handling, your detection rules silently miss events where a field the rule depends on was not populated.

The Kusto engine does not warn you about these problems. A query with a type mismatch runs successfully and returns an empty result set. A query with a misplaced operator runs successfully and returns the wrong count. A query that ignores null values runs successfully and excludes evidence the investigation needed. KQL's failure mode is silence. This module teaches you to prevent those silent failures before they reach production queries and detection rules.

0.4 How to get the best from this module

Work through the sections in order. Each section builds on the previous one. Section 1.1 establishes the table structure. Section 1.2 shows how operators transform that structure through the pipeline. Section 1.3 introduces the type system that governs what each column can contain. Section 1.4 teaches conversion between types. Section 1.5 addresses the missing-data problem that causes the most investigation errors.

Run the example queries in your lab environment as you read. The concepts in this module are concrete, not abstract. Seeing a getschema result, watching row counts change after a where filter, and observing a null comparison drop rows from a result set are the experiences that make these concepts intuitive. Estimated time: 3 to 4 hours for all five sections. Two sections per session works well.

0.5 Module structure

• Section 1.1 — The Tabular Data Model
• Section 1.2 — The Query Pipeline
• Section 1.3 — Data Types in Depth
• Section 1.4 — Type Conversion and Coercion
• Section 1.5 — Null Handling

If you completed Module 0, you already have a working lab environment. If you skipped Module 0, set up your lab before starting Section 1.1. Every section includes queries that produce different results depending on your workspace data, and the learning happens when you run them and interpret the output.

Go to Section 1.1 — The Tabular Data Model to begin.