Hub eventi di Azure e più gruppi di consumatori

Question

Serve aiuto per l'utilizzo degli hub di eventi di Azure nel seguente scenario. Penso che i gruppi di consumatori potrebbero essere l'opzione giusta per questo scenario, ma non sono stato in grado di trovare un esempio concreto online.

Ecco la descrizione approssimativa del problema e la soluzione proposta con i mozzi di eventi (io non sono sicuro se questa è la soluzione ottimale. Sarà apprezzare il tuo feedback)

ho più fonti di eventi che generano molti dati di eventi (dati di telemetria dai sensori) che devono essere salvati nel nostro database e alcune analisi come la media corrente, min-max devono essere eseguite in parallelo.

Il mittente può solo inviare dati a un singolo endpoint, ma l'event-hub dovrebbe rendere questi dati disponibili a entrambi i gestori di dati.

Sto pensando di utilizzare due gruppi di consumatori, il primo sarà un cluster di istanze di ruolo di lavoro che si occuperanno di salvare i dati nel nostro archivio di valori-chiave e il secondo gruppo di consumatori sarà un motore di analisi (probabile andare con Azure Stream Analysis).

In primo luogo, come impostare i gruppi di consumatori e c'è qualcosa che devo fare sul lato mittente/destinatario in modo che le copie degli eventi vengano visualizzate su tutti i gruppi di consumatori?

Ho letto molti esempi online, ma o usano client.GetDefaultConsumerGroup(); e/o hanno tutte le partizioni elaborate da più istanze di uno stesso ruolo di lavoro.

Per il mio scenario, quando viene attivato un evento, ha bisogno di essere trattati da due diversi ruoli dei lavoratori in parallelo (uno che salva i dati e il secondo uno che fa un po 'di analisi)

Thank You!

Answer 1

TLDR: sembra ragionevole, basta creare due gruppi di consumatori utilizzando nomi diversi con CreateConsumerGroupIfNotExists.

I gruppi di consumatori sono principalmente un concetto, quindi esattamente il modo in cui funzionano dipende da come vengono implementati i vostri iscritti. Come sai, concettualmente sono un gruppo di abbonati che lavorano insieme in modo che ogni gruppo riceva tutti i messaggi e in circostanze ideali (che non accadrà) probabilmente consuma ciascun messaggio una volta. Ciò significa che ogni gruppo di consumatori avrà "tutte le partizioni elaborate da più istanze dello stesso ruolo di lavoro". Tu vuoi questo.

Questo può essere implementato in diversi modi. Microsoft ha fornito due modi per utilizzare direttamente i messaggi da Event Hub oltre all'opzione di utilizzare elementi come Streaming Analytics che sono probabilmente costruiti in base ai due modi diretti. Il primo modo è il Event Hub Receiver, il secondo che è il livello più alto è il Event Processor Host.

Non ho usato Event Hub Receiver direttamente in modo da questo particolare commento si basa sulla teoria di come questi tipi di sistemi di lavoro e di speculazione dalla documentazione: Mentre sono created da EventHubConsumerGroups questo serve a ben poco come questi ricevitori non coordinano con una sola un altro. Se si utilizzano questi elementi, è necessario (e possibile!) Eseguire autonomamente il coordinamento e l'esecuzione degli offset che presenta vantaggi in alcuni scenari, ad esempio la scrittura dell'offset in un DB transazionale nella stessa transazione degli aggregati calcolati.L'utilizzo di questi low level receivers, con gruppi di consumatori logici diversi che utilizzano lo stesso gruppo di utenti di Azure probabilmente non dovrebbe essere particolarmente problematico (consigli normativi non pratici), ma è necessario utilizzare nomi diversi nel caso in cui sia importante o si passi a EventProcessorHosts.

Ora su ulteriori informazioni utili, EventProcessorHosts sono probabilmente costruiti sopra EventHubReceivers. Sono una cosa di livello superiore e c'è il supporto per consentire a più macchine di lavorare insieme come un gruppo di consumatori logici. Di seguito ho incluso uno snippet leggermente modificato dal mio codice che rende uno EventProcessorHost con una serie di commenti lasciati nello spiegare alcune scelte.

//We need an identifier for the lease. It must be unique across concurrently 
//running instances of the program. There are three main options for this. The 
//first is a static value from a config file. The second is the machine's NETBIOS 
//name ie System.Environment.MachineName. The third is a random value unique per run which 
//we have chosen here, if our VMs have very weak randomness bad things may happen. 

string hostName = Guid.NewGuid().ToString(); 

//It's not clear if we want this here long term or if we prefer that the Consumer 
//Groups be created out of band. Nor are there necessarily good tools to discover 
//existing consumer groups. 
NamespaceManager namespaceManager = 
    NamespaceManager.CreateFromConnectionString(eventHubConnectionString); 
EventHubDescription ehd = namespaceManager.GetEventHub(eventHubPath); 
namespaceManager.CreateConsumerGroupIfNotExists(ehd.Path, consumerGroupName); 

host = new EventProcessorHost(hostName, eventHubPath, consumerGroupName, 
    eventHubConnectionString, storageConnectionString, leaseContainerName); 
//Call something like this when you want it to start 
host.RegisterEventProcessorFactoryAsync(factory) 

Avrete notato che ho detto Azure di fare un nuovo gruppo di consumatori, se non esiste, si otterrà un messaggio di errore bello se non è così. Sinceramente non so quale sia lo scopo di questo perché non include la stringa di connessione Storage che deve essere uguale a tra le diverse istanze in modo che il coordinamento di EventProcessorHost (e presumibilmente il commit) funzioni correttamente.

Qui ho fornito una foto da Azure Storage Explorer di contratti di locazione e presumibilmente compensazioni da un gruppo di consumatori che stavo sperimentando a novembre. Si noti che mentre ho un testhub e un contenitore testhub-testcg, ciò è dovuto alla loro denominazione manuale. Se fossero nello stesso contenitore sarebbero cose come "$ Default/0" vs "testcg/0".

Come si può vedere c'è un blob per partizione. La mia ipotesi è che questi BLOB vengano usati per due cose. Il primo di questi è il leasing Blob per la distribuzione di partizioni tra le istanze, vedere here, il secondo è la memorizzazione degli offset all'interno della partizione che è stata commessa.

Piuttosto che i dati che vengono inviati ai gruppi di consumatori, le istanze consumatrici chiedono al sistema di archiviazione dati per alcuni offset in una partizione. EventProcessorHosts sono un ottimo modo di avere un gruppo di consumatori logici in cui ogni partizione viene letta da un solo utente alla volta e in cui non viene dimenticato lo stato di avanzamento del gruppo di consumatori logici in ciascuna partizione.

Ricordare che il throughput per partizione viene misurato in modo tale che se si sta esaurendo l'ingresso è possibile avere solo due utenti logici che sono tutti alla velocità. Come tale vorrai assicurarti di avere abbastanza partizioni e unità di throughput, che puoi:

1. Leggi tutti i dati che invii.
2. Raccogliere entro il periodo di conservazione di 24 ore se si rimane indietro per alcune ore a causa di problemi.

In conclusione: i gruppi di consumatori sono ciò di cui hai bisogno. Gli esempi che si leggono che utilizzano uno specifico gruppo di consumatori sono validi, all'interno di ciascun gruppo di consumatori logici utilizzano lo stesso nome per il gruppo di consumatori di Azure e hanno gruppi di consumatori logici diversi che ne utilizzano diversi.

Non ho ancora utilizzato Azure Stream Analytics, ma almeno durante la versione di anteprima si è limited to the default consumer group. Quindi, non utilizzare il gruppo di consumatori predefinito per qualcos'altro e, se hai bisogno di due lotti separati di analisi di flusso di Azure, potresti dover fare qualcosa di brutto. Ma è facile da configurare!