Funkce a terminologie ve službě Azure Event Hubs

Azure Event Hubs je škálovatelná služba pro zpracování událostí, která ingestuje a zpracovává velké objemy událostí a dat s nízkou latencí a vysokou spolehlivostí. Podrobný přehled najdete v tématu co je Event Hubs? .

Tento článek sestaví informace v článku Přehleda poskytuje podrobnosti o technické a implementaci Event Hubs komponentách a funkcích.

Obor názvů

Event Hubs obor názvů je kontejner správy pro centra událostí (nebo témata v Kafka agilním). Poskytuje koncové body sítě integrované DNS a řadu funkcí řízení přístupu a správy integrace sítě, jako je filtrování IP adres, koncový bod služby virtuální sítěa privátní odkaz.

Zdroje událostí

Každá entita, která odesílá data do centra událostí, je vydavatelem událostí (jako synonyma se používá u výrobce událostí). Vydavatelé událostí můžou publikovat události pomocí protokolu HTTPS nebo AMQP 1,0 nebo protokolu Kafka. vydavatelé událostí používají ověřování založené na Azure Active Directory s tokeny JWT vydanými OAuth2 nebo tokenem sdíleného přístupového podpisu specifického pro centrum událostí, který získá přístup pro publikování.

Publikování události

Událost můžete publikovat prostřednictvím AMQP 1,0, protokolu Kafka nebo protokolu HTTPS. Služba Event Hubs poskytuje klientské knihovny pro REST API a .NET, Java, Python, JavaScripta na cestách pro publikování událostí do centra událostí. Pro jiné moduly runtime a platformy můžete použít libovolného klienta protokolu AMQP 1.0, například Apache Qpid.

Volba, jestli se použije protokol AMQP nebo HTTPS, závisí na konkrétním scénáři použití. Protokol AMQP vyžaduje nejen protokol TLS (Transport Level Security) nebo SSL/TLS, ale i vytvoření trvalého obousměrného soketu. AMQP má při inicializaci relace vyšší náklady na síť, ale protokol HTTPS vyžaduje pro každý požadavek další režii TLS. AMQP má významně vyšší výkon pro časté vydavatele a při použití s asynchronním kódem publikování může dosáhnout mnohem nižších latencí.

Události můžete publikovat jednotlivě nebo v dávce. Jedna publikace má omezení 1 MB, bez ohledu na to, zda se jedná o jednu událost nebo dávku. Události, které jsou větší než tato prahová hodnota, budou odmítnuty.

Event Hubs propustnost se škáluje pomocí oddílů a přidělení jednotek propustnosti (viz níže). Doporučuje se, aby vydavatelé zůstali bez ohledu na konkrétní model dělení, který je vybraný pro centrum událostí, a jenom zadat klíč oddílu , který se používá k konzistentnímu přiřazování souvisejících událostí ke stejnému oddílu.

Event Hubs zajišťuje, aby všechny události sdílející hodnotu klíče oddílu byly uloženy společně a doručeny v pořadí doručení. Pokud se klíče oddílů používají společně se zásadami zdroje, musí si identita zdroje a hodnota klíče oddílu odpovídat. V opačném případě dojde k chybě.

Uchovávání událostí

Publikované události se odeberou z centra událostí na základě konfigurovatelné zásady uchovávání na základě časových limitů. Tady je několik důležitých bodů:

• Výchozí hodnota a nejkratší možné období uchování je 1 den (24 hodin).
• Pro Event Hubs Standard je maximální doba uchovávání 7 dní.
• u Event Hubs Premium a vyhrazená je maximální doba uchování 90 dní.
• Pokud změníte dobu uchování, bude platit pro všechny zprávy, včetně zpráv, které jsou již v centru událostí.

Event Hubs zachovává události pro nakonfigurovanou dobu uchování, která se vztahuje na všechny oddíly. Události jsou automaticky odebrány po dosažení doby uchování. Pokud zadáte dobu uchování jednoho dne, událost nebude k dispozici přesně 24 hodin poté, co byla přijata. Události nemůžete explicitně odstranit.

pokud potřebujete archivovat události nad povolenou dobu uchovávání, můžete je automaticky ukládat do Azure Storage nebo Azure Data Lake zapnutím funkce Event Hubs Capture. Pokud potřebujete tyto podrobné archivy prohledávat nebo analyzovat, můžete je snadno importovat do Azure synapse nebo jiných podobných úložišť a analytických platforem.

Důvodem Event Hubs "omezení uchovávání dat na základě času je zabránit velkým objemům historických zákaznických dat v hlubokém úložišti, které je indexováno pouze pomocí časového razítka, a umožňuje pouze sekvenční přístup. Architektura architektury filozofie tady je, že historické údaje potřebují mnohem lepší indexování a větší přímý přístup než rozhraní pro zpracování událostí v reálném čase, které Event Hubs nebo Kafka poskytují. Moduly streamování událostí nejsou vhodné pro hraní role datových laků nebo dlouhodobých archivů pro účely plnění událostí.

Zásady zdroje

Služba Event Hubs umožňuje podrobnou kontrolu nad zdroji událostí prostřednictvím zásad zdroje. Zásady zdroje jsou běhové funkce, které byly navržené pro usnadnění kontroly nad velkým množstvím nezávislých zdrojů událostí. Zásady zdroje poskytují s použitím následujícího mechanismu každému zdroji vlastní identifikátor, který se používá při publikování událostí do centra událostí:

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

Názvy zdrojů není potřeba vytvářet dopředu, při publikování události ale musí odpovídat tokenu SAS, aby se zajistilo, že každý zdroj bude mít nezávislou identitu. Při použití zásad zdroje se každému názvu zdroje nastaví hodnota PartitionKey (Klíč oddílu). Aby vše správně fungovalo, musí tyto hodnoty odpovídat.

Zachytávání

Event Hubs Capture vám umožní automaticky zachytit streamovaná data v Event Hubs a uložit je do vašeho výběru buď účtu úložiště Blob, nebo účtu Azure Data Lake Storage. Můžete povolit zachytávání z Azure Portal a zadat minimální velikost a časový interval pro provedení zachycení. pomocí služby Event Hubs Capture zadáte vlastní účet a kontejner Azure Blob Storage a účet Azure Data Lake Storage, který se používá k uložení zachycených dat. Zachycená data se zapisují ve formátu Apache Avro.

Soubory vytvořené pomocí Event Hubs Capture mají následující schéma Avro:

Oddíly

Event Hubs uspořádá sekvence událostí odeslané do centra událostí do jednoho nebo více oddílů. Jakmile přijdete o novější události, přidají se na konec této sekvence.

Oddíl lze představit jako "potvrzovací protokol". Oddíly uchovávají data událostí, která obsahují tělo události, uživatelem definovaný kontejner vlastností popisující událost, metadata, jako je jeho posun v oddílu, jeho číslo v posloupnosti datových proudů a časové razítko na straně služby, na kterém byla přijata.

Výhody používání oddílů

Event Hubs je navržená tak, aby pomáhala při zpracování velkých objemů událostí, a pomáhá s nimi dvěma způsoby:

• I když Event Hubs je služba PaaS, existuje fyzická realita a udržuje protokol, který zachovává pořadí událostí, vyžaduje, aby se tyto události zachovaly společně v podkladovém úložišti a jeho replikách a aby výsledkem byl limit propustnosti pro takový protokol. Vytváření oddílů umožňuje používat pro stejné centrum událostí více paralelních protokolů a vynásobit dostupnou nezpracované propustnosti v/v.
• Vaše vlastní aplikace musí být schopné udržet se zpracováním objemu událostí, které se odesílají do centra událostí. Může být komplexní a vyžaduje značnou kapacitu paralelního zpracování škálované na více instancí. Kapacita jednoho procesu pro zpracování událostí je omezená, takže potřebujete několik procesů. Oddíly představují způsob, jakým vaše řešení tyto procesy doručí, a ještě zajišťuje, aby každá událost měla jasného vlastníka zpracování.

Počet oddílů

Počet oddílů se zadává v době vytváření centra událostí. Hodnota musí být mezi 1 a maximálním počtem oddílů povoleným pro jednotlivé cenové úrovně. Omezení počtu oddílů pro jednotlivé úrovně najdete v tomto článku.

Doporučujeme, abyste si zvolili aspoň tolik oddílů, kolik jich očekáváte, a to při špičkovém zatížení vaší aplikace pro konkrétní centrum událostí. Počet oddílů centra událostí po jeho vytvoření nemůžete změnit, s výjimkou centra událostí ve vyhrazeném clusteru a na úrovni Premium. Počet oddílů centra událostí ve vyhrazeném Event Hubs clusteru se dá po vytvoření centra událostí zvýšit , ale distribuce datových proudů napříč oddíly se v době, kdy se provedla, změní na změny oddílů oddílů na oddíly. proto byste se měli pokusit, abyste se těmto změnám vyhnuli, pokud se jedná o relativní pořadí událostí ve vaší aplikaci.

Nastavení počtu oddílů na maximální povolenou hodnotu se měří, ale vždy mějte na paměti, že datové proudy událostí musí být strukturované, aby bylo možné využít více oddílů. Pokud potřebujete zachování absolutního pořadí napříč všemi událostmi nebo jenom několik podproudy, možná nebudete moct využít mnoho oddílů. Mnoho oddílů navíc usnadňuje zpracování na straně sebe složitější.

Nezáleží na tom, kolik oddílů je v centru událostí, když přichází na ceny. Závisí na počtu cenových jednotek (jednotky propustnosti (počet propustnosti) pro úroveň Standard, zpracování jednotek (PUs) pro úroveň Premium a na vyhrazené úrovni (kapacitní jednotky) pro obor názvů nebo vyhrazený cluster. Například centrum událostí úrovně Standard s 32 oddíly nebo s 1 oddílem vznikne přesně stejné náklady, pokud je obor názvů nastavený na 1 část kapacity. Můžete také škálovat počet propustnosti nebo PUs na svůj obor názvů nebo kapacitní jednotky vyhrazený cluster nezávisle na počtu oddílů.

Mapování událostí na oddíly

Klíč oddílu můžete použít k mapování příchozích dat událostí do konkrétních oddílů pro účely organizace dat. Klíč oddílu je hodnota zadaná odesílatelem, která byla předaná do centra událostí. Zpracovává se pomocí statické hashovací funkce, která vytvoří přiřazení k oddílu. Pokud při publikování události nezadáte klíč oddílu, použije se přiřazení metodou kruhového dotazování.

Zdroj události zná jenom svůj klíč oddílu, a ne oddíl, do kterého se události publikují. Díky tomuto oddělení klíče a oddílu odesílatel toho nepotřebuje vědět o zpracování příjmu dat příliš mnoho. Vhodným klíčem oddílu je jedinečná identita uživatele nebo zařízení, ale k seskupení souvisejících událostí do jednoho oddílu je možné použít i další atributy, například geografickou polohu.

Zadání klíče oddílu umožňuje udržovat související události společně ve stejném oddílu a v přesném pořadí, ve kterém byly přijaty. Klíč oddílu je řetězec, který je odvozen z kontextu vaší aplikace a identifikuje vzájemné vztahy událostí. Posloupnost událostí identifikovaných klíčem oddílu je datový proud. Oddíl je multiplexované úložiště protokolu pro mnoho takových datových proudů.

Tokeny SAS

Event Hubs používá sdílené přístupové podpisy, které jsou k dispozici na úrovni oboru názvů a centra událostí. Token SAS, který se generuje z klíče SAS, je adresa URL, která je zašifrovaná pomocí hašovacího algoritmu SHA a zakódovaná ve specifickém formátu. Služba Event Hubs může znovu vygenerovat hash kód pomocí názvu klíče (zásady) a tokenu, a ověřit tak odesílatele. Za normálních okolností se tokeny SAS pro vydavatele událostí vytvářejí jenom s oprávněními pro odesílání na konkrétní centrum událostí. Tento mechanismus adresy URL a tokenu SAS slouží jako základ pro identifikaci zdroje, kterou představíme v části o zásadách zdroje. Další informace o práci s tokenem SAS naleznete v tématu o ověřování u služby Service Bus pomocí sdíleného přístupového podpisu.

Příjemci událostí

Každá entita, která čte data událostí z centra událostí, je příjemce událostí. Všichni příjemci se ve službě Event Hubs připojují pomocí relace protokolu AMQP 1.0 a události se doručují tak, jak jsou postupně dostupné. Klient se na dostupnost dat nemusí dotazovat.

Skupiny uživatelů

Mechanismus publikování/odebírání ve službě Event Hubs umožňují skupiny příjemců. Skupina příjemců je zobrazení (stavu, pozice nebo posunu) celého centra událostí. Skupiny příjemců poskytují různým přijímajícím aplikacím oddělená zobrazení datového proudu událostí a umožňují jim nezávisle číst datový proud vlastním tempem a s použitím vlastních posunů.

V architektuře zpracování datového proudu se každá aplikace pro příjem dat rovná skupině příjemců. Pokud chcete zapisovat data událostí do dlouhodobého úložiště, pak je aplikace, která do úložiště zapisuje, skupinou příjemců. Komplexní zpracování událostí zase může provádět jiná, samostatná skupina příjemců. K oddílům můžete přistupovat pouze prostřednictvím skupiny příjemců. V centru událostí je vždy výchozí skupina příjemců a můžete vytvořit maximální počet skupin uživatelů pro odpovídající cenovou úroveň.

U oddílu na skupinu příjemců může existovat maximálně 5 souběžných čtecích zařízení. doporučuje se ale , aby v oddílu na skupinu příjemců byl jenom jeden aktivní přijímač. Každý čtenář v rámci jednoho oddílu obdrží všechny zprávy. Pokud máte na stejném oddílu více čtenářů, budete zpracovávat duplicitní zprávy. To je třeba zpracovat v kódu, který nemusí být triviální. V některých scénářích se ale jedná o platný přístup.

Někteří klienti, kteří nabízejí sady Azure SDK, jsou inteligentní agenti pro zákazníky, kteří automaticky spravují podrobnosti o tom, že každý oddíl má jedno čtecí zařízení a že se z něj čtou všechny oddíly centra událostí. Díky tomu se váš kód může soustředit na zpracování událostí čtených z centra událostí, aby mohl ignorovat mnoho podrobností o těchto oddílech. další informace najdete v tématu Připojení k oddílu.

Následující příklady znázorňují konvenci identifikátoru URI pro skupinu příjemců:

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

Následující obrázek znázorňuje architekturu zpracování datového proudu Event Hubs:

Posuny datového proudu

Posun je pozice události v rámci oddílu. Posun si můžete představit jako kurzor na straně klienta. Posun je číslo bajtu události. Tento posun umožňuje příjemci události (čtenáři) určit bod v datovém proudu událostí, od kterého chce události začít číst. Posun můžete zadat v podobě časového razítka nebo hodnoty posunu. Příjemci si sami zodpovídají za uložení svých hodnot posunu mimo službu Event Hubs. Každá událost v rámci oddílu zahrnuje posun.

Vytváření kontrolních bodů

Vytváření kontrolních bodů je proces, pomocí kterého čtenáři označují nebo potvrzují svou pozici v rámci posloupnosti událostí v oddílu. Za vytváření kontrolních bodů zodpovídá příjemce. Proces probíhá na bázi oddílů ve skupinách příjemců. Taková zodpovědnost znamená, že si každý čtenář oddílu v každé skupině příjemců musí udržovat přehled o své aktuální pozici v datovém proudu událostí a může informovat službu, když bude považovat datový proud za dokončený.

Pokud se čtenář z oddílu odpojí, začne při opětovném připojení číst od kontrolního bodu, který dříve zaslal poslední čtenář daného oddílu z této skupiny příjemců. Když se čtenář připojí, předá posun do centra událostí, aby určil umístění, ve kterém se má začít číst. Takto můžete vytváření kontrolních bodů použít jak k označování událostí jako „dokončených“, tak k zajištění ochrany pro případ, že nastane selhání u čtenářů spuštěných na různých strojích. Je možné vrátit se ke starším datům zadáním nižšího posunu od tohoto procesu vytváření kontrolního bodu. Díky tomuto mechanismu umožňuje vytváření kontrolních bodů nejen obnovu při selhání, ale i opakované přehrání datového proudu.

Běžné úlohy příjemce

Všichni Event Hubs spotřebitelé se připojují prostřednictvím relace AMQP 1,0, obousměrného komunikačního kanálu s podporou stavu. Každý oddíl má relaci AMQP 1.0, která usnadňuje transport událostí rozdělených do oddílů.

Připojení k oddílu

Při připojování k oddílům je běžné použití mechanismu leasingu ke koordinaci připojení čtenářů ke konkrétním oddílům. Díky tomu je možné, že každý oddíl ve skupině příjemců má jenom jeden aktivní čtecí modul. Vytváření kontrolních bodů, zapůjčení a Správa čtenářů se zjednodušují pomocí klientů v rámci Event Hubs SDK, které fungují jako inteligentní agenti zákazníků. Jsou to:

• EventProcessorClient pro .NET
• EventProcessorClient pro jazyk Java
• EventHubConsumerClient pro Python
• EventHubConsumerClient pro JavaScript/TypeScript

Čtení událostí

Po otevření připojení a relace AMQP 1.0 u konkrétního oddílu služba Event Hubs doručí události do klienta protokolu AMQP 1.0. Tento mechanismus doručení umožňuje vyšší propustnost a nižší latenci než mechanismy založené na operaci Pull, jako je například metoda GET protokolu HTTP. Události se posílají klientovi a každá instance dat události obsahuje důležitá metadata, jako je posun a číslo posloupnosti, která se používají k zjednodušení vytváření kontrolních bodů v posloupnosti událostí.

Data události:

• Posun
• Pořadové číslo
• Text
• Uživatelské vlastnosti
• Systémové vlastnosti

Je vaše zodpovědnost za správu posunu.

Další kroky

Další informace o službě Event Hubs naleznete pod těmito odkazy:

• Začínáme se službou Event Hubs
  • .NET
  • Java
  • Python
  • JavaScript

• Průvodce programováním pro službu Event Hubs
• Dostupnost a konzistence ve službě Event Hubs
• Nejčastější dotazy k Event Hubs
• Ukázky Event Hubs