Funktioner och terminologi i Azure Event Hubs

Azure Event Hubs är en skalbar tjänst för händelsebearbetning som matar in och bearbetar stora mängder händelser och data, med kort svarstid och hög tillförlitlighet. Se Vad Event Hubs? för en översikt på hög nivå.

Den här artikeln bygger på informationen i översiktsartikelnoch innehåller teknisk information och implementeringsinformation om Event Hubs komponenter och funktioner.

Namnområde

Ett Event Hubs-namnområde är en hanteringscontainer för händelsehubbar (eller ämnen på Kafka-parlance). Den tillhandahåller DNS-integrerade nätverksslutpunkter och en mängd funktioner för åtkomstkontroll och hantering av nätverksintegrering, till exempel IP-filtrering,tjänstslutpunkt för virtuelltnätverk och Private Link .

Händelseutfärdare

En entitet som skickar data till en händelsehubb är en händelseutgivare (används synonymt med händelseproducenten). Händelseutgivare kan publicera händelser med HTTPS, AMQP 1.0 eller Kafka-protokollet. Händelseutgivare använder Azure Active Directory-baserad auktorisering med OAuth2-utfärdade JWT-token eller en Event Hub-specifik SAS-token (signatur för delad åtkomst) som får publiceringsåtkomst.

Publicera en händelse

Du kan publicera en händelse via AMQP 1.0, Kafka-protokollet eller HTTPS. Tjänsten Event Hubs tillhandahåller klientbibliotek REST API .NET, Java, Python, JavaScriptoch Go för publicering av händelser till en händelsehubb. För andra körningar och plattformar kan du använda alla AMQP 1.0-klienter, t.ex. Apache Qpid.

Valet att använda AMQP eller HTTPS är specifikt för användningsscenariot. AMQP kräver en beständig dubbelriktad socket och dessutom säkerhet på transportnivå (TLS) eller SSL/TLS. AMQP har högre nätverkskostnader vid initiering av sessionen, men HTTPS kräver ytterligare TLS-omkostnader för varje begäran. AMQP har betydligt högre prestanda för frekventa utgivare och kan uppnå mycket kortare svarstider när den används med asynkron publiceringskod.

Du kan publicera händelser individuellt eller i batchar. En enskild publikation har en gräns på 1 MB, oavsett om det är en enskild händelse eller en batch. Publicering av händelser som är större än det här tröskelvärdet avvisas.

Event Hubs dataflöde skalas med hjälp av partitioner och genomflödesenhetsallokeringar (se nedan). Det är bästa praxis att utgivare inte känner till den specifika partitioneringsmodell som valts för en händelsehubb och att bara ange en partitionsnyckel som används för att konsekvent tilldela relaterade händelser till samma partition.

Event Hubs ser till att alla händelser som delar ett partitionsnyckelvärde lagras tillsammans och levereras i ankomstordning. Om partitionsnycklar används med utfärdarprinciper måste utfärdarens identitet och partitionsnyckelns värde matcha varandra. Annars uppstår ett fel.

Kvarhållning av händelser

Publicerade händelser tas bort från en händelsehubb baserat på en konfigurerbar, tidsbaserad bevarandeprincip. Här är några viktiga punkter:

• Standardvärdet och den kortaste möjliga kvarhållningsperioden är 1 dag (24 timmar).
• För Event Hubs Standard är den maximala kvarhållningsperioden 7 dagar.
• För Event Hubs Premium och Dedikerad är den maximala kvarhållningsperioden 90 dagar.
• Om du ändrar kvarhållningsperioden gäller den för alla meddelanden, inklusive meddelanden som redan finns i händelsehubben.

Event Hubs behåller händelser under en konfigurerad kvarhållningstid som gäller för alla partitioner. Händelser tas bort automatiskt när kvarhållningsperioden har uppnåtts. Om du anger en kvarhållningsperiod på en dag blir händelsen otillgänglig exakt 24 timmar efter att den har godkänts. Du kan inte uttryckligen ta bort händelser.

Om du behöver arkivera händelser utöver den tillåtna kvarhållningsperioden kan du lagra dem automatiskt i Azure Storage eller Azure Data Lake genom att aktivera Event Hubs Capture-funktionen. Om du behöver söka efter eller analysera sådana djupa arkiv kan du enkelt importera dem till Azure Synapse eller andra liknande butiker och analysplattformar.

Anledningen till Event Hubs begränsningen av databevarande baserat på tid är att förhindra att stora volymer historiska kunddata fångas in i ett djupt lager som endast indexeras av en tidsstämpel och endast tillåter sekventiell åtkomst. Arkitekturfilosofi här är att historiska data behöver mer indexering och mer direkt åtkomst än det realtidsgränssnitt för händelse som Event Hubs eller Kafka tillhandahåller. Händelseströmmotorer är inte särskilt väl lämpade för att spela rollen som datasjöar eller långsiktiga arkiv för händelsekällor.

Utgivarprincip

Med händelsehubbar får du granulär kontroll över utgivare via utgivarprinciper. Utfärdarprinciper är körningsfunktioner som utformats för att ge stöd för ett stort antal oberoende utfärdare. Med utgivarprinciper använder varje utgivare sin egen unika identifierare vid publicering av händelser på en händelsehubb med hjälp av följande mekanism:

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

Du behöver inte skapa utgivarnamnen i förväg, men de måste matcha SAS-token som används när du publicerar en händelse för att garantera oberoende utgivaridentiteter. När du använder utgivarprinciper ställs PartitionKey-värdet in på utgivarens namn. Dessa värden måste matcha för att fungera korrekt.

Capture

Event Hubs Capture gör att du automatiskt kan samla in strömmande data i Event Hubs och spara dem till ditt val av antingen ett Blob Storage-konto eller ett Azure Data Lake Storage-konto. Du kan aktivera avskiljning från Azure Portal och ange en minsta storlek och tidsfönster för att utföra avskiljning. Med Event Hubs Capture anger du ditt eget Azure Blob Storage-konto och azure-container eller Azure Data Lake Storage-konto, där ett av dessa används för att lagra infångade data. Infångade data skrivs i Apache Avro-format.

Filerna som skapas av Event Hubs Capture har följande Avro-schema:

Partitioner

Event Hubs ordnar sekvenser av händelser som skickas till en händelsehubb i en eller flera partitioner. När nyare händelser anländer läggs de till i slutet av den här sekvensen.

En partition kan ses som en "commit log" (genomförandelogg). Partitioner innehåller händelsedata som innehåller händelsens brödtext, en användardefinierad egenskapsdesk som beskriver händelsen, metadata som dess offset i partitionen, dess nummer i strömsekvensen och tidsstämpeln på tjänstsidan där den accepterades.

Fördelar med att använda partitioner

Event Hubs är utformat för att hjälpa till med bearbetning av stora mängder händelser, och partitionering hjälper till med detta på två sätt:

• Även om Event Hubs är en PaaS-tjänst finns det en fysisk verklighet under, och att upprätthålla en logg som bevarar ordningen på händelserna kräver att dessa händelser hålls tillsammans i den underliggande lagringen och dess repliker och att resulterar i ett dataflödestak för en sådan logg. Partitionering gör att flera parallella loggar kan användas för samma händelsehubb och därför multipliceras den tillgängliga råa I/O-dataflödeskapaciteten.
• Dina egna program måste kunna hålla koll på bearbetningen av mängden händelser som skickas till en händelsehubb. Det kan vara komplext och kräver betydande, utskalat, parallell bearbetningskapacitet. Kapaciteten för en enda process för att hantera händelser är begränsad, så du behöver flera processer. Partitioner är hur din lösning matar dessa processer och säkerställer ändå att varje händelse har en tydlig bearbetningsägare.

Antal partitioner

Antalet partitioner anges när du skapar en händelsehubb. Det måste vara mellan 1 och det maximala antalet partitioner som tillåts för varje prisnivå. Information om gränsen för antal partitioner för varje nivå finns i den här artikeln.

Vi rekommenderar att du väljer minst så många partitioner som du förväntar dig att krävs under programmets belastningstopp för just den händelsehubben. Du kan inte ändra antalet partitioner för en händelsehubb när den har skapats, förutom händelsehubben i ett dedikerat kluster och på premiumnivån. Antalet partitioner för en händelsehubb i ett dedikerat Event Hubs-kluster kan ökas när händelsehubben har skapats, men distributionen av strömmar mellan partitioner ändras när den är klar när mappningen av partitionsnycklar till partitioner ändras, så du bör försöka undvika sådana ändringar om den relativa ordningen på händelser är viktig i ditt program.

Det är lockande att ange antalet partitioner till det högsta tillåtna värdet, men tänk alltid på att dina händelseströmmar måste struktureras så att du verkligen kan dra nytta av flera partitioner. Om du behöver absolut ordningsföljd för alla händelser eller bara ett fåtal delströmmar kanske du inte kan dra nytta av många partitioner. Dessutom gör många partitioner bearbetningssidan mer komplex.

Det spelar ingen roll hur många partitioner som finns i en händelsehubb när det gäller priser. Det beror på antalet prisnivåer(dataflödesenheter (TUs) för standardnivån, bearbetningsenheter (PUS) för Premium-nivån och kapacitetsenheter (CUs) för den dedikerade nivån) för namnområdet eller det dedikerade klustret. Till exempel medför en händelsehubb på standardnivån med 32 partitioner eller med 1 partition exakt samma kostnad när namnområdet är inställt på 1 TU-kapacitet. Du kan också skala TUs eller PUs på namnområdet eller CUs för ditt dedikerade kluster oberoende av antalet partitioner.

Mappning av händelser till partitioner

Du kan använda en partitionsnyckel för att mappa inkommande händelsedata till specifika partitioner för att ordna data. Partitionsnyckeln är ett värde som avsändaren anger och som skickas till en händelsehubb. Den bearbetas via en statisk hash-funktion som skapar partitionstilldelningen. Om du inte anger en partitionsnyckel när du publicerar en händelse, används en tilldelning enligt resursallokeringsmodellen.

Händelseutfärdaren känner bara till sin partitionsnyckel, inte den partition som händelserna publiceras till. Frikopplingen av nyckeln och partitionen gör att avsändaren inte behöver känna till så mycket om bearbetningen nedströms. En identitet per enhet eller en användarunik identitet utgör en bra partitionsnyckel, men andra attribut, till exempel geografi, kan också användas för att gruppera relaterade händelser i en enda partition.

Om du anger en partitionsnyckel kan relaterade händelser förvaras tillsammans i samma partition och i exakt den ordning som de ankom. Partitionsnyckeln är en sträng som härleds från programkontexten och identifierar relationen mellan händelserna. En händelsesekvens som identifieras av en partitionsnyckel är en dataström. En partition är ett multiplexerat logglager för många sådana strömmar.

SAS-token

Event Hubs använder signaturer för delad åtkomst , som är tillgängliga på namnområdes- och händelsehubbnivå. En SAS-token genereras från en SAS-nyckel och är en SHA-hash för en URL som kodats i ett specifikt format. Med hjälp av namnet på nyckeln (principen) och token kan Event Hubs återgenerera hash-värdet och därmed autentisera avsändaren. Sas-token för händelseutgivare skapas vanligtvis med endast behörighet att skicka på en specifik händelsehubb. Den här URL-mekanismen med SAS-token är den grund för utfärdaridentifiering som presenterades i principen för utfärdare. Mer information om hur du arbetar med SAS finns i autentisering med signatur för delad åtkomst med Service Bus.

Händelsekonsumenter

En entitet som läser händelsedata från en händelsehubb är en händelsekonsument. Alla Event Hubs-konsumenter ansluter via AMQP 1.0-sessionen och händelser levereras via sessionen när de blir tillgängliga. Klienten behöver inte söka efter datatillgänglighet.

Konsumentgrupper

Publicerings-/prenumerationsmekanismen för Event Hubs aktiveras via konsumentgrupper. En konsumentgrupp är en vy (tillstånd, position eller offset) av en hel händelsehubb. Konsumentgrupper gör det möjligt för flera användningsprogram att vart och ett ha en separat vy över händelseströmmen och att oberoende läsa strömmen i egen takt och med sina egna offset.

Inom en arkitektur för strömbearbetning utgör varje nedströms program en konsumentgrupp. Om du vill skriva händelsedata till långsiktig lagring utgör programmet för att skriva data till lagring en konsumentgrupp. Komplex händelsebearbetning kan sedan utföras av en annan, separat konsumentgrupp. Du får bara åtkomst till en partition via en konsumentgrupp. Det finns alltid en standardkonsumentgrupp i en händelsehubb och du kan skapa upp till det maximala antalet konsumentgrupper för motsvarande prisnivå.

Det kan finnas högst 5 samtidiga läsare på en partition per konsumentgrupp. Vi rekommenderar dock att det bara finns en aktiv mottagare på en partition per konsumentgrupp. Inom en enda partition tar varje läsare emot alla meddelanden. Om du har flera läsare på samma partition bearbetar du dubblettmeddelanden. Du måste hantera detta i koden, vilket kanske inte är trivialt. Det är dock en giltig metod i vissa scenarier.

Vissa klienter som erbjuds av Azure-SDK:erna är intelligenta konsumentagenter som automatiskt hanterar information om att säkerställa att varje partition har en enda läsare och att alla partitioner för en händelsehubb läses från. På så sätt kan din kod fokusera på att bearbeta de händelser som läses från händelsehubben så att den kan ignorera mycket information om partitionerna. Mer information finns i Anslut till en partition.

I följande exempel visas URI-konventionen för konsumentgrupper:

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

Följande bild visar strömhanteringsarkitekturen i Event Hubs:

Offsets för strömmar

En offset är positionen för en händelse i en partition. Föreställ dig en offset som en markör på klientsidan. Denna offset är en byte-numrering av händelsen. Med den så kan en händelsekonsument (läsare) ange vid vilken punkt i händelseströmmen som läsningen ska starta. Du kan ange offseten som en tidsstämpel eller ett offset-värde. Konsumenterna ansvarar för att lagra sina egna offset-värden utanför händelsehubbtjänsten. Inom en partition innehåller varje händelse en offset.

Kontrollpunkter

Att skapa kontrollpunkter är en process genom vilken läsare markerar eller sparar sin position inom en händelsesekvens i en partition. Att skapa kontrollpunkter är konsumentens ansvar och görs för varje partition i en konsumentgrupp. Det här ansvaret innebär att varje läsare i partitionen måste hålla reda på sin nuvarande position i händelseströmmen för varje konsumentgrupp. Läsaren kan sedan informera tjänsten när de anser att dataströmmen är klar.

Om en läsare kopplar från en partition och den sedan återansluts kan han börja läsa vid den kontrollpunkt som tidigare skickades in av den senaste läsaren i den aktuella partitionen inom just den konsumentgruppen. När läsaren ansluter skickar den förskjutningen till händelsehubben för att ange den plats där läsningen ska börja. På så sätt kan du använda kontrollpunkter både till att markera händelser som ”klara” i underordnade program och som skydd i händelse av en redundansväxling mellan läsare som körs på olika datorer. Du kan återgå till äldre data genom att ange en lägre förskjutning från den här kontrollpunktsprocessen. Den här mekanismen möjliggör både återhämtning vid redundansväxlingar och återuppspelning av händelseströmmar.

Vanliga konsumentuppgifter

Alla Event Hubs ansluter via en AMQP 1.0-session, en tillståndsmedveten dubbelriktad kommunikationskanal. Varje partition har en AMQP 1.0-session som gör det lättare att flytta händelser som åtskiljs av partitioner.

Ansluta till en partition

När du ansluter till partitioner är det vanligt att använda en leasingmekanism för att samordna läsaranslutningar till specifika partitioner. På så sätt är det möjligt för varje partition i en konsumentgrupp att bara ha en aktiv läsare. Kontrollpunkter, leasing och hantering av läsare förenklas med hjälp av klienterna i Event Hubs-SDK:er, som fungerar som intelligenta konsumentagenter. Dessa är:

• EventProcessorClient för .NET
• EventProcessorClient för Java
• EventHubConsumerClient för Python
• EventHubConsumerClient för JavaScript/TypeScript

Läsa händelser

När en AMQP 1.0-session och -länk har öppnats för en specifik partition, levereras händelser till AMQP 1.0-klienten av händelsehubbtjänsten. Den här leveransmekanismen gör det möjligt med ett högre genomflöde och kortare svarstid än i pull-baserade mekanismer som t.ex. HTTP GET. När händelser skickas till klienten innehåller varje instans av händelsedata viktiga metadata, till exempel offset- och sekvensnumret som används för att göra det lättare att skapa kontrollpunkter i händelsesekvensen.

Händelsedata:

• Offset
• Sekvensnummer
• Brödtext
• Användaregenskaper
• Systemegenskaper

Det är ditt ansvar att hantera förskjutningen.

Nästa steg

Besök följande länkar för mer utförlig information om Event Hubs:

• Kom igång med händelsehubbar
  • .NET
  • Java
  • Python
  • JavaScript

• Event Hubs programmeringsguide
• Tillgänglighet och konsekvens i Event Hubs
• Vanliga frågor och svar om Event Hubs
• Event Hubs exempel