Funzionalità e terminologia di Hub eventi di Azure

Hub eventi di Azure è un servizio scalabile di elaborazione degli eventi che inserisce ed elabora grandi volumi di eventi e dati, con latenza bassa e affidabilità elevata. Per una panoramica generale del servizio, vedere Che cos'è Hub eventi?.

Questo articolo si basa sulle informazioni presenti nella panoramica e contiene dettagli tecnici e informazioni sull'implementazione relativi ai componenti e alle funzionalità di Hub eventi.

Spazio dei nomi

Uno spazio dei nomi di Hub eventi è un contenitore di gestione per hub eventi (o argomenti, in linguaggio Kafka). Fornisce endpoint di rete integrati con DNS e una gamma di funzionalità di controllo di accesso e gestione dell'integrazione di rete, ad esempio filtro IP, endpoint servizio di rete virtuale e collegamento privato.

Partizioni

L'Hub eventi organizza le sequenze di eventi in una o più partizioni. Man mano che arrivano, i nuovi eventi vengono aggiunti alla fine di questa sequenza.

Una partizione può essere considerata come registro commit. Le partizioni contengono i dati dell'evento con le informazioni seguenti:

• Corpo dell'evento
• Contenitore di proprietà definito dall'utente che descrive l'evento
• Metadati, ad esempio l'offset nella partizione e il relativo numero nella sequenza di flusso
• Timestamp sul lato servizio in corrispondenza del quale è stato accettato

Vantaggi dell'utilizzo delle partizioni

Hub eventi è progettato per semplificare l'elaborazione di volumi elevati di eventi e il partizionamento contribuisce a questo scopo in due modi:

• Anche se Hub eventi è un servizio PaaS, esiste una realtà fisica sottostante. Per mantenere un log che preservi l'ordine degli eventi è necessario che tali eventi vengano tenuti insieme nell'archiviazione sottostante e nelle relative repliche e che il risultato sia un limite di velocità effettiva per tale log. Il partizionamento consente l'uso di più log paralleli per lo stesso hub eventi e quindi la moltiplicazione della capacità di output di input non elaborato (I/O) disponibile.
• Le applicazioni devono essere in grado di tenere il passo con l'elaborazione del volume di eventi inviati a un hub eventi. Questa operazione può essere complessa e richiede una capacità di elaborazione parallela sostanziale e scale-out. La capacità di gestione degli eventi di un singolo processo è limitata, quindi sono necessari diversi processi. Le partizioni sono il modo in cui la soluzione inserisce tali processi e garantisce tuttavia che ogni evento abbia un proprietario di elaborazione chiaro.

Numero di partizioni

Il numero di partizioni viene specificato al momento della creazione di un hub eventi. Deve essere compreso tra uno e il numero massimo di partizioni consentito per ogni piano tariffario. Per conoscere il limite del numero di partizioni per ogni livello, vedere questo articolo.

È consigliabile scegliere almeno il numero di partizioni previste durante il carico massimo dell'applicazione per tale hub eventi specifico. Per i livelli diversi dai livelli dedicati e Premium, non è possibile modificare il numero di partizioni per un hub eventi dopo la creazione. Per un hub eventi in un livello Premium o dedicato, è possibile aumentare il numero di partizioni dopo la creazione, ma non è possibile ridurlo. La distribuzione dei flussi tra le partizioni cambierà perché il mapping delle chiavi di partizione alle partizioni cambia, pertanto è consigliabile provare a evitare tali modifiche se l'ordine relativo degli eventi è importante nell'applicazione.

Si potrebbe essere tentati di impostare il numero di partizioni sul valore massimo consentito, ma tenere sempre presente che i flussi di eventi devono essere strutturati in modo da consentire di usufruire di più partizioni. Se è necessario preservare l'ordine assoluto in tutti gli eventi o solo in pochi sottoflussi, è possibile che non si riesca a sfruttare molte partizioni. Inoltre, molte partizioni rendono l'elaborazione più complessa.

Non importa quante partizioni si trovano in un hub eventi quando si tratta di prezzi. Dipende dal numero di unità tariffarie (unità elaborate (TU) per il livello Standard, unità di elaborazione (PU) per il livello Premium e unità di capacità (CU) per il livello dedicato) per lo spazio dei nomi o il cluster dedicato. Ad esempio, un hub eventi del livello standard con 32 partizioni o con una partizione comporta lo stesso costo esatto quando lo spazio dei nomi è impostato su una capacità TU. È anche possibile ridimensionare le TU o PU nello spazio dei nomi o le CU del cluster dedicato indipendentemente dal numero di partizioni.

La partizione è un meccanismo di organizzazione dei dati che consente di pubblicare e utilizzare i dati in modo parallelo. È consigliabile bilanciare le unità di ridimensionamento (unità elaborate per il livello Standard, le unità di elaborazione per il livello Premium o le unità di capacità per il livello dedicato) e le partizioni per ottenere una scalabilità ottimale. In generale, è consigliabile una velocità effettiva massima di 1 MB/s per partizione. Pertanto, una regola generale per calcolare il numero di partizioni consiste nel dividere la velocità effettiva massima prevista per 1 MB/s. Ad esempio, se il caso d'uso richiede 20 MB/s, è consigliabile scegliere almeno 20 partizioni per ottenere la velocità effettiva ottimale.

Tuttavia, se si dispone di un modello in cui l'applicazione ha un'affinità con una determinata partizione, l'aumento del numero di partizioni non è vantaggioso. Per altre informazioni, vedere Disponibilità e coerenza.

Mapping di eventi a partizioni

È possibile usare una chiave di partizione per mappare i dati dell'evento in ingresso in partizioni specifiche ai fini dell'organizzazione dei dati. La chiave di partizione è un valore fornito dal mittente che viene passato a un hub eventi. Viene elaborato tramite una funzione hash statica, che crea l'assegnazione di partizione. Se non si specifica una chiave di partizione quando si pubblica un evento, viene usata un'assegnazione round robin.

L'autore di eventi è a conoscenza solo della chiave di partizione, non la partizione in cui gli eventi vengono pubblicati. Questa separazione tra chiave e partizione evita che il mittente debba conoscere troppe informazioni sull'elaborazione downstream. Un’identità univoca per dispositivo o utente crea una chiave di partizione efficace, ma è possibile utilizzare anche altri attributi, ad esempio l’area geografica, per raggruppare gli eventi correlati in un'unica partizione.

La specifica di una chiave di partizione consente di mantenere insieme gli eventi correlati nella stessa partizione e nell'ordine esatto in cui sono arrivati. La chiave di partizione è una stringa derivata dal contesto dell'applicazione che identifica l'interrelazione degli eventi. Una sequenza di eventi identificata da una chiave di partizione è un flusso. Una partizione è un archivio di log multiplex per molti flussi di questo tipo.

Publisher di eventi

Qualsiasi entità che invia dati a un hub eventi è un autore di eventi (usato come sinonimo di producer di eventi). Gli autori di eventi possono pubblicare eventi usando HTTPS o AMQP 1.0 o il protocollo Kafka. Gli autori di eventi usano l'autorizzazione basata su Microsoft Entra ID con token JWT rilasciati da OAuth2 o un token di firma di accesso condiviso specifico dell'hub eventi per ottenere l'accesso alla pubblicazione.

È possibile pubblicare un evento tramite AMQP 1.0, il protocollo Kafka o HTTPS. Il servizio Hub eventi fornisce API REST e librerie client .NET, Java, Python, JavaScript e Go per la pubblicazione di eventi in un hub eventi. Per altre piattaforme e runtime, è possibile utilizzare qualsiasi client AMQP 1.0, ad esempio Apache Qpid.

La scelta tra AMQP e HTTPS dipende dallo scenario di utilizzo. AMQP richiede di stabilire un socket bidirezionale persistente oltre alla sicurezza a livello di trasporto (TLS) o SSL/TLS. AMQP ha costi di rete più elevati durante l'inizializzazione della sessione, ma HTTPS richiede un sovraccarico TLS aggiuntivo per ogni richiesta. AMQP offre prestazioni più elevate per gli autori che pubblicano di frequente e può ottenere latenze molto inferiori se usate con codice di pubblicazione asincrona.

È possibile pubblicare gli eventi singolarmente o in batch. Una singola pubblicazione ha un limite di 1 MB, indipendentemente dal fatto che si tratti di un singolo evento o di un batch. Gli eventi di pubblicazione con dimensioni superiori a questa soglia vengono rifiutati.

La velocità effettiva di Hub eventi viene ridimensionata usando partizioni e allocazioni di unità elaborate. È consigliabile che gli autori non conoscano il modello di partizionamento specifico scelto per un hub eventi e che venga specificata solo una chiave di partizione usata per assegnare in modo coerente gli eventi correlati alla stessa partizione.

Hub eventi garantisce che tutti gli eventi che condividono un valore di chiave di partizione vengano archiviati insieme e recapitati in ordine di arrivo. Se si usano chiavi di partizione con i criteri di autore, l'identità dell’autore e il valore della chiave di partizione devono corrispondere. In caso contrario si verifica un errore.

Conservazione degli eventi

Gli eventi pubblicati vengono rimossi da un hub eventi in base a un criterio di conservazione configurabile e basato sul tempo. Ecco alcuni punti importanti:

• Il valore predefinito e il periodo di conservazione più breve possibile è 1 ora.
• Per Hub eventi Standard, il periodo di conservazione massimo è 7 giorni.
• Per Hub eventi Premium e Dedicato, il periodo di conservazione massimo è 90 giorni.
• Se si modifica il periodo di conservazione, la modifica verrà applicata a tutti gli eventi inclusi gli eventi già presenti nell'hub eventi.

Hub eventi mantiene gli eventi per un periodo di conservazione configurato che viene applicato a tutte le partizioni. Gli eventi vengono rimossi automaticamente al raggiungimento del periodo di conservazione. Se è stato specificato un periodo di conservazione di un giorno (24 ore), l'evento diventa non disponibile esattamente 24 ore dopo che è stato accettato. Non è possibile eliminare in modo esplicito gli eventi.

Se è necessario archiviare gli eventi oltre il periodo di conservazione consentito, è possibile archiviarli automaticamente in Archiviazione di Azure o Azure Data Lake attivando la funzionalità Acquisizione di Hub eventi. Se è necessario eseguire ricerche o analizzare tali archivi profondi, è possibile importarli facilmente in Azure Synapse o in altri archivi e piattaforme di analisi simili.

Il motivo del limite temporale di Hub eventi per la conservazione dei dati è di impedire che volumi elevati di dati cronologici dei clienti vengano intrappolati in un archivio profondo che viene indicizzato solo in base a timestamp e consente solo l'accesso sequenziale. La filosofia alla base dell'architettura è che i dati cronologici richiedono un'indicizzazione più avanzata e un accesso più diretto rispetto all'interfaccia eventi in tempo reale fornita da Hub eventi o Kafka. I motori di streaming di eventi non sono adatti per svolgere il ruolo di data lake o archivi a lungo termine per l'origine degli eventi.

Criteri di autore

Hub eventi consente un controllo granulare degli autori di eventi tramite criteri di autore. I criteri di autore sono funzionalità di runtime progettate per consentire un numero elevato di autori di eventi indipendenti. Con i criteri di autore, ogni autore usa il proprio identificatore univoco durante la pubblicazione di eventi in un hub eventi, con il meccanismo seguente:

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

Non è necessario creare nomi di autore prima di procedere, ma devono corrispondere al token SAS utilizzato quando si pubblica un evento, al fine di garantire le identità di autore indipendenti. Quando si usano i criteri di pubblicazione, il valore PartitionKey deve essere impostato sul nome dell'autore. Per il corretto funzionamento, questi valori devono corrispondere.

Acquisire

Acquisizione di Hub eventi consente di acquisire automaticamente i dati in streaming in Hub eventi e salvarli, a propria scelta, in un account di archiviazione BLOB o un account di Azure Data Lake Storage. È possibile abilitare la funzione Acquisizione dal portale di Azure e specificare una dimensione minima e l'intervallo di tempo per eseguire l'acquisizione. L'Acquisizione di Hub eventi consente di specificare un contenitore e un account di Archiviazione BLOB di Azure oppure un account di Azure Data Lake Storage da usare per archiviare i dati acquisiti. I dati acquisiti vengono scritti nel formato di Apache Avro.

I file generati da Acquisizione di Hub eventi hanno lo schema Avro seguente:

Token di firma di accesso condiviso

Hub eventi usa firme di accesso condiviso, disponibili a livello di spazio dei nomi e di hub eventi. Un token SAS viene generato da una chiave SAS ed è un hash SHA di un URL, codificato in un formato specifico. Hub eventi può rigenerare l'hash usando il nome della chiave (criterio) e il token e quindi autenticare il mittente. In genere, i token di firma di accesso condiviso per gli autori di eventi vengono creati con privilegi solo di invio per un hub eventi specifico. Questo meccanismo di URL token SAS costituisce la base per l'identificazione dell’autore introdotta nei criteri di autore. Per altre informazioni sull'uso di SAS, vedere Autenticazione della firma di accesso condiviso con il bus di servizio.

Consumer di eventi

Qualsiasi entità che legge i dati dell'evento da un hub eventi è un consumer eventi. I consumer o i ricevitori usano AMQP o Apache Kafka per ricevere eventi da un hub eventi. Hub eventi supporta solo il modello pull da cui i consumer ricevono gli eventi. Anche quando si usano gestori eventi per gestire gli eventi da un hub eventi, il processore di eventi usa internamente il modello pull per ricevere eventi dall'hub eventi.

Gruppi di consumer

Il meccanismo di pubblicazione/sottoscrizione degli Hub eventi è abilitato tramite i gruppi di consumer. Un gruppo di consumer è un raggruppamento logico di consumer che leggono i dati da un hub eventi o da un argomento Kafka. Consente a più applicazioni consumer di leggere gli stessi dati di streaming in un hub eventi in modo indipendente con i propri offset. Consente di parallelizzare l'utilizzo dei messaggi e di distribuire il carico di lavoro tra più consumer mantenendo l'ordine dei messaggi all'interno di ogni partizione.

È consigliabile che sia presente solo un ricevitore attivo in una partizione all'interno di un gruppo di consumer. In alcuni scenari, tuttavia, è possibile usare fino a cinque consumer o ricevitori per partizione in cui tutti i ricevitori ottengono tutti gli eventi della partizione. Se si hanno più lettori nella stessa partizione, si elaborano eventi duplicati. È necessario gestire questo aspetto nel codice, che non è semplice. È tuttavia un approccio valido in alcuni scenari.

In un'architettura di elaborazione del flusso, ogni applicazione downstream equivale a un gruppo di consumer. Se si vogliono scrivere i dati degli eventi nell'archiviazione a lungo termine, tale applicazione del writer di archiviazione è un gruppo di consumer. L'elaborazione di eventi complessi può quindi essere eseguita da un altro gruppo di consumer separato. È possibile accedere alle partizioni solo tramite un gruppo di consumer. Esiste sempre un gruppo di consumer predefinito in un hub eventi ed è possibile creare gruppi fino al numero massimo di gruppi di consumer per il piano tariffario corrispondente.

Alcuni client offerti dagli SDK di Azure sono agenti consumer intelligenti che gestiscono automaticamente i dettagli per garantire che ogni partizione abbia un singolo lettore e che venga eseguita la lettura da tutte le partizioni per un hub eventi. Consente al codice di concentrarsi sull'elaborazione degli eventi letti dall'hub eventi in modo che possa ignorare molti dei dettagli delle partizioni. Per altre informazioni, vedere Connettersi a una partizione.

Gli esempi seguenti illustrano la convenzione URI del gruppo di consumer:

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

La figura seguente illustra l'architettura di elaborazione del flusso di Hub eventi:

Offset di flusso

Un offset è la posizione di un evento all'interno di una partizione. Un offset può essere considerato come un cursore sul lato client. L'offset è la numerazione di byte dell'evento. Questo offset consente a un consumer di eventi (lettore) di specificare un punto nel flusso di eventi da cui iniziare la lettura degli eventi. È possibile specificare l'offset come un timestamp o un valore di offset. I consumer sono responsabili di archiviare i propri valori di offset all'esterno del servizio Hub eventi. All'interno di una partizione, ogni evento include un offset.

Checkpoint

Checkpoint è un processo mediante il quale i lettori contrassegnano o eseguono il commit della propria posizione all'interno di una sequenza di eventi di partizione. Il checkpoint è responsabilità del consumer e si verifica per partizione all'interno di un gruppo di consumer. Questa responsabilità significa che per ogni gruppo di consumer, ogni lettore di partizione deve tenere traccia della posizione corrente nel flusso di eventi e può informare il servizio quando considera completo il flusso di dati.

Se un lettore si disconnette da una partizione, quando riconnette inizia a leggere in corrispondenza del checkpoint inviato in precedenza dall’ulitimo lettore di tale partizione in tale gruppo di consumer. Quando il lettore si connette, passa l'offset all'hub eventi per specificare la posizione da cui iniziare la lettura. In questo modo è possibile usare la funzionalità di checkpoint sia per contrassegnare gli eventi come "completi" dalle applicazioni a valle sia per fornire la resilienza in caso di failover tra i lettori in esecuzione in computer diversi. È possibile tornare a dati precedenti specificando un offset inferiore da questo processo di checkpoint. Tramite questo meccanismo il checkpoint consente sia la resilienza del failover che la riproduzione del flusso di eventi.

Seguire queste raccomandazioni quando si usa Archiviazione BLOB di Azure come archivio checkpoint:

• Usare un contenitore separato per ogni gruppo di consumer. È possibile usare lo stesso account di archiviazione, ma occorre usare un contenitore per ogni gruppo.
• Non usare il contenitore per altri elementi e non usare l'account di archiviazione per altri elementi.
• L'account di archiviazione deve trovarsi nella stessa area in cui si trova l'applicazione distribuita. Se l'applicazione è locale, provare a scegliere l'area più vicina possibile.

Nella pagina Account di archiviazione del portale di Azure verificare che le impostazioni seguenti siano disabilitate nella sezione Servizio BLOB.

• Spazio dei nomi gerarchico
• Eliminazione temporanea dei BLOB
• Controllo delle versioni

Compattazione dei log

Hub eventi di Azure supporta la compattazione del registro eventi per conservare gli eventi più recenti di una determinata chiave evento. Con l'argomento Hub eventi/Kafka compresso, è possibile usare la conservazione basata su chiave anziché usare la conservazione basata sul tempo meno dettagliata.

Per altre informazioni sulla compattazione dei log, vedere Compattazione dei log.

Attività comuni del consumer

Tutti i consumer di Hub eventi si connettono tramite una sessione AMQP 1.0 e un canale di comunicazione bidirezionale in grado di riconoscere lo stato. Ogni partizione ha una sessione AMQP 1.0 che facilita il trasporto di eventi separati dalla partizione.

Connettersi a una partizione

Quando ci si connette direttamente a partizioni, viene in genere usato un meccanismo di leasing per coordinare le connessioni di lettura per partizioni specifiche. In questo modo è possibile per ogni partizione in un gruppo di consumer avere un solo lettore attivo. I checkpoint, il leasing e la gestione dei lettori sono semplificati usando i client all'interno degli SDK di Hub eventi, che fungono da agenti consumer intelligenti. Sono:

• EventProcessorClient per .NET
• EventProcessorClient per Java
• EventHubConsumerClient per Python
• EventHubConsumerClient per JavaScript/TypeScript

Leggere gli eventi

Dopo l'apertura di una sessione AMQP 1.0 e del collegamento per una partizione specifica, gli eventi vengono recapitati al client AMQP 1.0 dal servizio Hub eventi. Questo meccanismo di recapito permette una velocità effettiva più elevata e una latenza più bassa rispetto ai meccanismi basati su pull, ad esempio HTTP GET. Quando gli eventi vengono inviati al client, ogni istanza dei dati dell'evento contiene metadati importanti, ad esempio l’offset e il numero di sequenza utilizzati per facilitare il checkpoint sulla in sequenza di eventi.

Dati evento:

• Contropartita
• Sequenza numerica
• Testo
• Proprietà utente
• Proprietà di sistema

L'utente è responsabile della gestione dell'offset.

Gruppi di applicazioni

Un gruppo di applicazioni è una raccolta di applicazioni client che si connettono a uno spazio dei nomi di Hub eventi e che condividono una condizione di identificazione univoca, ad esempio il contesto di sicurezza, i criteri di accesso condiviso o l'ID applicazione Microsoft Entra.

Hub eventi di Azure consente di definire criteri di accesso alle risorse, ad esempio i criteri di limitazione, per un determinato gruppo di applicazioni e controlla lo streaming di eventi (pubblicazione o utilizzo) tra applicazioni client e Hub eventi.

Per altre informazioni, vedere Governance delle risorse per le applicazioni client con gruppi di applicazioni.

Supporto di Apache Kafka

Il supporto del protocollo per client Apache Kafka (versioni >=1.0) fornisce endpoint che consentono alle applicazioni Kafka esistenti di usare Hub eventi. La maggior parte delle applicazioni Kafka esistenti può essere riconfigurata in modo che punti a uno spazio dei nomi s anziché a un server bootstrap del cluster Kafka.

Dal punto di vista dei costi, delle attività operative e dell'affidabilità, Hub eventi di Azure è un'ottima alternativa alla distribuzione e alla gestione di cluster Kafka e Zookeeper e alle offerte Kafka-as-a-Service non native in Azure.

Oltre a ottenere le stesse funzionalità di base del broker Apache Kafka, si ottiene anche l'accesso alle funzionalità di Hub eventi di Azure, ad esempio invio automatico in batch e archiviazione automatica tramite Acquisizione di Hub eventi, scalabilità e bilanciamento automatici, ripristino di emergenza, supporto della zona di disponibilità indipendente dai costi, integrazione della rete flessibile e sicura e supporto di più protocolli, incluso il protocollo AMQP-over-WebSockets.

Protocolli

I producer o i mittenti possono usare protocolli AMQP (Advanced Messaging Queuing Protocol), Kafka o HTTPS per inviare eventi a un hub eventi.

I consumer o i ricevitori usano AMQP o Kafka per ricevere eventi da un hub eventi. Hub eventi supporta solo il modello pull da cui i consumer ricevono gli eventi. Anche quando si usano gestori eventi per gestire gli eventi da un hub eventi, il processore di eventi usa internamente il modello pull per ricevere eventi dall'hub eventi.

AMQP

È possibile usare il protocollo AMQP 1.0 per inviare e ricevere eventi da Hub eventi di Azure. AMQP offre comunicazioni affidabili, efficienti e sicure per l'invio e la ricezione di eventi. È possibile usarlo per lo streaming ad alte prestazioni e in tempo reale ed è supportato dalla maggior parte degli SDK di Hub eventi di Azure.

HTTPS/REST API

È possibile inviare eventi solo a Hub eventi usando le richieste HTTP POST. Hub eventi non supporta la ricezione di eventi tramite HTTPS. È adatto per i client leggeri in cui una connessione TCP diretta non è fattibile.

Apache Kafka

Hub eventi di Azure ha un endpoint Kafka predefinito che supporta producer e consumer Kafka. Le applicazioni compilate con Kafka possono usare il protocollo Kafka (versione 1.0 o successiva) per inviare e ricevere eventi da Hub eventi senza modifiche al codice.

Gli SDK di Azure astraggono i protocolli di comunicazione sottostanti e offrono un modo semplificato per inviare e ricevere eventi da Hub eventi usando linguaggi come C#, Java, Python, JavaScript e così via.

Passaggi successivi

Per altre informazioni su Hub eventi, vedere i collegamenti seguenti:

• Introduzione all'Hub eventi
  • .NET
  • Java
  • Python
  • JavaScript

• Disponibilità e coerenza nell'Hub eventi
• Domande frequenti su Hub eventi
• Esempi di Hub eventi