Functies en terminologie in Azure Event Hubs

Azure Event Hubs is een schaalbare gebeurtenisverwerkingsservice die grote hoeveelheden gebeurtenissen en gegevens opneem en verwerkt, met lage latentie en hoge betrouwbaarheid. Zie Wat is Event Hubs? voor een overzicht op hoog niveau.

Dit artikel bouwt voort op de informatie in hetoverzichtsartikel en biedt technische en implementatiedetails over Event Hubs onderdelen en functies.

Naamruimte

Een Event Hubs is een beheercontainer voor Event Hubs (of onderwerpen, in Kafka-parlance). Het biedt met DNS geïntegreerde netwerk eindpunten en een scala aan functies voor toegangsbeheer en netwerkintegratie, zoals IP-filtering,service-eindpunt voor virtuele netwerken en Private Link.

Gebeurtenisuitgevers

Elke entiteit die gegevens naar een Event Hub verzendt, is een gebeurtenisuitgever (synoniem gebruikt met gebeurtenisproducent). Gebeurtenisuitgevers kunnen gebeurtenissen publiceren met HTTPS of AMQP 1.0 of het Kafka-protocol. Gebeurtenisuitgevers gebruiken Azure Active Directory op basis van verificatie met door OAuth2 uitgegeven JWT-tokens of een Event Hub-specifiek Shared Access Signature (SAS)-token om publicatietoegang te krijgen.

Een gebeurtenis publiceren

U kunt een gebeurtenis publiceren via AMQP 1.0, het Kafka-protocol of HTTPS. De Event Hubs-service biedt REST API- en .NET-clientbibliotheken voor Java, Python, JavaScripten Go voor het publiceren van gebeurtenissen naar een Event Hub. Voor andere runtimes en platforms kunt u een AMQP 1.0-client gebruiken, zoals Apache Qpid.

De keuze om AMQP of HTTPS te gebruiken, geldt specifiek voor het gebruiksscenario. AMQP vereist de inrichting van een permanente bidirectionele socket naast Transport Layer Security (TLS) of SSL/TLS. AMQP heeft hogere netwerkkosten bij het initialiseren van de sessie, maar HTTPS vereist extra TLS-overhead voor elke aanvraag. AMQP biedt aanzienlijk betere prestaties voor frequente uitgevers en kan veel lagere latentie bereiken bij gebruik met asynchrone publicatiecode.

U kunt gebeurtenissen afzonderlijk of in batch publiceren. Eén publicatie heeft een limiet van 1 MB, ongeacht of het om één gebeurtenis of om een batch gaat. Publicatiegebeurtenissen die groter zijn dan deze drempelwaarde, worden geweigerd.

Event Hubs doorvoer wordt geschaald met behulp van partities en toewijzingen van doorvoereenheden (zie hieronder). Het is een best practice voor uitgevers om zich niet bewust te zijn van het specifieke partitioneringsmodel dat is gekozen voor een Event Hub en om alleen een partitiesleutel op te geven die wordt gebruikt om gerelateerde gebeurtenissen consistent toe te wijzen aan dezelfde partitie.

Event Hubs zorgt ervoor dat alle gebeurtenissen die een partitiesleutelwaarde delen, samen worden opgeslagen en geleverd op volgorde van aankomst. De identiteit van de uitgever en de waarde van de partitiesleutel moeten overeenkomen als er partitiesleutels met uitgeversbeleid worden gebruikt. Anders treedt er een fout op.

Retentie van gebeurtenissen

Gepubliceerde gebeurtenissen worden verwijderd uit een Event Hub op basis van een configureerbaar retentiebeleid op basis van tijd. Hier zijn enkele belangrijke punten:

• De standaardwaarde en kortst mogelijke bewaarperiode zijn 1 dag (24 uur).
• Voor Event Hubs Standard is de maximale bewaarperiode 7 dagen.
• Voor Event Hubs Premium dedicated is de maximale bewaarperiode 90 dagen.
• Als u de bewaarperiode wijzigt, is deze van toepassing op alle berichten, inclusief berichten die zich al in de Event Hub hebben.

Event Hubs bewaart gebeurtenissen voor een geconfigureerde bewaartijd die wordt toegepast op het niveau van alle partities. Gebeurtenissen worden automatisch verwijderd wanneer de retentieperiode is bereikt. Als u een retentieperiode van één dag opgeeft, wordt de gebeurtenis precies 24 uur nadat deze is geaccepteerd onbeschikbaar. U kunt gebeurtenissen niet expliciet verwijderen.

Als u gebeurtenissen buiten de toegestane bewaarperiode wilt archiveren, kunt u deze automatisch laten opslaan in Azure Storage of Azure Data Lake door de functie Event Hubs Capture in te schakelt. Als u dergelijke diepe archieven wilt doorzoeken of analyseren, kunt u ze eenvoudig importeren in Azure Synapse of andere vergelijkbare archieven en analyseplatforms.

De limiet op de retentieperiode voor Event Hubs is om te voorkomen dat grote hoeveelheden historische klantgegevens worden vastgelegd in een archief dat alleen wordt geïndexeerd per timestamp en alleen sequentiële toegang toestaat. De architectuurstijl hier is dat historische gegevens uitgebreidere indexering en directere toegang nodig hebben dan de realtime gebeurtenisinterface die Event Hubs of Kafka biedt. Gebeurtenisstroomen engines zijn niet geschikt om de rol van data lakes of langetermijnarchieven voor gebeurtenissourcing te spelen.

Uitgeversbeleid

In Event Hubs kunt u gebeurtenisuitgevers nauwkeurig beheren met behulp van uitgeversbeleid. Uitgeversbeleid bestaat uit runtimefuncties die zijn ontworpen om grote aantallen onafhankelijke gebeurtenisuitgevers mogelijk te maken. Als u uitgeversbeleid implementeert, gebruikt elke uitgever zijn eigen unieke id bij het publiceren van gebeurtenissen naar een Event Hub. Hierbij wordt het volgende mechanisme gebruikt:

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

Het is niet nodig om van tevoren uitgeversnamen te maken. De namen moeten echter wel overeenkomen met het SAS-token dat wordt gebruikt wanneer een gebeurtenis wordt gepubliceerd. Hiermee wordt voor onafhankelijke uitgeversidentiteiten gezorgd. Als u uitgeversbeleid gebruikt, is de waarde Partitiesleutel ingesteld op de naam van de uitgever. Voor een goede werking moeten deze waarden overeenkomen.

Vastleggen

Event Hubs Capture kunt u automatisch de streaminggegevens vastleggen in Event Hubs en opslaan in een Blob Storage-account of een Azure Data Lake Storage-account. U kunt vastleggen vanuit de Azure Portal en een minimale grootte en tijdvenster opgeven om de opname uit te voeren. Met Event Hubs Capture geeft u uw eigen Azure Blob Storage-account en -container op, of een Azure Data Lake Storage-account, waarvan er één wordt gebruikt voor het opslaan van de vastgelegde gegevens. Vastgelegde gegevens worden geschreven in de Apache Avro-indeling.

De bestanden die door Event Hubs Capture worden geproduceerd, hebben het volgende Avro-schema:

Partities

Event Hubs organiseert reeksen gebeurtenissen die naar een Event Hub worden verzonden, in een of meer partities. Als er nieuwere gebeurtenissen plaatsvinden, worden deze toegevoegd aan het einde van deze reeks.

Een partitie kan worden zien als een 'commit log'. Partities bevatten gebeurtenisgegevens die de body van de gebeurtenis bevatten, een door de gebruiker gedefinieerde eigenschappentas die de gebeurtenis beschrijft, metagegevens zoals de offset in de partitie, het nummer in de stroomreeks en het tijdstempel aan de servicezijde waarop deze is geaccepteerd.

Voordelen van het gebruik van partities

Event Hubs is ontworpen om te helpen bij het verwerken van grote hoeveelheden gebeurtenissen. Partitioneren draagt hier op twee manieren aan bij:

• Hoewel Event Hubs een PaaS-service is, ligt er een fysieke realiteit onder en voor het onderhouden van een logboek dat de volgorde van gebeurtenissen behoudt, moeten deze gebeurtenissen worden bewaard in de onderliggende opslag en de replica's, wat resulteert in een doorvoer maximum voor een dergelijk logboek. Partitionering maakt het mogelijk om meerdere parallelle logboeken te gebruiken voor dezelfde Event Hub en dus de beschikbare onbewerkte I/O-doorvoercapaciteit te vermenigvuldigen.
• Uw eigen toepassingen moeten het volume aan gebeurtenissen dat naar een Event Hub wordt verzonden, kunnen blijven verwerken. Dit kan complex zijn en vereist aanzienlijke, uitgeschaalde en parallelle verwerkingscapaciteit. De capaciteit van één proces voor het afhandelen van gebeurtenissen is beperkt, dus u hebt verschillende processen nodig. Partities zijn de manier waarop uw oplossing deze processen verwerkt en er toch voor zorgt dat elke gebeurtenis een duidelijke verwerkingseigenaar heeft.

Aantal partities

Het aantal partities wordt opgegeven op het moment dat een Event Hub wordt gemaakt. Dit moet tussen 1 en het maximum aantal partities zijn dat is toegestaan voor elke prijscategorie. Zie dit artikel voor de limiet voor het aantal partities voor elke laag.

U wordt aangeraden minstens zo veel partities te kiezen als verwacht tijdens de piekbelasting van uw toepassing voor die specifieke Event Hub. U kunt het aantal partities voor een Event Hub na het maken niet wijzigen, met uitzondering van de Event Hub in een toegewezen cluster en premium-laag. Het aantal partities van een Event Hub in een toegewezen Event Hubs-cluster kan worden verhoogd nadat de Event Hub is gemaakt, maar de distributie van stromen over partities verandert als deze klaar is, omdat de toewijzing van partitiesleutels aan partities verandert. U kunt dus het beste proberen om dergelijke wijzigingen zoveel mogelijk te vermijden als de relatieve volgorde van gebeurtenissen in uw toepassing van belang is.

Het instellen van het aantal partities op de maximaal toegestane waarde is verleidelijk, maar u moet er altijd rekening mee houden dat uw gebeurtenissenstromen zo moeten worden gestructureerd dat u wel kunt profiteren van meerdere partities. Als u de volgorde van alle gebeurtenissen of voor een klein aantal substromen echt moet behouden, kunt u misschien niet profiteren van het gebruik van veel partities. Daarnaast maken veel partities de verwerkingszijde complexer.

Het maakt niet uit hoeveel partities een Event Hub heeft als het gaat om prijzen. Dit is afhankelijk van het aantal prijseenheden(doorvoereenheden (TUS's) voor de Standard-laag, verwerkingseenheden (PUS's) voor de Premium-laag en capaciteitseenheden (CUs) voor de toegewezen laag) voor de naamruimte of het toegewezen cluster. Voor een Event Hub van de standard-laag met 32 partities of met 1 partitie worden bijvoorbeeld exact dezelfde kosten in gebruik wanneer de naamruimte is ingesteld op 1 TU-capaciteit. U kunt ook DEP's of PUS's op uw naamruimte of DE's van uw toegewezen cluster schalen, onafhankelijk van het aantal partities.

Gebeurtenissen toewijzen aan partities

U kunt een partitiesleutel gebruiken om inkomende gebeurtenisgegevens toe te wijzen aan specifieke partities, zodat de gegevens kunnen worden geordend. De partitiesleutel is een door de afzender opgegeven waarde die aan een Event Hub wordt doorgegeven. De partitiesleutel wordt verwerkt door een statische hash-functie, die zorgt voor de partitietoewijzing. Als u bij het publiceren van een gebeurtenis geen partitiesleutel opgeeft, wordt er gebruikgemaakt van round robin-toewijzing.

De gebeurtenisuitgever is alleen op de hoogte van de partitiesleutel en niet van de partitie waarop de gebeurtenissen worden gepubliceerd. Deze ontkoppeling van sleutel en partitie schermt de afzender af, zodat deze niet te veel te weten hoeft te komen over de downstreamverwerking. Goede partitiesleutels zijn bijvoorbeeld een apparaatspecifieke of een gebruikersspecifieke identiteit, maar voor het groeperen van gerelateerde gebeurtenissen in dezelfde partitie kunnen ook andere kenmerken, zoals geografie, worden gebruikt.

Door een partitiesleutel op te geven, kunnen gerelateerde gebeurtenissen bij elkaar worden geplaatst in dezelfde partitie en in de exacte volgorde waarin ze zijn aangekomen. De partitiesleutel is een tekenreeks die is afgeleid van uw toepassingscontext en identificeert de relatie tussen de gebeurtenissen. Een reeks gebeurtenissen die wordt geïdentificeerd door een partitiesleutel is een stroom. Een partitie is een multiplex-logboekopslag voor veel van zulke stromen.

SAS-tokens

Event Hubs maakt gebruik van Shared Access Signatures, die beschikbaar zijn op het niveau van de naamruimte en event hub. Een SAS-token wordt gegenereerd uit een SAS-sleutel en is een SHA-hash of URL. gecodeerd in een specifieke indeling. Event Hubs kan de hash opnieuw genereren met de naam van de sleutel (het beleid) en de token, en op deze manier de afzender verifiëren. Normaal gesproken worden SAS-tokens voor gebeurtenisuitgevers gemaakt met alleen verzendbevoegdheden voor een specifieke Event Hub. Dit URL-mechanisme met SAS-token vormt de basis voor de uitgeversidentificatie die in het uitgeversbeleid wordt geïntroduceerd. Zie Shared Access Signature-verificatie met Service Bus voor meer informatie over werken met SAS.

Gebeurtenisconsumers

Elke entiteit die gebeurtenisgegevens van een Event Hub leest, is een gebeurtenis consumer. Alle Event Hubs-consumers maken verbinding via de AMQP 1.0-sessie, waarin gebeurtenissen worden geleverd zodra deze beschikbaar komen. De client hoeft de beschikbaarheid van de gegevens niet te peilen.

Consumentengroepen

Het mechanisme voor publiceren/abonneren van Event Hubs wordt ingeschakeld via consumentengroepen. Een consumergroep is een weergave (status, positie of offset) van een volledige Event Hub. Consumergroepen maken het mogelijk dat meerdere consumerende toepassingen beschikken over een afzonderlijke weergave van de gebeurtenisstroom. De toepassingen kunnen de stroom onafhankelijk, in hun eigen tempo en met hun eigen offsets lezen.

In een architectuur waarin de stroom wordt verwerkt, is elke downstream-toepassing gelijk aan een consumergroep. Als u gebeurtenisgegevens naar de langetermijnopslag wilt schrijven, is de schrijftoepassing die hiervoor wordt gebruikt, een consumergroep. De complexe verwerking van gebeurtenissen kan vervolgens worden uitgevoerd door een andere, afzonderlijke consumergroep. U hebt alleen toegang tot partities via een consumergroep. Er is altijd een standaard consumentengroep in een Event Hub en u kunt maximaal het maximum aantal consumentengroepen maken voor de bijbehorende prijscategorie.

Een partitie per consumentengroep kan uit niet meer dan vijf gelijktijdige lezers bestaat; het wordt echter aanbevolen dat er slechts één actieve ontvanger op een partitie per consumentengroep is. Binnen één partitie ontvangt elke lezer alle berichten. Als u meerdere lezers op dezelfde partitie hebt, verwerkt u dubbele berichten. U moet dit in uw code afhandelen, wat mogelijk niet eenvoudig is. In sommige scenario's is het echter een geldige benadering.

Sommige clients die door de Azure-SDK's worden aangeboden, zijn intelligente consumentenagents die automatisch de details beheren om ervoor te zorgen dat elke partitie één lezer heeft en dat alle partities voor een Event Hub worden gelezen. Hierdoor kan uw code zich richten op het verwerken van de gebeurtenissen die worden gelezen uit de Event Hub, zodat veel van de details van de partities kunnen worden genegeerd. Zie een Verbinding maken partitie voor meer informatie.

In de volgende voorbeelden wordt de URI-conventie voor consumentengroep weer gegeven:

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

In de volgende afbeelding ziet u de architectuur voor de verwerking van stromen van Event Hubs:

Stroom-offsets

Een offset is de positie van een gebeurtenis binnen een partitie. U kunt een offset beschouwen als een clientcursor. De offset is een bytenummering van de gebeurtenis. Met deze offset kan een gebeurtenisconsumer (lezer) een punt in de gebeurtenisstroom opgeven vanwaaruit begonnen moet worden met het lezen van gebeurtenissen. U kunt de offset opgeven als een tijdstempel of als een offsetwaarde. Consumers zijn zelf verantwoordelijk voor het opslaan van hun eigen offsetwaarden buiten de Event Hubs-service. Binnen een partitie bevat elke gebeurtenis een offset.

Controlepunten maken

Het plaatsen van controlepunten is een proces waarbij lezers hun positie binnen de gebeurtenisvolgorde van een partitie markeren of vastleggen. Het plaatsen van controlepunten is de verantwoordelijkheid van de consumer en vindt plaats per partitie binnen een consumergroep. Deze verantwoordelijkheid houdt in dat elke partitielezer voor elke consumergroep de huidige positie in de gebeurtenisstroom moet bijhouden en de service kan informeren wanneer de gegevensstroom is voltooid.

Als een lezer van een partitie is losgekoppeld en er vervolgens weer verbinding wordt gemaakt, begint het lezen bij het controlepunt dat eerder is verzonden door de laatste lezer van de betreffende partitie in de consumergroep. Wanneer de lezer verbinding maakt, geeft deze de offset door aan de Event Hub om de locatie op te geven waarop moet worden gelezen. Op deze manier kunt u het plaatsen van controlepunten gebruiken om gebeurtenissen te markeren als 'voltooid' door downstream-toepassingen. Bovendien beschikt u met controlepunten over tolerantie bij een failover tussen lezers die op verschillende apparaten worden uitgevoerd. Het is mogelijk om terug te keren naar oudere gegevens door een lagere offset van dit controlepuntproces op te geven. Via dit mechanisme zorgt het plaatsen van controlepunten voor failover-tolerantie en voor herhaling van gebeurtenisstromen.

Algemene taken voor consumers

Alle Event Hubs maken verbinding via een AMQP 1.0-sessie, een statusbewust bidirectioneel communicatiekanaal. Elke partitie heeft een AMQP 1.0-sessie die het mogelijk maakt partitiespecifieke gebeurtenissen te transporteren.

Verbinding maken met een partitie

Wanneer u verbinding maakt met partities, is het gebruikelijk om een leasemechanisme te gebruiken om lezerverbindingen met specifieke partities te coördineren. Op deze manier is het mogelijk dat elke partitie in een consumentengroep slechts één actieve lezer heeft. Het maken van controlepunten, leasen en beheren van lezers wordt vereenvoudigd door gebruik te maken van de clients in de Event Hubs SDK's, die als intelligente consumentenagents fungeren. Deze zijn:

• De EventProcessorClient voor .NET
• De EventProcessorClient voor Java
• De EventHubConsumerClient voor Python
• De EventHubConsumerClient voor JavaScript/TypeScript

Gebeurtenissen lezen

Nadat er voor een specifieke partitie een AMQP 1.0-sessie en -koppeling zijn geopend, worden de gebeurtenissen door de Event Hubs-service aan de AMQP 1.0-client geleverd. Dit leveringsmechanisme maakt hogere doorvoer en lagere latentie mogelijk dan pull-mechanismen zoals HTTP GET. Tijdens het verzenden van gebeurtenissen naar de client wordt elk gebeurtenisgegeven voorzien van belangrijke metagegevens, zoals de offset en het volgnummer. Deze worden gebruikt om het plaatsen van controlepunten in de gebeurtenisvolgorde mogelijk te maken.

Gebeurtenisgegevens:

• Offset
• Volgnummer
• Hoofdtekst
• Gebruikerseigenschappen
• Systeemeigenschappen

Het is uw verantwoordelijkheid om de offset te beheren.

Volgende stappen

Voor meer informatie over Event Hubs gaat u naar de volgende koppelingen:

• Aan de slag met Event Hubs
  • .NET
  • Java
  • Python
  • JavaScript

• Event Hubs programmeerhandleiding
• Beschikbaarheid en consistentie in Event Hubs
• Veelgestelde vragen over Event Hubs
• Event Hubs voorbeelden