Real-Time Intelligence

Het patroon

Real-Time Intelligence is geen los product maar een keten: Eventstream is de opname en routering, Eventhouse de compute, de KQL Database de opslag en query-taal, het Real-Time Dashboard de consumptie, en Data Activator de reflex die er automatisch op reageert.

De echte ontwerpkeuze is niet welk onderdeel je gebruikt, maar waar je de stroom splitst in een hot en een cold path. Dezelfde Eventstream fan-out naar twee bestemmingen: het hot path naar een Eventhouse voor seconden-verse queries (status, drift, alerting), het cold path naar het Lakehouse voor alles wat historie en joins nodig heeft (samenvoegen met de medallion, ML-features). Zo krijgt elk pad de motor die erbij hoort. Via OneLake availability verschijnen de KQL-aggregaten als Delta in OneLake, zodat Power BI ze via Direct Lake meeneemt zonder derde kopie.

Wanneer gebruik je dit

• Beslissingen binnen seconden tot minuten: procesbewaking, fraude-signalen, logistieke afwijkingen.
• Hoge event-volumes waar batch-ingestie op stukloopt.
• Tijdreeksanalyse met KQL als kerncompetentie (percentielen, windows, anomaliedetectie).

Wanneer juist niet

• "Realtime" blijkt bij doorvragen "vandaag ververst": dan is een goed micro-batchpatroon in het Lakehouse simpeler en veel goedkoper.
• Complexe joins over grote historische sets: dat is Lakehouse- of Warehouse-werk.
• Kleine volumes met lage frequentie, de streaming-machinerie moet zichzelf terugverdienen.
• Besturing of veiligheidsafschakeling, nooit. Fabric-realtime is operationele-analytics-realtime: seconden, best-effort. Geen deterministische, milliseconde-nauwkeurige control loop. Een machine daadwerkelijk stoppen hoort bij PLC, SCADA en de OT-veiligheidslaag, niet bij Data Activator. Dit is de duurste ontwerpfout op deze laag.

Trade-offs

• Kosten: realtime is een altijd-aan-model. Anders dan batch, dat in een nachtvenster CU verbruikt, draait de Eventstream continu en het Eventhouse zolang het niet suspend is. De grote knoppen: hot-cache-grootte, minimum consumption, autosuspend en de retentie op ruwe events (bewaar ruw kort, geaggregeerd lang). De vraag "welke latency heeft deze beslissing écht nodig?" blijft de belangrijkste kostenknop.
• Twee query-talen: KQL naast SQL betekent extra competentie in het team. Onderschat de leercurve niet; overschat hem ook niet, voor tijdreeksen (make-series, anomaliedetectie) is KQL aantoonbaar productiever dan hetzelfde nabouwen in Spark of T-SQL.
• Dubbele paden: hot en cold path divergeren stil als je definities niet centraal beheert. Als het live dashboard OEE nét anders berekent dan het nachtelijke rapport, verlies je vertrouwen. Leg kern-definities één keer vast als gedeelde logica en pas ze in beide paden identiek toe, dát consistentievraagstuk is het echte werk op deze laag.

Praktijkvalkuilen

De klassieker: alles door het realtime-spoor sturen "omdat het toch kan". Binnen een paar maanden verbrandt de capaciteit en blijkt negentig procent van de dashboards prima met een uur vertraging te kunnen. Ontwerp vanaf de beslissing terug: wie doet wat anders als de data één seconde, één minuut of één uur oud is? Dat antwoord bepaalt het patroon, niet de technologie.

Verder: OneLake availability is een logische kopie mét vertraging, geen nul-latency spiegel, Direct Lake op KQL-data is dus niet zo vers als het hot-path-dashboard, beloof dat verschil niet weg. KQL-RLS geldt niet op die OneLake-kopie, dus tenant-isolatie rust op OneLake Security en fysieke scheiding. En bij alerting: trigger op een gestabiliseerde conditie (drempel gedurende een venster) met ontdubbeling en hersteldrempels, anders stuurt een flapperende sensor honderd berichten en negeert de ploeg voortaan élk alert.