Funkce a terminologie ve službě Azure Event Hubs
Azure Event Hubs je škálovatelná služba zpracování událostí, která ingestuje a zpracovává velké objemy událostí a dat s nízkou latencí a vysokou spolehlivostí. Základní přehled služby najdete v tématu Co je Event Hubs?
Tento článek vychází z informací v článku přehledu a poskytuje technické a implementační podrobnosti o součástech a funkcích služby Event Hubs.
Obor názvů
Obor názvů služby Event Hubs je kontejner pro správu pro centra událostí (nebo témata v parlanci Kafka). Poskytuje koncové body sítě integrované pomocí DNS a řadu funkcí řízení přístupu a správy integrace sítě, jako jsou filtrování IP adres, koncový bod služby virtuální sítě a Private Link.
Oddíly
Event Hubs organizuje posloupnosti událostí odesílaných do centra událostí do jednoho nebo více oddílů. Při příchodu novějších událostí se na konec této sekvence přidají.
Oddíl si můžete představit jako protokol potvrzení. Oddíly uchovávají data událostí, která obsahují následující informace:
- Text události
- Kontejner vlastností definovaný uživatelem popisující událost
- Metadata, jako je jeho posun v oddílu, její číslo v posloupnosti datových proudů
- Časové razítko na straně služby, ve kterém bylo přijato
Výhody používání oddílů
Služba Event Hubs je navržená tak, aby pomohla se zpracováním velkých objemů událostí a dělení pomáhá s tím dvěma způsoby:
- I když je Služba Event Hubs službou PaaS, je pod ní fyzická realita. Udržování protokolu, který zachovává pořadí událostí, vyžaduje, aby se tyto události uchovávaly společně v podkladovém úložišti a jeho replikách a výsledkem je strop propustnosti pro takový protokol. Dělení umožňuje použít více paralelních protokolů pro stejné centrum událostí a tím vynásobit dostupnou kapacitu propustnosti nezpracovaného vstupu a výstupu vstupně-výstupních operací.
- Vaše vlastní aplikace musí být schopné udržovat krok se zpracováním objemu událostí, které se odesílají do centra událostí. Může to být složité a vyžaduje značnou kapacitu paralelního zpracování se škálováním 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í zpracovává tyto procesy a přesto zajišťuje, že každá událost má jasného vlastníka zpracování.
Počet oddílů
Počet oddílů se zadává při vytváření centra událostí. Musí být mezi jedním a maximálním povoleným počtem oddílů pro každou cenovou úroveň. Limit počtu oddílů pro každou úroveň najdete v tomto článku.
Doporučujeme zvolit alespoň tolik oddílů, kolik očekáváte při zatížení vaší aplikace ve špičce pro konkrétní centrum událostí. U vrstev jiných než úrovně Premium a dedicated nemůžete po vytvoření centra událostí změnit počet oddílů. U centra událostí v úrovni Premium nebo dedicated můžete po vytvoření zvýšit počet oddílů, ale nemůžete je snížit. Distribuce datových proudů mezi oddíly se po dokončení mapování klíčů oddílů na změny oddílů změní, takže je vhodné se těmto změnám vyhnout, pokud je v aplikaci důležité relativní pořadí událostí.
Nastavení počtuoddílůch Pokud potřebujete absolutní zachování pořadí napříč všemi událostmi nebo pouze několika podstreamy, možná nebudete moct využívat mnoho oddílů. Mnoho oddílů také zkompiluje zpracování na straně zpracování.
Nezáleží na tom, kolik oddílů je v centru událostí, pokud jde o ceny. Závisí na počtu cenových jednotek (jednotek propustnosti (TU) pro úroveň Standard, jednotek zpracování (RU) pro úroveň Premium a jednotek kapacity (CU) pro vyhrazenou úroveň) pro obor názvů nebo vyhrazený cluster. Například centrum událostí úrovně Standard s 32 oddíly nebo s jedním oddílem se účtují stejné náklady, pokud je obor názvů nastavený na jednu kapacitu TU. Můžete také škálovat jednotky TU nebo PU ve vašem oboru názvů nebo jednotek CU vyhrazeného clusteru nezávisle na počtu oddílů.
Vzhledem k tomu , že oddíl je mechanismus organizace dat, který umožňuje paralelně publikovat a využívat data. Doporučujeme vyvážit jednotky škálování (jednotky propustnosti pro úroveň Standard, jednotky zpracování pro úroveň Premium nebo jednotky kapacity pro vyhrazenou úroveň) a oddíly, abyste dosáhli optimálního škálování. Obecně doporučujeme maximální propustnost 1 MB/s na oddíl. Pravidlo pro výpočet počtu oddílů by proto mělo dělit maximální očekávanou propustnost o 1 MB/s. Pokud například váš případ použití vyžaduje 20 MB/s, doporučujeme zvolit alespoň 20 oddílů, abyste dosáhli optimální propustnosti.
Pokud ale máte model, ve kterém má vaše aplikace spřažení k určitému oddílu, zvýšení počtu oddílů není výhodné. Další informace najdete v tématu Dostupnost a konzistence.
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 prostřednictvím statické funkce hash, která vytvoří přiřazení 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 ve stejném oddílu a v přesném pořadí, ve kterém dorazily. Klíč oddílu je řetězec odvozený z kontextu 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ě protokolů pro mnoho takových datových proudů.
Poznámka:
I když můžete odesílat události přímo do oddílů, nedoporučujeme je, zejména pokud je pro vás důležitá vysoká dostupnost. Downgraduje dostupnost centra událostí na úrovni oddílů. Další informace najdete v tématu Dostupnost a konzistence.
Zdroje událostí
Každá entita, která odesílá data do centra událostí, je vydavatel událostí (synonymem používaným s producentem 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í autorizaci založenou na ID Microsoftu s tokeny JWT vydanými protokolem OAuth2 nebo tokenem sdíleného přístupového podpisu (SAS) specifického pro centrum událostí.
Událost můžete publikovat prostřednictvím protokolu AMQP 1.0, protokolu Kafka nebo HTTPS. Služba Event Hubs poskytuje rozhraní REST API a klientské knihovny .NET, Java, Python, JavaScript a Go 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 HTTPS pro každý požadavek vyžaduje další režii protokolu TLS. AMQP má vyšší výkon pro časté vydavatele a může dosáhnout mnohem nižší latence při použití s asynchronním kódem publikování.
Události můžete publikovat jednotlivě nebo dávkově. Jedna publikace má limit 1 MB bez ohledu na to, jestli se jedná o jednu událost nebo dávku. Publikování událostí větších než tato prahová hodnota se odmítne.
Propustnost služby Event Hubs se škáluje pomocí oddílů a přidělení jednotek propustnosti. Osvědčeným postupem pro vydavatele je zůstat bez vědomí konkrétního modelu dělení zvoleného pro centrum událostí a zadat pouze klíč oddílu, který se používá k konzistentnímu přiřazování souvisejících událostí do stejného oddílu.
Služba Event Hubs zajišťuje, aby všechny události sdílející hodnotu klíče oddílu byly uloženy společně a doručovány 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ých zásad uchovávání informací na základě časového limitu. Tady je několik důležitých bodů:
- Výchozí hodnota a nejkratší možná doba uchovávání je 1 hodina. V současné době můžete dobu uchovávání nastavit pouze v hodinách na webu Azure Portal. Šablona Resource Manageru, PowerShell a rozhraní příkazového řádku umožňují nastavit tuto vlastnost pouze ve dnech.
- Pro službu Event Hubs Standard je maximální doba uchovávání 7 dnů.
- V případě služby Event Hubs Premium a Dedicated je maximální doba uchovávání 90 dnů.
- Pokud dobu uchovávání změníte, platí pro všechny události, včetně událostí, které jsou již v centru událostí.
Služba Event Hubs uchovává události pro nakonfigurovanou dobu uchovávání informací, která se vztahuje na všechny oddíly. Události se po dosažení doby uchovávání automaticky odeberou. Pokud jste zadali dobu uchování jednoho dne (24 hodin), stane se událost nedostupnou přesně 24 hodin po přijetí. Události nelze explicitně odstranit.
Pokud potřebujete archivovat události nad rámec povolené doby uchovávání, můžete je automaticky uložit ve službě Azure Storage nebo Azure Data Lake zapnutím funkce Event Hubs Capture. Pokud potřebujete vyhledávat nebo analyzovat takové hloubkové archivy, můžete je snadno importovat do Azure Synapse nebo do jiných podobných úložišť a analytických platforem.
Důvodem limitu služby Event Hubs pro uchovávání dat na základě času je zabránit tomu, aby se velké objemy historických zákaznických dat zachytávali v hlubokém úložišti, které je indexováno pouze časovým razítkem a umožňuje sekvenční přístup. Zde je filozofie architektury, že historická data potřebují bohatší indexování a více přímého přístupu než rozhraní událostí v reálném čase, které poskytuje Event Hubs nebo Kafka. Moduly streamu událostí se nehodí k tomu, aby hrály roli datových jezer nebo dlouhodobých archivů pro event sourcing.
Poznámka:
Event Hubs je modul streamu událostí v reálném čase a není navržený tak, aby se používal místo databáze nebo jako trvalé úložiště pro nekonečně uchovávané streamy událostí.
Čím hlubší je historie datového proudu událostí, tím více budete potřebovat pomocné indexy k vyhledání konkrétního historického řezu daného streamu. Kontrola datových částí událostí a indexování nejsou v rozsahu funkcí služby Event Hubs (nebo Apache Kafka). Databáze a specializované analytické úložiště a moduly, jako jsou Azure Data Lake Store, Azure Data Lake Analytics a Azure Synapse, jsou proto mnohem vhodnější pro ukládání historických událostí.
Event Hubs Capture se integruje přímo se službou Azure Blob Storage a Azure Data Lake Storage a prostřednictvím této integrace také umožňuje tok událostí přímo do Azure Synapse.
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 vydavatele musí být hodnota PartitionKey nastavena na název vydavatele. Aby vše správně fungovalo, musí tyto hodnoty odpovídat.
Capture
Event Hubs Capture umožňuje automaticky zachytit streamovaná data ve službě Event Hubs a uložit je do libovolného účtu úložiště objektů blob nebo účtu Azure Data Lake Storage. Zachytávání můžete povolit na webu 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 služby Azure Blob Storage nebo účet Azure Data Lake Storage, z něhož se používají k ukládání zachycených dat. Zachycená data se zapisuje ve formátu Apache Avro.
Soubory vytvořené službou Event Hubs Capture mají následující schéma Avro:
Poznámka:
Pokud na webu Azure Portal nepoužíváte žádný editor kódu, můžete zachytit streamovaná data ve službě Event Hubs v účtu Azure Data Lake Storage Gen2 ve formátu Parquet . Další informace najdete v tématu Postupy: Zachycení dat ze služby Event Hubs ve formátu Parquet a kurz: zachycení dat služby Event Hubs ve formátu Parquet a analýza pomocí služby Azure Synapse Analytics.
Tokeny SAS
Služba Event Hubs využívá sdílené přístupové podpisy, které jsou dostupné 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 hodnotu hash pomocí názvu klíče (zásady) a tokenu a tím ověřit odesílatele. Za normálních okolností se tokeny SAS pro zdroje událostí vytváří jen 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í
Příjemcem událostí je každá entita, která čte data událostí z centra 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 nemusí dotazovat na dostupnost dat.
Skupiny uživatelů
Mechanismus publikování/odebírání ve službě Event Hubs umožňují skupiny příjemců. Skupina příjemců je logické seskupení příjemců, kteří čtou data z centra událostí nebo tématu Kafka. Umožňuje více aplikacím číst stejná streamovaná data v centru událostí nezávisle na sobě vlastním tempem s jejich posuny. Umožňuje paralelizovat spotřebu zpráv a distribuovat úlohy mezi více příjemců při zachování pořadí zpráv v rámci každého oddílu.
Doporučujeme, aby v oddílu ve skupině příjemců byl jen jeden aktivní příjemce. V určitých scénářích ale můžete použít až pět příjemců nebo příjemců na oddíl, kde všichni příjemci získají všechny události oddílu. Pokud máte ve stejném oddílu více čtenářů, zpracujete duplicitní události. Musíte ho zpracovat ve svém kódu, což není triviální. V některých scénářích je to ale platný přístup.
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 pro odpovídající cenovou úroveň můžete vytvořit až maximální počet skupin příjemců.
Někteří klienti nabízení sadami Azure SDK jsou inteligentní spotřebitelé agenti, kteří automaticky spravují podrobnosti o tom, že každý oddíl má jednu čtečku a že se čtou všechny oddíly centra událostí. Umožňuje vašemu kódu zaměřit se na zpracování událostí, které se čtou z centra událostí, aby mohl ignorovat mnoho podrobností oddílů. Další informace najdete v tématu Připojení oddílu.
Následující příklady ukazují konvenci identifikátoru URI skupiny 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í a určí 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. Ke starším datům se můžete vrátit zadáním nižšího posunu z tohoto procesu vytváření kontrolních bodů. 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.
Důležité
Posuny jsou poskytovány službou Event Hubs. Za zpracování událostí zodpovídá příjemce.
Při používání služby Azure Blob Storage jako úložiště kontrolních bodů postupujte podle těchto doporučení:
- Pro každou skupinu příjemců použijte samostatný kontejner. Můžete použít stejný účet úložiště, ale pro každou skupinu použít jeden kontejner.
- Nepoužívejte kontejner pro nic jiného a nepoužívejte účet úložiště pro nic jiného.
- Účet úložiště by měl být ve stejné oblasti jako nasazená aplikace. Pokud je aplikace místní, zkuste zvolit nejbližší možnou oblast.
Na stránce účtu úložiště na webu Azure Portal v části Blob Service se ujistěte, že jsou zakázaná následující nastavení.
- Hierarchický obor názvů
- Obnovitelné odstranění objektu blob
- Vytváření verzí
Komprimace protokolů
Azure Event Hubs podporuje komprimace protokolu událostí, aby se zachovaly nejnovější události daného klíče události. S komprimovanými centry událostí nebo tématem Kafka můžete místo použití hrubšího uchovávání informací založeného na čase použít uchovávání založené na klíčích.
Další informace o komprimování protokolů naleznete v tématu Komprimace protokolu.
Běžné úlohy příjemce
Všichni příjemci služby Event Hubs se připojují prostřednictvím relace AMQP 1.0, obousměrného komunikačního kanálu pracujícího se stavem. 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 se běžně používá mechanismus leasingu ke koordinaci připojení čtenáře ke konkrétním oddílům. Tímto způsobem je možné, že každý oddíl ve skupině příjemců bude mít jenom jednu aktivní čtečku. Vytváření kontrolních bodů, leasing a správa čtenářů jsou zjednodušené pomocí klientů v sadách SDK služby Event Hubs, které fungují jako inteligentní spotřebitelé agenti. Mezi ně patří:
- EventProcessorClient pro .NET
- EventProcessorClient pro Javu
- 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:
- Odsazení
- Pořadové číslo
- Text
- Uživatelské vlastnosti
- Systémové vlastnosti
Je to vaše zodpovědnost za správu posunu.
Skupiny aplikací
Skupina aplikací je kolekce klientských aplikací, které se připojují k oboru názvů služby Event Hubs, který sdílí jedinečnou identifikaci podmínky, jako je kontext zabezpečení – zásady sdíleného přístupu nebo ID aplikace Microsoft Entra.
Azure Event Hubs umožňuje definovat zásady přístupu k prostředkům, jako jsou zásady omezování pro danou skupinu aplikací a řídí streamování událostí (publikování nebo využívání) mezi klientskými aplikacemi a službou Event Hubs.
Další informace najdete v tématu Zásady správného řízení prostředků pro klientské aplikace se skupinami aplikací.
Podpora Apache Kafka
Podpora protokolu pro klienty Apache Kafka (verze >=1.0) poskytuje koncové body, které umožňují stávajícím aplikacím Kafka používat službu Event Hubs. Většina existujících aplikací Kafka se dá jednoduše překonfigurovat tak, aby odkazovala na obor názvů s místo na server bootstrap clusteru Kafka.
Z hlediska nákladů, provozního úsilí a spolehlivosti je azure Event Hubs skvělou alternativou k nasazení a provozu vlastních clusterů Kafka a Zookeeper a nabídek kafka jako služby, které nejsou nativní pro Azure.
Kromě získání stejné základní funkce jako u zprostředkovatele Apache Kafka získáte také přístup k funkcím Služby Azure Event Hubs, jako je automatické dávkování a archivace prostřednictvím služby Event Hubs Capture, automatické škálování a vyrovnávání, zotavení po havárii, podpora nákladově neutrální zóny dostupnosti, flexibilní a zabezpečená integrace sítě a podpora více protokolů, včetně protokolu AMQP-over-WebSockets.
Další kroky
Další informace o službě Event Hubs naleznete pod těmito odkazy:
- Začínáme se službou Event Hubs