KQL (Kusto Query Language)

Wat is KQL?

KQL staat voor Kusto Query Language. Het is een zoektaal die Microsoft ontwikkelde voor het razendsnel bevragen van grote hoeveelheden logs, telemetrie en tijdreeksdata. Je komt KQL tegen in Azure Data Explorer, Microsoft Fabric Real-Time Intelligence, Azure Monitor, Log Analytics, Application Insights en Microsoft Sentinel.

Waar SQL perfect werkt voor relationele data met sterke schema's, is KQL ontworpen voor semi-gestructureerde data met miljarden rijen en frequente tijdgebaseerde vragen: toon de fouten van het voorbije uur, bereken p95-latency per endpoint, vind alle logins vanuit een verdachte regio de laatste 24 uur. Die vragen draaien op een slim gepartitioneerde KQL-engine vaak in milliseconden, ook op terabytes data.

Je kan KQL vergelijken met een schep waarmee je snel door logbergen graaft, terwijl SQL meer op een scalpel lijkt voor nauwkeurige relationele snijwerk.

Hoe ziet KQL eruit?

KQL leest van boven naar beneden als een pipeline, met | als scheidingsteken tussen stappen. Een eenvoudig voorbeeld:

StormEvents
| where StartTime > ago(30d)
| where State == "TEXAS"
| summarize count() by EventType
| top 5 by count_

Te lezen als: begin bij de tabel StormEvents, filter op de voorbije 30 dagen, filter op Texas, tel per event-type, toon de vijf meest frequente. Dat is natuurlijk: je denkt in stappen, je bouwt een query uit in stappen, je leest hem ook zo terug.

Enkele veelgebruikte operators:

• where: filter rijen. Vergelijkbaar met SQL WHERE.

• project: selecteer of hernoem kolommen. Vergelijkbaar met SELECT.

• extend: voeg berekende kolommen toe.

• summarize: aggregeer per groep. Vergelijkbaar met GROUP BY.

• join: combineer tabellen.

• render: teken een grafiek binnen de query-tool.

Tijdsfuncties als ago(1h), bin(Timestamp, 5m) en now() zitten ingebakken. Ook time-series-operaties zoals anomaliedetectie en forecasting kan je met enkele regels oproepen.

KQL versus SQL

Ontwerpfilosofie

SQL is declaratief: je beschrijft het resultaat en de engine beslist hoe. KQL is een pipeline: je beschrijft de stappen en de engine optimaliseert binnen dat frame. Voor exploratief werk op logs voelt KQL vaak sneller en natuurlijker.

Datatypes

KQL is ontworpen voor append-only tijdreeksdata en heeft krachtige ondersteuning voor dynamisch getypeerde kolommen (JSON-objecten als eerste-klas waarden), arrays en ingebouwde statistiek-functies.

Schrijven versus lezen

KQL is primair een read-only taal. Je laadt data in via ingestion-pipelines en stelt vragen via KQL, je doet geen transactionele updates. Wie klassieke OLTP-operaties nodig heeft, blijft bij SQL.

Interoperabiliteit

Een KQL-database in Fabric stelt zichzelf ook beschikbaar als SQL-endpoint, zodat tools als Power BI zonder aparte integratie op KQL-data kunnen draaien. De meeste BI-vragen kunnen in beide talen, zware log-analyses bijna enkel nog vlot in KQL.

Wanneer gebruik je KQL?

1. Log-analyse. Applicatielogs, webserverlogs, Kubernetes-logs. KQL kan miljarden rijen doorploegen met gerichte filters en aggregaties.

2. Monitoring en observability. Azure Monitor en Application Insights draaien op KQL. Dashboards, alerts en ad-hoc troubleshooting gebeuren in KQL.

3. Security analytics. Microsoft Sentinel gebruikt KQL voor SIEM-queries. Detectieregels, threat hunting en incident-onderzoek leunen er zwaar op.

4. IoT en telemetrie. Metingen van sensoren of machines met hoge frequentie en lange historieken. KQL combineert dat goed met anomaliedetectie.

5. Realtime rapportering in Fabric. Binnen Fabric Real-Time Intelligence voed je eventstreams naar een KQL-database en bouw je live-dashboards die binnen seconden bijwerken.

KQL binnen Microsoft Fabric

Eventhouse is de nieuwe naam voor een KQL-database binnen Fabric. Data komt binnen via Eventstreams (vanuit IoT Hub, Event Hubs, Kafka, sampleconnectoren) en wordt opgeslagen in kolomgeoriënteerde tabellen met automatische indexering. KQL-queries daarop draaien bovenop OneLake, zodat je dezelfde data ook kan delen met het rest van Fabric.

Resultaten kan je direct als KQL-dashboard publiceren, als set alerts configureren via Data Activator, of via DirectQuery koppelen aan Power BI voor de klassieke BI-kant van de stack.

Valkuilen

Onderschatten hoe anders KQL denkt
Wie jarenlang SQL schreef, neigt er naar om | als verplicht vertaalpunt van SELECT/JOIN/WHERE te gebruiken. Investeer in een goede KQL-opleiding voor je engineers, anders blijft de taal onderbenut.

Querys die niet schalen door joins
KQL is fantastisch in één tabel, maar joins tussen heel grote tabellen zijn duur. Herverdeel data of gebruik lookup voor kleine dimensionele tabellen.

Retentie en kosten
KQL-databases houden data meestal beperkt tijdsgebonden (30, 90, 365 dagen). Oudere data kan naar goedkopere lagen (cold, archived) of naar OneLake worden gearchiveerd. Vergeet niet een retentiebeleid expliciet te zetten.

Geen vervanging voor Data Warehouse
Voor stabiele BI-modellen met dimensies en feiten blijft een klassiek warehouse of goudlaag beter geschikt. Gebruik KQL waar het schittert: ruwe logs en tijdreeksen.