Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Azure Event Hubs uitgelegd: realtime datastreaming met partities, consumergroepen en Kafka (AI-nasynchronisatie)

Transcript

Azure Event Hubs uitgelegd: realtime datastreaming met partities, consumergroepen en Kafka (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

• 0:00
  Speaker 2: Klaar voor 10 dagen Microsoft 365, Copilot, AI, Azure en
• 0:05
  Speaker 2: de mensen die de toekomst van werk vormgeven? Deze januari
• 0:09
  Speaker 2: is M365 komt terug en we pakken het groter aan.
• 0:12
  Speaker 2: Doe mee aan livesessies, praktijkdemo's en krijg praktische kennis van
• 0:16
  Speaker 2: MVP's en experts uit de hele wereld. Geen algemene slides,
• 0:20
  Speaker 2: geen eindeloos jargon. We pakken de echte uitdagingen aan Copilot Studio,
• 0:25
  Speaker 2: AI Agents, Fabric, Beveiliging, Governance en Automatisering. Of je nu IT-professional,
• 0:31
  Speaker 2: ontwikkelaar of zakelijk leider bent, er zijn sessies speciaal voor jou.
• 0:35
  Speaker 2: Met 10 volledige dagen kun je verschillende technologieën verkennen en
• 0:38
  Speaker 2: in contact komen met een wereldwijde community. Kijk live mee
• 0:41
  Speaker 2: en neem praktische inzichten mee terug naar je organisatie. Januari 2027,
• 0:46
  Speaker 2: 10 dagen, 1 Microsoft Community. De inschrijving is nu geopend.
• 0:51
  Speaker 2: Claim vandaag nog je plek. Dat kan op m365con.net. Meld
• 1:00
  Speaker 2: je nu aan op m365con.net, dan zien we je live
• 1:03
  Speaker 2: in januari. Welkom terug bij een nieuwe aflevering van Microsoft
• 1:07
  Speaker 2: Knowledge Nuggets. Ik ben je host Mirko Peters en vandaag
• 1:10
  Speaker 2: pakken we een reëel data-vraagstuk aan. Dus, laat me je
• 1:12
  Speaker 2: dit vragen. Stel je voor dat je in een fabriek
• 1:14
  Speaker 2: bent met duizend sensoren voor temperatuur, druk, trillingen, die continu
• 1:18
  Speaker 2: elke seconde een waarde doorgeven. Dat zijn dus duizend datapunten
• 1:21
  Speaker 2: per seconde. Twintig jaar geleden was de oplossing simpel. Je
• 1:25
  Speaker 2: verzamelde die data overdag, sloeg het op in een bestand,
• 1:28
  Speaker 2: draaide s'nachts een badge op om het te verwerken en
• 1:30
  Speaker 2: de volgende ochtend had je een rapport van wat er
• 1:32
  Speaker 2: gisteren gebeurde. Dat werkte prima toen snel genoeg betekende tegen morgenochtend.
• 1:37
  Speaker 2: Maar de wereld is veranderd. Sensoren werden goedkoper, apps slimmer
• 1:41
  Speaker 2: en gebruikers verwachten directe antwoorden. Nu betekent die nachtelijke badge
• 1:44
  Speaker 2: op dat je data altijd een dag oud is en
• 1:46
  Speaker 2: in een wereld waar een oververhitte machine binnen minuten brand
• 1:48
  Speaker 2: kan veroorzaken, heb je niets aan data van gisteren. Dus
• 1:51
  Speaker 2: stap je over op realtime waarbij je data verzamelt zodra
• 1:54
  Speaker 2: deze wordt gegenereerd. Maar hier begint de ellende. Probeer al
• 1:57
  Speaker 2: die streaming data maar eens in een traditionele database te stoppen,
• 2:00
  Speaker 2: die loopt direct vast. Databases zijn gebouwd voor queries en transacties,
• 2:04
  Speaker 2: niet om een waterval aan events te verwerken. Je probeert
• 2:06
  Speaker 2: een reguliere message queue en dat werkt even, maar queues
• 2:09
  Speaker 2: zijn ontworpen voor één consument die een bericht opbakt en verwerkt.
• 2:13
  Speaker 2: Ze zijn dus niet gebouwd voor miljoenen events per seconde
• 2:16
  Speaker 2: waarbij meerdere downstream systemen dezelfde stroom willen lezen. Dit is
• 2:20
  Speaker 2: de kern van de uitdaging. Je hebt een manier nodig
• 2:23
  Speaker 2: om enorme hoeveelheden data op te nemen, te bufferen zodat
• 2:25
  Speaker 2: er niets verloren gaat en in real-time te distribueren naar
• 2:28
  Speaker 2: meerdere consumenten. Dat is geen database probleem. Dat is geen
• 2:31
  Speaker 2: queue probleem. Het is een streaming probleem. Dus, wat is
• 2:33
  Speaker 2: de oplossing? Dat is waar Azure Event Hubs in beeld komt.
• 2:36
  Speaker 2: Wat is Azure Event Hubs? Hier is de eenvoudigste definitie.
• 2:39
  Speaker 2: Azure Event Hubs is een volledig beheerd real-time data streaming platform...
• 2:43
  Speaker 2: Speciaal gebouwd om miljoenen events per seconde te verwerken met
• 2:46
  Speaker 2: lage latentie. Merk op dat ik geen message queue of
• 2:48
  Speaker 2: database zei. Event hubs is geen wachtrij en het is
• 2:51
  Speaker 2: geen database. Het is een stream en dat verschil is belangrijk.
• 2:54
  Speaker 2: Een wachtrij houdt een bericht vast totdat één consumer het
• 2:56
  Speaker 2: opikt en dan is het weg. Een database slaat data
• 2:59
  Speaker 2: op zodat je die later kunt opvragen... Maar een stream
• 3:01
  Speaker 2: is anders. Het is een continu stroom van events die
• 3:03
  Speaker 2: meerdere lezers onafhankelijk en in hun eigen tempo kunnen lezen
• 3:06
  Speaker 2: zonder iets uit de stream te verwijderen. Laten we nu
• 3:09
  Speaker 2: een paar mythes uit de weg ruimen. Event Hubs kan
• 3:11
  Speaker 2: miljoenen events per seconde aan. We hebben het over het
• 3:14
  Speaker 2: opnemen van honderdduizenden berichten per seconde van duizenden producenten en
• 3:18
  Speaker 2: dat met een zeer lage latentie, milliseconden vanaf het moment
• 3:21
  Speaker 2: dat een event wordt verzonden tot het moment dat een
• 3:23
  Speaker 2: consumer het kan lezen. Hier is iets wat veel mensen verbaast.
• 3:26
  Speaker 2: Event Hubs is Kafka-compatibel. Dus als je eerder met Apache
• 3:29
  Speaker 2: Kafka hebt gewerkt... kun je je bestaande Kafka tools en
• 3:32
  Speaker 2: clients gebruiken... om met Event Hubs te communiceren zonder een
• 3:34
  Speaker 2: nieuw protocol te leren... of je applicaties te herschrijven. Het
• 3:37
  Speaker 2: spreekt dezelfde taal. De eenvoudigste manier om dit te zien...
• 3:40
  Speaker 2: is als een hoge snelheids voordeur voor data. Stel je
• 3:43
  Speaker 2: een druk kantoorgebouw voor tijdens de spits. Honderden mensen lopen
• 3:46
  Speaker 2: elke minuut door de voordeur... en de deur houdt ze
• 3:48
  Speaker 2: niet tegen, stelt geen vragen en stuurt ze niet naar
• 3:50
  Speaker 2: specifieke ruimtes. Het laat ze gewoon snel naar binnen. Dat
• 3:54
  Speaker 2: is Event Hubs. Het is de voordeur voor je data.
• 3:56
  Speaker 2: Het verwerkt de data niet, analyseert ze niet en beslist
• 3:58
  Speaker 2: niet wat ermee moet gebeuren. Het krijgt de data gewoon
• 4:01
  Speaker 2: zo snel mogelijk in je Azure-omgeving, zodat je downstream-systemen het
• 4:04
  Speaker 2: echte werk kunnen doen. Maar hoe werkt het eigenlijk? Laten
• 4:06
  Speaker 2: we de onderdelen opsplitsen, de bouwstenen, partities, consumer groups, doorvoer.
• 4:11
  Speaker 2: Binnen elke event hub zit een structuur die het geheel
• 4:13
  Speaker 2: laat werken. Het belangrijkste onderdeel is de partitie. Denk bij
• 4:16
  Speaker 2: een partitie aan een rijstrook op een snelweg. Data komt
• 4:18
  Speaker 2: binnen en belandt in een van deze rijstroken. Dit is
• 4:20
  Speaker 2: de kern. Binnen elke rijstrook blijft de volgorde van events
• 4:23
  Speaker 2: precies zoals ze aankwamen. Event 1 komt voor event 2
• 4:26
  Speaker 2: en event 2 voor event 3. Die volgorde verandert nooit
• 4:29
  Speaker 2: binnen die rijstrook. Dus als je applicatie events in de
• 4:31
  Speaker 2: exacte volgorde nodig heeft, hou je ze in dezelfde partitie.
• 4:33
  Speaker 2: Je kunt tussen de 2 en 32 partities per event
• 4:36
  Speaker 2: hub hebben en dit aantal stel je in wanneer je
• 4:38
  Speaker 2: de hub aanmaakt. Je kunt dit later niet meer wijzigen.
• 4:40
  Speaker 2: Je moet dus vooraf nadenken over je doorvoerbehoefte. Meer partities
• 4:43
  Speaker 2: betekenen meer parallelle verwerking. Als je een hoog volume aan
• 4:46
  Speaker 2: events verwacht, wil je meer partities, zodat meerdere consumers tegelijkertijd
• 4:50
  Speaker 2: uit verschillende banen kunnen lezen. Maar meer partities betekenen ook
• 4:53
  Speaker 2: meer complexiteit. De vuistregel is om te kiezen op basis
• 4:55
  Speaker 2: van je verwachte doorvoer, niet willekeurig. Als je het niet
• 4:58
  Speaker 2: zeker weet, begin dan kleiner en test. Partities alleen zijn
• 5:01
  Speaker 2: echter niet genoeg. Je hebt ook consumer groups nodig. Een
• 5:03
  Speaker 2: consumer group is simpelweg een afzonderlijke downstream applicatie die dezelfde
• 5:07
  Speaker 2: stream leest. Elke consumer group krijgt zijn eigen onafhankelijke kopie. Dus,
• 5:10
  Speaker 2: als je één groep hebt voor real-time analytics en een
• 5:13
  Speaker 2: andere voor archivering naar opslag, lezen ze beide tegelijkertijd dezelfde
• 5:16
  Speaker 2: events zonder elkaar te hinderen. De analyticsgroep leest temperatuurgegevens om
• 5:19
  Speaker 2: afwijkingen te detecteren. De archiveringsgroep leest dezelfde gegevens en verstuurt
• 5:22
  Speaker 2: deze naar een data lake voor lange termijn opslag. Beide
• 5:25
  Speaker 2: groepen zien elk event. Geen van beide groepen blokkeert de andere.
• 5:28
  Speaker 2: En dit is erg belangrijk. In een traditionele wachtrij wordt
• 5:30
  Speaker 2: een bericht door één processor geconsumeerd en daarna is het weg.
• 5:32
  Speaker 2: Hier kunnen meerdere consumers onafhankelijk dezelfde stream lezen. Dat is
• 5:35
  Speaker 2: de kracht van consumer groups. Maar hoe meet je hoeveel
• 5:38
  Speaker 2: gegevens je eventhub kan verwerken? Daarvoor zijn throughput units. Een
• 5:41
  Speaker 2: throughput unit, of TU, is hoe we de capaciteit meten.
• 5:44
  Speaker 2: Een TU geeft je 1 megabyte per seconde aan inkomende
• 5:47
  Speaker 2: data en 2 megabyte per seconde aan uitgaande data. Dus
• 5:50
  Speaker 2: als je 10 megabyte per seconde moet opnemen, heb je
• 5:52
  Speaker 2: tenminste 10 TUS nodig. Je kunt handmatig opschalen of je
• 5:55
  Speaker 2: kunt auto en fleet inschakelen, wat automatisch je TUS verhoogt
• 5:58
  Speaker 2: bij pieken in het verkeer. Je betaalt voor het maximale
• 6:00
  Speaker 2: aantal TUS dat in een uur is gebruikt. Dus als
• 6:03
  Speaker 2: je gedurende 10 minuten 20 TUS gebruikt, betaal je voor
• 6:06
  Speaker 2: 20 dus voor dat hele uur. Nog een onderdeel, retentie.
• 6:09
  Speaker 2: Events verdwijnen niet uit de hub nadat ze zijn geconsumeerd.
• 6:11
  Speaker 2: Ze blijven gedurende een instelbare periode in de hub staan.
• 6:14
  Speaker 2: In de standaardlaag is dat 1 tot 7 dagen. In
• 6:16
  Speaker 2: de premiumlaag tot wel 90 dagen. Dit maakt iets mogelijk
• 6:18
  Speaker 2: dat replay wordt genoemd. Als je downstream consumer faalt, of
• 6:21
  Speaker 2: als je gegevens opnieuw moet verwerken voor een nieuwe analyse,
• 6:24
  Speaker 2: kun je teruggaan en oude events opnieuw lezen. Dat is
• 6:26
  Speaker 2: anders dan bij een wachtrij waar een bericht voor goed
• 6:28
  Speaker 2: weg is zodra het is geconsumeerd. Je kent nu de onderdelen,
• 6:31
  Speaker 2: maar hoe werken ze eigenlijk samen in een echt systeem?
• 6:33
  Speaker 2: Hoe het werkt? Het producent- en consumentmodel. Laten we de
• 6:37
  Speaker 2: stroom van begin tot eind doorlopen. Aan de ene kant
• 6:39
  Speaker 2: heb je producenten. Een producent is elke applicatie of apparaat
• 6:42
  Speaker 2: dat gebeurtenissen naar de hub stuurt. Dit kan een temperatuursensor
• 6:45
  Speaker 2: in een fabriek zijn, een webserver die paginabezoeken logt, of
• 6:48
  Speaker 2: een bankapp die transactiegegevens verstuurt. Producenten kunnen communiceren met eventhubs
• 6:52
  Speaker 2: via drie verschillende protocollen, AMQP, HTTPS of Kafka, dus welke
• 6:56
  Speaker 2: taal of welk platform je ook gebruikt. Er is altijd
• 6:58
  Speaker 2: een manier om verbinding te maken. Wanneer een producent een
• 7:00
  Speaker 2: gebeurtenis verstuurt, beslist de HAP in welke partitie deze terechtkomt.
• 7:02
  Speaker 2: Standaard worden gebeurtenissen verdeeld op basis van een round-robin methode.
• 7:05
  Speaker 2: De eerste gebeurtenis gaat naar partitie 1, de tweede naar
• 7:08
  Speaker 2: partitie 2, enzovoort. Maar je kunt ook een partitiesleutel gebruiken.
• 7:11
  Speaker 2: Als je wilt dat alle gebeurtenissen van hetzelfde apparaat in
• 7:13
  Speaker 2: dezelfde partitie belanden, stel je het apparaat ID in als partitiesleutel.
• 7:16
  Speaker 2: Op die manier blijft de volgorde van gebeurtenissen van dat
• 7:18
  Speaker 2: apparaat behouden. De HAP zelf doet niet veel aan verwerking.
• 7:21
  Speaker 2: Het buffert de gebeurtenissen en slaat ze op in de
• 7:23
  Speaker 2: partities voor de bewaarperiode. Zie het als een tijdelijke opslagruimte.
• 7:26
  Speaker 2: De gebeurtenissen staan daar te wachten tot iemand ze leest.
• 7:29
  Speaker 2: Aan de andere kant heb je consumenten. Consumenten zijn downstream
• 7:31
  Speaker 2: applicaties die gegevens van de hub lezen. En dit is
• 7:34
  Speaker 2: het belangrijke gedeelte. Consumenten gebruiken een poolmodel. Ze bepalen hun
• 7:37
  Speaker 2: eigen tempo. Ze krijgen geen gebeurtenissen gepust, maar vragen erom
• 7:41
  Speaker 2: wanneer ze er klaar voor zijn. Dit is anders dan
• 7:42
  Speaker 2: bij een wachtrij, waar het systeem berichten naar een consument bust.
• 7:45
  Speaker 2: Hier bepaalt de consument wanneer de volgende batch wordt opgehaald.
• 7:48
  Speaker 2: Elke consumentengroep houdt zijn eigen positie in de stream bij.
• 7:51
  Speaker 2: Deze positie wordt een offset genoemd. De offset vertelt de
• 7:54
  Speaker 2: consument welke gebeurtenissen al zijn verwerkt. En de consument slaat
• 7:57
  Speaker 2: deze offset ergens duurzaam op, meestal in Azure Blob Opslag.
• 8:01
  Speaker 2: Dit proces heet checkpointing. Dit is waarom checkpointing belangrijk is.
• 8:04
  Speaker 2: Stel je voor dat je consument-applicatie crash halverwege het verwerken
• 8:07
  Speaker 2: van een batch gebeurtenissen. Bij herstart leest het het laatste
• 8:10
  Speaker 2: checkpoint uit de Blob Opslag en hervat het vanaf dat
• 8:12
  Speaker 2: exacte punt. Het verwerkt geen oude gebeurtenissen opnieuw en slaat
• 8:15
  Speaker 2: geen gebeurtenissen over. Het gaat precies verder waar het gebleven was.
• 8:18
  Speaker 2: En dat is betrouwbaarheid zonder complexiteit. Het belangrijkste inzicht is
• 8:21
  Speaker 2: dat EventHubs producenten volledig ontkoppelt van consumenten. Producenten weten niet
• 8:25
  Speaker 2: wie hun gegevens leest. Consumenten weten niet wie de gegevens verstuurt.
• 8:28
  Speaker 2: Ze zijn onafhankelijk. De HAP zit in het midden, buffert
• 8:30
  Speaker 2: en verdeelt gebeurtenissen, en beide kanten werken op hun eigen tempo.
• 8:33
  Speaker 2: En die ontkoppeling is wat EventHAP zo krachtig maakt voor
• 8:35
  Speaker 2: het bouwen van schaalbare, veerkrachtige systemen. Laten we dit concreet
• 8:39
  Speaker 2: maken met praktijkscenario's. Gebruikscenario's uit de praktijk. Laten we beginnen
• 8:43
  Speaker 2: met de grootste IoT-telemetrie. Stel je een slimme fabriek voor
• 8:46
  Speaker 2: met duizenden sensoren. Elke machine heeft sensoren die temperatuur, druk,
• 8:50
  Speaker 2: trillingen en energieverbruik meten, en elke sensor stuurt om de
• 8:53
  Speaker 2: paar seconden een waarde. Dat zijn geen honderden gebeurtenissen per seconde,
• 8:56
  Speaker 2: maar honderdduizenden, misschien wel miljoenen, afhankelijk van de grootte van
• 8:59
  Speaker 2: de fabriek. Dat kun je niet opslaan in een traditionele
• 9:01
  Speaker 2: database en je kunt het niet verwerken met een batchjob
• 9:03
  Speaker 2: die één keer per dag draait. Tegen de tijd dat
• 9:05
  Speaker 2: je het rapport krijgt, kan een machine al oververhit zijn
• 9:07
  Speaker 2: geraakt en de productie hebben stilgelegd. Dus stuur je al
• 9:09
  Speaker 2: die sensordata naar event hubs dat deze enorme stroom verwerkt
• 9:12
  Speaker 2: zonder enige moeite. Vervolgens koppel je Azure Stream Analytics aan
• 9:15
  Speaker 2: de hub en worden er real-time queries op de data uitgevoerd.
• 9:18
  Speaker 2: Wanneer een temperatuurmeting een drempelwaarde overschrijdt, wordt er een waarschuwing verstuurd,
• 9:21
  Speaker 2: wordt een onderhoudsteam ingelicht en wordt de machine uitgeschakeld voordat
• 9:24
  Speaker 2: deze uitvalt. Dat is voorspellend onderhoud in de praktijk. Een
• 9:27
  Speaker 2: ander veel voorkomend gebruikscenario is applicatie logging en monitoring. Stel
• 9:30
  Speaker 2: dat je een microservices architectuur beheert met 50 verschillende services
• 9:33
  Speaker 2: die elk iets anders doen. Elke service genereert logbestanden met fouten,
• 9:36
  Speaker 2: waarschuwingen en prestatiestatistieken. Vroeger schreef je die laks naar bestanden
• 9:40
  Speaker 2: op elke server en als er iets misging, moest je
• 9:42
  Speaker 2: op vijf verschillende machines inloggen om de fout te vinden.
• 9:44
  Speaker 2: Dat is een nachtmerrie. In plaats daarvan laat je elke
• 9:47
  Speaker 2: service zijn laks naar één eventhub sturen, één centrale pijplijn.
• 9:52
  Speaker 2: Daarna maak je meerdere consumentengroepen aan. Eén groep leest de
• 9:55
  Speaker 2: stroom en stuurt kritieke fouten naar een real-time waarschuwingssysteem. Een
• 9:57
  Speaker 2: andere groep leest dezelfde stroom en stuurt kritieke fouten naar
• 9:59
  Speaker 2: een real-time waarschuwingssysteem. en schrijft alle laks naar Azure Data
• 10:01
  Speaker 2: Lake voor lange termijnopslag en analyse. Een derde groep voedt
• 10:04
  Speaker 2: een live dashboard dat de systeemgezondheid toont. Elk team ziet
• 10:07
  Speaker 2: dezelfde data in real-time zonder elkaar te hinderen. Clickstream-analyse is
• 10:11
  Speaker 2: een andere grote. Stel je voor dat je een e-commerce
• 10:13
  Speaker 2: website runt. Elke klik, paginaweergave, zoekopdracht en toevoegen aan winkelwagen,
• 10:17
  Speaker 2: actie wordt naar eventhubs gestuurd. Dat is een enorme stroom
• 10:19
  Speaker 2: aan gebruikersgedrag data. Downstream-consumenten analyseren de stroom in real-time. Een
• 10:23
  Speaker 2: consument bouwt gebruikersprofielen op die laten zien welke producten mensen
• 10:26
  Speaker 2: bekijken en welke categorieën ze doorzoeken. Een andere consument detecteert
• 10:29
  Speaker 2: trends en ziet welke producten plotseling populair worden. Een derde
• 10:32
  Speaker 2: consument personaliseert de winkelervaring door aanbevelingen te tonen op basis
• 10:35
  Speaker 2: van waar de gebruiker net op heeft geklikt. Dit alles
• 10:37
  Speaker 2: gebeurt in milliseconden, niet van de ene op de andere dag.
• 10:39
  Speaker 2: En dan is er nog fraudedetectie in de financiële sector.
• 10:42
  Speaker 2: Banken verwerken elke dag miljoenen transacties. Creditcardbetalingen, overboekingen, onlinebetalingen. Elke
• 10:47
  Speaker 2: transactie is een gebeurtenis en elke transactie moet in realtime
• 10:50
  Speaker 2: worden beoordeeld op fraude. Je kunt niet wachten op een batchverwerking,
• 10:53
  Speaker 2: want als een frauduleuze transactie wordt goedgekeurd... is het geld weg.
• 10:56
  Speaker 2: De stream te bank elke transactie naar event hubs. Stroomafwaarts
• 10:59
  Speaker 2: consumeren machine learning modellen de stream en beoordelen ze elke
• 11:02
  Speaker 2: transactie op fraude risico, verdachte transacties worden binnen enkele seconden
• 11:05
  Speaker 2: gemarkeerd en geblokkeerd. Ondertussen voeden afzonderlijke consumentengroepen dezelfde stream aan
• 11:09
  Speaker 2: compliance systemen voor wettelijke rapportage en aan operationele dashboards voor
• 11:13
  Speaker 2: het monitoren van transactievolumes. Drie verschillende consumenten lezen allemaal dezelfde
• 11:17
  Speaker 2: stream en doen allemaal verschillende dingen. De rode draad in
• 11:20
  Speaker 2: al deze scenario's is hetzelfde. Hoog volume, meerdere consumenten en
• 11:24
  Speaker 2: de behoefte aan real-time inzicht. Event Hubs is niet de
• 11:26
  Speaker 2: oplossing voor elk probleem, maar bij deze combinatie is het
• 11:29
  Speaker 2: de juiste tool voor de klus. Event Hubs is echter
• 11:31
  Speaker 2: niet de enige berichtenservice in Azure. Laten we het vergelijken
• 11:35
  Speaker 2: met de andere. Event Hubs vs Event Grid vs Service Bus.
• 11:38
  Speaker 2: Azure heeft drie hoofddiensten voor het verplaatsen van gegevens. Event Grid,
• 11:41
  Speaker 2: Event Hubs en Service Bus. Mensen halen ze constant door elkaar,
• 11:44
  Speaker 2: dus laten we de verwarring wegnemen. Event Grid is het rookalarm.
• 11:47
  Speaker 2: Het is lichtgewicht en reactief. Wanneer er iets gebeurt, een
• 11:50
  Speaker 2: blob wordt geüpload naar opslag, een virtuele machine van status
• 11:54
  Speaker 2: verandert of een resource wordt aangemaakt. EventGrid vuurt een gebeurtenis af.
• 11:58
  Speaker 2: Het vervoert de gegevens zelf niet, het zegt alleen, hé,
• 12:00
  Speaker 2: er is iets gebeurd. Vervolgens stuurt het die melding door
• 12:02
  Speaker 2: naar handlers zoals Azure Functions of Logic App. Eventgrid is
• 12:05
  Speaker 2: geen stream en is niet ontworpen voor een hoge doorvoer.
• 12:08
  Speaker 2: Het is voor discrete gebeurtenissen die een snelle reactie vereisen.
• 12:10
  Speaker 2: Het beste voor blob upload triggers, wijzigingen in resource status
• 12:13
  Speaker 2: en serverloze workflows. Servicebus is de postdienst. Het is betrouwbaar,
• 12:17
  Speaker 2: geordend en garandeert aflevering. Wanneer je een bericht via Servicebus verstuurt,
• 12:21
  Speaker 2: weet je zeker dat het aankomt. Het ondersteunt first-in-first-out-ordening, detectie
• 12:24
  Speaker 2: van duplicaten en transacties. Als de verwerking van een bericht mislukt,
• 12:27
  Speaker 2: gaat het naar een wachtrij voor dodenbrieven waar je het
• 12:29
  Speaker 2: later kunt inspecteren. Servicebus is gebouwd voor bedrijfscritische workflows zoals betalingsverwerking,
• 12:34
  Speaker 2: orderafhandeling en goedkeuringsketens. Het verwerkt duizenden berichten per seconde, geen miljoenen,
• 12:38
  Speaker 2: en dat is prima, want bij het verwerken van een
• 12:40
  Speaker 2: betaling heb je geen miljoenen gebeurtenissen per seconde nodig. Je
• 12:42
  Speaker 2: hebt nodig dat elk bericht precies één keer in de
• 12:44
  Speaker 2: juiste volgorde aankomt. Event Hubs is de beveiligingscamera. Het registreert
• 12:48
  Speaker 2: alles voor terugkijken en analyse. Het is gebouwd voor streaming
• 12:51
  Speaker 2: met een hoog volume, miljoenen gebeurtenissen per seconde en meerdere
• 12:53
  Speaker 2: consumenten kunnen onafhankelijk van elkaar dezelfde stream lezen. Gebeurtenissen blijven
• 12:56
  Speaker 2: dagen of weken in de Hubs staan, zodat je ze
• 12:58
  Speaker 2: indien nodig opnieuw kunt afspelen. Event Hubs is niet bedoeld
• 13:00
  Speaker 2: voor transactionele berichtgeving. Het is bedoeld voor telemetrie, analyse, pijplijnen
• 13:04
  Speaker 2: en elk scenario waarin je enorme hoeveelheden gegevens moet opnemen
• 13:07
  Speaker 2: en distribueren naar meerdere consumenten. Dus, hoe maak je een keuze?
• 13:10
  Speaker 2: Stel jezelf drie vragen. Reageer je op een verandering? Een
• 13:13
  Speaker 2: blob is geüpload, een VM is gemaakt, een resource is
• 13:15
  Speaker 2: van status veranderd. Dat is Event Grid. Heb je gegarandeerde
• 13:18
  Speaker 2: aflevering en strikte volgorde nodig? Het verwerken van betalingen, uitvoeren
• 13:21
  Speaker 2: van workflows, coördineren van zakelijke transacties? Dat is Service Bus.
• 13:24
  Speaker 2: Stream je enorme hoeveelheden data voor analytics, IoT telemetrie, applicatielogboeken, klikstromen, fraudedetectie?
• 13:31
  Speaker 2: Dat is Event Hubs. Hier is het punt. Je hoeft
• 13:33
  Speaker 2: er niet slechts één te kiezen. Deze services werken samen.
• 13:36
  Speaker 2: Event Hubs neemt de ruwe datastroom op. EventGrid reageert op
• 13:39
  Speaker 2: gebeurtenissen binnen die stroom en activeert downstream acties. Servicebus regelt
• 13:43
  Speaker 2: de betrouwbare berichtgeving voor zakelijke workflows. Gebruik ze samen en
• 13:46
  Speaker 2: je krijgt het beste van alle werelden. Laten we praten
• 13:49
  Speaker 2: over de kosten van het draaien van dit soort pijplijn.
• 13:51
  Speaker 2: Prijzen en niveaus. Laten we over kosten praten, want weten
• 13:54
  Speaker 2: wat EventHubs doet is één ding, maar weten wat het
• 13:56
  Speaker 2: kost is iets heel anders. EventHubs heeft vier niveaus en
• 13:59
  Speaker 2: Basic is de goedkoopste. Het geeft je één dag retentie,
• 14:02
  Speaker 2: beperkte functies en de laagste kosten per doorvoereenheid. Dat werkt
• 14:05
  Speaker 2: voor eenvoudige scenario's waar je niet veel nodig hebt, maar
• 14:07
  Speaker 2: de meeste mensen slaan basic over en beginnen met standard.
• 14:10
  Speaker 2: Standard is het ideale midden. Het biedt tot 7 dagen retentie,
• 14:13
  Speaker 2: event hubs, capture voor automatische archivering naar opslag, Kafka compatibiliteit
• 14:17
  Speaker 2: en tot 20 consumentengroepen. Dat dekt de meeste productieworkloads, dus
• 14:21
  Speaker 2: als je iets echt bouwt, is dit meestal waar je begint.
• 14:23
  Speaker 2: Premium is een stap omhoog. Je krijgt 90 dagen retentie,
• 14:26
  Speaker 2: 1 terabyte opslag per verwerkingseenheid, voorspelbare prestaties en VNet ondersteuning
• 14:30
  Speaker 2: voor netwerkisolatie. Gereserveerde resources betekenen dat drukke buren je niet
• 14:33
  Speaker 2: beïnvloeden en dit niveau is gebouwd voor hoogwaardige workloads waar
• 14:36
  Speaker 2: latentie en isolatie ertoe doen. Dedicated is het topniveau. Een
• 14:39
  Speaker 2: single tenant cluster speciaal voor jou met 10 terabyte per capaciteitseenheid.
• 14:42
  Speaker 2: Het is voor zeer grote workloads waar je de hele
• 14:44
  Speaker 2: omgeving voor jezelf nodig hebt. Ja, het is duur, maar
• 14:47
  Speaker 2: als je constant enorme volumes verwerkt. kan het kosteneffectiever zijn
• 14:50
  Speaker 2: dan het schalen van premium. Dus wat bepaalt de kosten,
• 14:53
  Speaker 2: vier dingen, doorvoereenheden, oftewel hoeveel data je verplaatst, retentieduur, hoe
• 14:57
  Speaker 2: lang je gebeurtenissen bewaart, capture of je archiveert naar opslag
• 15:01
  Speaker 2: en georeplicatie als je data kopieert over regio's voor noodherstel.
• 15:06
  Speaker 2: Hier zijn een paar tips voor kostenoptimalisatie. Begin met standaard
• 15:09
  Speaker 2: en schaal pas op wanneer dat nodig is. Gebruik een
• 15:11
  Speaker 2: korte retentieperiode voor actuele data. Bewaar het een of twee
• 15:14
  Speaker 2: dagen in de hab en verplaats het daarna naar goedkopere
• 15:16
  Speaker 2: opslag zoals blob of data lake voor analyse op lange termijn.
• 15:19
  Speaker 2: Monitor uw doorvoergebruik, schaal uw TU's correct en voorkom overprovisioning.
• 15:23
  Speaker 2: Gebruik waar mogelijk ook HTTP voor verzenders in plaats van AMQP,
• 15:27
  Speaker 2: omdat AMQP verbindingen kosten met zich meebrengen en HTTP niet.
• 15:30
  Speaker 2: Laten we nu een eenvoudige architectuur doorlopen om te zien
• 15:33
  Speaker 2: hoe u echt van start gaat. Aan de slag, een
• 15:35
  Speaker 2: eenvoudige architectuur. Het basispatroon is simpel. Producenten sturen events naar
• 15:39
  Speaker 2: eventhubs en consumenten lezen vanuit eventhubs. Dat is alles. Hier
• 15:43
  Speaker 2: is een concreet voorbeeld. Stel je voor dat IoT-apparaten temperatuurgegevens
• 15:46
  Speaker 2: naar eventhubs sturen. Een Azure-functie wordt geactiveerd door elke nieuwe
• 15:49
  Speaker 2: batch events en de functie verwerkt de data. Deze kan
• 15:52
  Speaker 2: metingen binnen het normale bereik filteren, alleen de afwijkingen bewaren
• 15:55
  Speaker 2: en deze vervolgens naar Cosmos DB schrijven voor snelle queries.
• 15:58
  Speaker 2: Dat is een volledige pipeline in drie services. Het mooie
• 16:01
  Speaker 2: van functies is dat ze automatisch schalen met het aantal partities.
• 16:04
  Speaker 2: Als u acht partities heeft, kunnen functies tot acht instanties
• 16:07
  Speaker 2: opstarten die elk lezen.