Dela via

Kafka Streams för Azure Event Hubs

  • Artikel

Den här artikeln innehåller information om hur du använder Kafka Streams-klientbiblioteket med Azure Event Hubs.

Kommentar

Kafka Streams-funktioner är endast tillgängliga i offentlig förhandsversion för Event Hubs Premium- och Dedikerade nivåer.

Översikt

Apache Kafka Streams är ett java-klientbibliotek som tillhandahåller ett ramverk för bearbetning av strömmande data och skapa realtidsprogram mot data som lagras i Kafka-ämnen. All bearbetning är begränsad till klienten, medan Kafka-ämnen fungerar som datalager för mellanliggande data innan utdata skrivs till målavsnittet.

Event Hubs tillhandahåller en Kafka-slutpunkt som ska användas med dina befintliga Kafka-klientprogram som ett alternativ till att köra ditt eget Kafka-kluster. Event Hubs fungerar med många av dina befintliga Kafka-program. Mer information finns i Event Hubs för Apache Kafka.

Använda Kafka Streams med Azure Event Hubs

Azure Event Hubs har inbyggt stöd för både AMQP- och Kafka-protokollet. Men för att säkerställa kompatibelt Kafka Streams-beteende måste vissa av standardkonfigurationsparametrarna uppdateras för Kafka-klienter.

Property Standardbeteende för Event Hubs Ändrat beteende för Kafka-strömmar Förklaring
messageTimestampType inställd på AppendTime ska ställas in på CreateTime Kafka Streams förlitar sig på tidsstämpel för skapande i stället för att lägga till tidsstämpel
message.timestamp.difference.max.ms högsta tillåtna värde är 90 dagar Egenskapen används endast för att styra tidigare tidsstämplar. Framtida tid är inställd på 1 timme och kan inte ändras. Detta är i linje med Kafka-protokollspecifikationen
min.compaction.lag.ms högsta tillåtna värde är två dagar
Avsnitt om oändlig kvarhållning storleksbaserad trunkering på 250 GB för varje ämnespartition
Ta bort post-API för oändliga kvarhållningsämnen Inte implementerad. Som en lösning kan ämnet uppdateras och en begränsad kvarhållningstid kan anges. Detta kommer att göras i GA

Övriga beaktanden

Här följer några av de andra övervägandena att tänka på.

  • Kafka streams-klientprogram måste beviljas hanterings-, läs- och skrivbehörigheter för hela namnrymderna för att kunna skapa tillfälliga ämnen för dataströmbearbetning.
  • Tillfälliga ämnen och partitioner räknas mot kvoten för det angivna namnområdet. Dessa bör beaktas vid etablering av namnområdet eller klustret.
  • Oändlig kvarhållningstid för "Offset"Store begränsas av maximal kvarhållningstid för meddelanden för SKU:n. Kontrollera Event Hubs-kvoter för dessa nivåspecifika värden.

Dessa inkluderar uppdatering av ämneskonfigurationen messageTimestampType i för att använda CreateTime (det vill: Skapandetid för händelse) i stället för (det vill: loggens tilläggstid).AppendTime

Om du vill åsidosätta standardbeteendet (krävs) måste nedanstående inställning anges i Azure Resource Manager (ARM).

Kommentar

Endast de specifika delarna i ARM-mallen visas för att markera konfigurationen som behöver uppdateras.

{
  "parameters": {
    "namespaceName": "contoso-test-namespace",
    "resourceGroupName": "contoso-resource-group",
    "eventHubName": "contoso-event-hub-kafka-streams-test",
    ...
    "parameters": {
      "properties": {
        ...
        "messageTimestampType": "CreateTime",
        "retentionDescription": {
          "cleanupPolicy": "Delete",
          "retentionTimeInHours": -1,
          "tombstoneRetentionTimeInHours": 1
        }
      }
    }
  }
}

Kafka Streams-begrepp

Kafka-strömmar ger ett enkelt abstraktionslager över Kafka-producent- och konsument-API:er för att hjälpa utvecklare att komma igång med scenarier för realtidsströmning snabbare. Biblioteket för låg vikt beror på en Apache Kafka-kompatibel asynkron meddelandekö (till exempel Azure Event Hubs) för det interna meddelandelagret och hanterar ett feltolerant lokalt tillståndsarkiv. Med transaktions-API:et stöder Kafka Streams-biblioteket omfattande bearbetningsfunktioner, till exempel exakt en gång bearbetning och en post i taget.

Poster som kommer i fel ordning drar nytta av händelsebaserade fönsteråtgärder.

Kommentar

Vi rekommenderar att du bekantar dig med Kafka Streams-dokumentationen och Kafka Streams kärnbegrepp.

Strömmar

En ström är en abstrakt representation av ett Kafka-ämne. Den består av en obundet, kontinuerligt uppdaterad datauppsättning med oföränderliga dataposter, där varje datapost är ett nyckel/värde-par.

Topologi för dataströmbearbetning

Ett Kafka-streams-program definierar beräkningslogik via en DAG (riktad acyklisk graf) som representeras av en processortopologi. Processortopologin består av dataströmprocessorer (noder i topologin) som representerar ett bearbetningssteg som är anslutet med strömmar (kanter i topologin).

Stream-processorer kan länkas till överordnade processorer eller underordnade processorer, förutom för vissa särskilda fall:

  • Källprocessorer – Dessa processorer har inga överordnade processorer och läser direkt från en eller flera strömmar. De kan sedan kopplas till underordnade processorer.
  • Mottagarprocessorer – Dessa processorer har inga underordnade processorer och måste skriva direkt till en dataström.

Topologi för dataströmbearbetning kan definieras antingen med Kafka Streams DSL eller med processor-API:et på lägre nivå.

Dataström och tabelldubbning

Strömmar och tabeller är två olika men användbara abstraktioner som tillhandahålls av Kafka Streams DSL, som modellerar både tidsserie- och relationsdataformat som måste samexistera för användningsfall för dataströmbearbetning.

Kafka utökar detta ytterligare och introducerar en dubbelhet mellan strömmar och tabeller, där en

  • En dataström kan betraktas som en ändringslogg för en tabell och
  • En tabell kan betraktas som en ögonblicksbild av det senaste värdet för varje nyckel i en dataström.

Med den här dualiteten kan tabeller och strömmar användas omväxlande enligt användningsfallet.

Till exempel

  • Koppla statiska kunddata (modellerade som en tabell) med dynamiska transaktioner (modellerade som en dataström) och
  • Gå med i föränderliga portföljpositioner i en day traders-portfölj (modellerad som en ström) med det senaste marknadsdataflödet (modellerat som en ström).

Tid

Kafka Streams tillåter att fönster- och respitfunktioner gör att dataposter i oordning kan matas in och fortfarande inkluderas i bearbetningen. För att säkerställa att det här beteendet är deterministiskt finns det ytterligare tidsbegrepp i Kafka-strömmar. Dessa kan vara:

  • Skapandetid (kallas även "Händelsetid") – Det här är den tid då händelsen inträffade och dataposten skapades.
  • Bearbetningstid – det här är den tid då dataposten bearbetas av dataströmbearbetningsprogrammet (eller när den förbrukas).
  • Tilläggstid (kallas även "Skapandetid") – Det här är den tid då data lagras och checkas in på lagringen av Kafka-koordinatorn. Detta skiljer sig från skapandetiden på grund av tidsskillnaden mellan skapandet av händelsen och den faktiska inmatningen av asynkron meddelandekö.

Tillståndskänsliga åtgärder

Tillståndshantering möjliggör avancerad dataströmbearbetning som att ansluta och aggregera data från olika strömmar. Detta uppnås med tillståndslager som tillhandahålls av Kafka Streams och används med tillståndskänsliga operatorer i Kafka Streams DSL.

Tillståndskänsliga transformeringar i DSL:

Fönster och respit

Fönsteråtgärder i Kafka Streams DSL gör det möjligt för utvecklare att styra hur poster grupperas för en viss nyckel för tillståndskänsliga åtgärder som sammansättningar och kopplingar.

Fönsteråtgärder tillåter också specifikationen av en respitperiod för att ge viss flexibilitet för out-of-order-poster för ett visst fönster. En post som är avsedd för ett visst fönster och som tas emot efter det angivna fönstret men inom respitperioden accepteras. Poster som anländer efter att respitperioden är över ignoreras.

Program måste använda kontrollerna för fönster och respitperiod för att förbättra feltoleransen för poster som inte är i ordning. Lämpliga värden varierar beroende på arbetsbelastningen och måste identifieras empiriskt.

Bearbetningsgarantier

Affärsanvändare och tekniska användare försöker extrahera viktiga affärsinsikter från utdata från dataströmbearbetningsarbetsbelastningar, vilket innebär höga krav på transaktionsgarantier. Kafka-strömmar fungerar tillsammans med Kafka-transaktioner för att säkerställa transaktionsbearbetningsgarantier genom att integrera med kafka-kompatibla koordinatorer (till exempel Azure Event Hubs) underliggande lagringssystem för att säkerställa att offset-incheckningar och uppdateringar av tillståndslager skrivs atomiskt.

För att säkerställa garantier processing.guarantee för transaktionsbearbetning måste inställningen i Kafka Streams-konfigurationerna uppdateras från standardvärdet at_least_once för till exactly_once_v2 (för klientversioner på eller efter Apache Kafka 2.5) eller exactly_once (för klientversioner före Apache Kafka 2.5.x).

Nästa steg

Den här artikeln gav en introduktion till Event Hubs för Kafka. Mer information finns i Apache Kafka-utvecklarguiden för Azure Event Hubs.

En självstudiekurs med stegvisa instruktioner för att skapa en händelsehubb och komma åt den med hjälp av SAS eller OAuth finns i Snabbstart: Dataströmning med Event Hubs med hjälp av Kafka-protokollet.

Se även OAuth-exemplen på GitHub.