Eventstream (Microsoft Fabric)

Wat is een Eventstream?

Een Eventstream is de bouwsteen in Microsoft Fabric die streaming data binnenhaalt, onderweg licht bewerkt en naar de juiste bestemming stuurt. Je klikt en sleept alles bij elkaar in een visuele editor, er komt geen code aan te pas. Eventstreams horen bij Real-Time Intelligence, de Fabric-workload voor alles wat met data in beweging te maken heeft.

Het principe: je kiest een bron, bijvoorbeeld een Azure Event Hub of een Kafka-topic. Je zet er eventueel bewerkingen tussen, zoals filteren of een gemiddelde per minuut. En je kiest waar het resultaat landt: een eventhouse, een lakehouse of een alert.

Vergelijk het met een rangeerstation: wagons komen binnen op een spoor, worden gewogen en herschikt, en vertrekken elk naar hun eigen eindbestemming. Een Eventstream doet dat met events.

Onder de motorkap draait elke Eventstream op Azure Event Hubs; Fabric zet die infrastructuur automatisch voor je op. Daardoor heeft elke Eventstream ook een Kafka-endpoint, waar toepassingen die al Kafka spreken rechtstreeks op aansluiten.

Welke bronnen kan je aansluiten?

De lijst met connectoren is lang, denk daarom eerder in categorieën dan in een opsomming:

• Azure-diensten. Azure Event Hubs, IoT Hub, Event Grid en Service Bus. Voor wie al op Azure zit, is dit de kortste weg.

• Databasewijzigingen via Change Data Capture. Connectoren voor onder meer Azure SQL, PostgreSQL, MySQL en Cosmos DB zetten elke insert, update en delete in je database om in een event.

• Andere clouds en brokers. Apache Kafka, Confluent Cloud, Amazon Kinesis, Google Pub/Sub en MQTT-brokers (die laatste nog in preview). Handig als je bronnen buiten het Microsoft-ecosysteem draaien.

• Fabric zelf. Workspace-events, OneLake-events en job-events. Zo kan je bijvoorbeeld reageren op de refresh van een semantisch model of een pipeline-run.

• Je eigen toepassingen. Via een custom endpoint stuurt je applicatie events rechtstreeks de stream in, met een connection string of via het Kafka-protocol.

• Oefendata. Ingebouwde voorbeeldstromen zoals beursdata en taxiritten, plus een echte weerdata-feed, om een opzet te testen zonder eerst een bron te bouwen.

Wat doe je onderweg met de events?

Tussen bron en bestemming zet je bewerkingen in de event processor, een drag-and-drop-editor. De belangrijkste:

• Filteren. Alleen de events doorlaten die aan een voorwaarde voldoen, bijvoorbeeld metingen boven een grenswaarde.

• Velden beheren. Kolommen hernoemen, verwijderen, toevoegen of van datatype veranderen. Zo landt de data meteen in de vorm die je rapporten verwachten.

• Aggregeren per tijdsvenster. Som, minimum, maximum of gemiddelde per venster van bijvoorbeeld een minuut, zodat duizenden ruwe metingen een handvol bruikbare cijfers worden.

• Combineren. Twee streams samenvoegen (union), een array uitklappen naar aparte rijen (expand) of twee streams joinen op een sleutel.

Het resultaat van zo'n bewerking kan je als afgeleide stream publiceren, zodat collega's op de opgekuiste versie verder bouwen. Wie liever code schrijft dan sleept: transformaties kan je ook als SQL-expressies definiëren, al zit die optie nog in preview.

Hou de verwachtingen wel realistisch. Een Eventstream is gemaakt voor lichte bewerkingen tijdens het transport. Zwaar modelleerwerk, historische joins en business-logica horen thuis in je lakehouse of warehouse, nadat de events geland zijn.

Waar stuur je de events naartoe?

Een Eventstream kan dezelfde stream naar meerdere bestemmingen tegelijk sturen. De vier die je het vaakst gebruikt:

• Eventhouse. De KQL-database van Fabric, gebouwd voor tijdreeksen en logdata. Hier bevraag je de events met KQL en bouw je er Real-Time Dashboards op die binnen seconden bijwerken.

• Lakehouse. De events worden als Delta-tabellen weggeschreven. Vanaf dan gedragen ze zich als gewone data voor Power BI, notebooks en je warehouse-laag.

• Activator. Bewaakt de stream op voorwaarden en onderneemt actie zodra die zich voordoen: een melding naar de juiste persoon of een Power Automate-flow die vertrekt.

• Custom endpoint. Voor systemen buiten Fabric die de events in real time willen meelezen.

Hoe verhoudt een Eventstream zich tot de rest?

De taakverdeling binnen Real-Time Intelligence

Real-Time Intelligence bestaat uit onderdelen met elk een duidelijke rol. De Eventstream doet transport en routering: events binnenhalen, licht bewerken, afleveren. Het eventhouse doet opslag en query: daar bevraag je de events met KQL. Het Real-Time Dashboard toont de resultaten, en Activator koppelt er acties aan. De Real-Time hub is ten slotte de catalogus waarin je alle streams van de organisatie terugvindt.

Die scheiding helpt bij het ontwerpen. De vraag "welke data moet binnen?" beantwoord je in de Eventstream, de vraag "wat wil ik erover weten?" in KQL, en de vraag "wie moet wanneer verwittigd worden?" in Activator.

Eventstream of zelf Kafka draaien?

Apache Kafka is de referentie onder de event-brokers, maar een eigen cluster beheren is een vak apart: brokers, partities, upgrades en monitoring vragen een technisch profiel dat er permanent op let. Een Eventstream geeft je hetzelfde basispatroon als managed dienst: Fabric regelt de infrastructuur, jij betaalt via je capaciteit.

Daar staat minder controle tegenover. Berichten mogen maximaal 1 MB groot zijn, events blijven hoogstens 90 dagen in de stream bewaard en aan de knoppen van de onderliggende infrastructuur kan je amper draaien. Draai je vandaag al Kafka met grote volumes en eigen tuning, dan is er weinig reden om te verhuizen; het Kafka-endpoint laat beide werelden gewoon naast elkaar bestaan. Voor wie nog geen streamingplatform heeft en al in Fabric werkt, is de Eventstream de logische eerste keuze.

Of gewoon batch blijven laden?

De eerlijkste vraag komt voor de technologiekeuze: moet er wel iemand binnen seconden op deze data reageren? Voor de meeste rapportering volstaat een refresh per nacht of per kwartier, en dan is een klassieke datapijplijn eenvoudiger en goedkoper. Een Eventstream verlaagt de drempel naar streaming fors, maar een stream waar niemand live naar kijkt, is capaciteit die je beter aan iets anders besteedt.

Voorbeeld: machinesensoren op een live dashboard

Een maakbedrijf heeft twaalf CNC-machines die elke paar seconden temperatuur en trillingsniveau doorsturen. De sensoren sturen hun metingen naar een Azure IoT Hub, die als bron aan een Eventstream hangt.

In de stream gebeuren drie dingen. Een filter gooit de events van de twee testmachines eruit. Een aggregatie berekent per machine het gemiddelde per minuut. En de stream vertrekt naar twee bestemmingen tegelijk: het eventhouse achter een Real-Time Dashboard dat in de productiehal hangt, en een Activator-regel die een melding stuurt zodra een machine vijf minuten boven haar temperatuurgrens zit.

De ruwe, ongefilterde events gaan ondertussen als derde tak naar een lakehouse. Daar bouwt het team er later historische analyses op, zoals slijtagepatronen per machine.

Het hele traject is klikwerk; er komt geen streaming-engineer aan te pas. Vervang de sensoren door webshop-events en hetzelfde patroon toont je bestellingen en afhakende bezoekers live.

Waar moet je op letten bij het gebruik van een Eventstream

Een actieve stream verbruikt capaciteit
Een Eventstream draait op je Fabric-capaciteit en telt door zolang er events stromen: een uurtarief voor de stream zelf, een tarief per gigabyte verkeer en een vergoeding voor de rekenkracht van processor en connectoren. Stroomt er twee uur lang niets, dan stoppen die tellers. Microsoft raadt minstens een F4-capaciteit aan, en wie events langer dan een dag in de stream bewaart, betaalt daarvoor apart OneLake-opslag. Hou het verbruik in het oog via de Capacity Metrics app.

At-least-once betekent soms twee keer
Een Eventstream garandeert dat elk event minstens een keer aankomt, en dus af en toe dubbel. Reken daarop in je verwerking: geef events een unieke sleutel en maak de afhandeling idempotent, zodat een dubbel event het resultaat niet vertekent.

Niet elk dashboard hoeft live
De verleiding is groot om alles door een stream te trekken zodra de techniek er staat. Vraag per use case wie er binnen seconden op reageert. Is het antwoord niemand, laad dan gewoon per kwartier of per nacht.

De stream is een doorgeefluik
Events blijven maximaal 90 dagen in de stream staan. Alles wat je wil bijhouden, stuur je naar een eventhouse of lakehouse; daar zit je historiek, met retentie die jij bepaalt.

FAQ over Eventstreams

1. Wat is het verschil tussen een Eventstream en een eventhouse?
De Eventstream vervoert en routeert events, het eventhouse slaat ze op en laat je erop queryen met KQL. Ze vullen elkaar aan: de stream levert af, het eventhouse bewaart en analyseert.

2. Kan ik mijn bestaande Kafka-toepassingen aansluiten?
Ja. Elke Eventstream heeft een Kafka-endpoint, dus een toepassing die al via het Kafka-protocol produceert of consumeert, heeft alleen nieuwe verbindingsgegevens nodig.

3. Moet mijn data met hoge volumes stromen om dit zinvol te maken?
Nee. Real-Time Intelligence is gebouwd om te reageren op events wanneer ze gebeuren. Ook een bescheiden stroom, zoals enkele bestellingen per minuut, past prima in een Eventstream.

4. Wat kost een Eventstream?
Je betaalt via je Fabric-capaciteit, op basis van actieve uren, dataverkeer en rekenkracht. Een stream zonder verkeer stopt na twee uur met aanrekenen, maar een drukke stream die dag en nacht draait, voel je in je capaciteit. Meet dat eerst op kleine schaal voor je opschaalt.