microsoft - panel azure login

Centros de eventos de Azure y varios grupos de consumidores

Question

Necesita ayuda para usar los centros de eventos de Azure en el siguiente escenario. Creo que los grupos de consumidores podrían ser la opción correcta para este escenario, pero no pude encontrar un ejemplo concreto en línea.

Aquí está la descripción aproximada del problema y la solución propuesta utilizando los centros de eventos ( no estoy seguro si esta es la solución óptima. Apreciaré sus comentarios )

Tengo múltiples fuentes de eventos que generan una gran cantidad de datos de eventos (datos de telemetría de los sensores) que deben guardarse en nuestra base de datos y algunos análisis como el promedio de ejecución, min-max se deben realizar en paralelo .

El remitente solo puede enviar datos a un único punto final, pero el centro de eventos debe hacer que estos datos estén disponibles para ambos manejadores de datos.

Estoy pensando en usar dos grupos de consumidores, el primero será un grupo de instancias de rol de trabajador que se encargará de guardar los datos en nuestro almacén de valores clave y el segundo grupo de consumidores será un motor de análisis (es probable que vaya con Azure Stream Analysis ).

En primer lugar, ¿cómo configuro los grupos de consumidores y hay algo que debo hacer en el lado del remitente / receptor para que aparezcan copias de los eventos en todos los grupos de consumidores?

Leí muchos ejemplos en línea, pero tampoco usan client.GetDefaultConsumerGroup(); y / o hacer que todas las particiones sean procesadas por varias instancias de un mismo rol de trabajador.

Para mi escenario, cuando se desencadena un evento, debe ser procesado por dos roles de trabajador diferentes en paralelo (uno que guarda los datos y el segundo que hace un análisis)

¡Gracias!

Answer 1

TLDR: Parece razonable, solo haga dos grupos de consumidores usando nombres diferentes con CreateConsumerGroupIfNotExists.

Los grupos de consumidores son principalmente un concepto, por lo que exactamente cómo funcionan depende de cómo se implementan los suscriptores. Como saben, conceptualmente son un grupo de suscriptores que trabajan juntos para que cada grupo reciba todos los mensajes y, en circunstancias ideales (no sucederán), probablemente consuma cada mensaje una vez. Esto significa que cada Grupo de consumidores "tendrá todas las particiones procesadas por varias instancias del mismo rol de trabajador". Tu quieres esto.

Esto se puede implementar de diferentes maneras. Microsoft ha proporcionado dos formas de consumir mensajes directamente desde los Centros de Eventos, más la opción de usar Streaming Analytics, que probablemente se construyen sobre las dos formas directas. La primera forma es el Event Hub Receiver , la segunda que es un nivel más alto es el Host del procesador de eventos .

No he usado Event Hub Receiver directamente, por lo que este comentario en particular se basa en la teoría de cómo funcionan estos tipos de sistemas y la especulación de la documentación: aunque se created partir de EventHubConsumerGroups esto no sirve para nada ya que estos receptores no se coordinan entre sí. Si usa estos, necesitará (y puede) hacer toda la coordinación y el compromiso de las compensaciones usted mismo, lo que tiene ventajas en algunos escenarios, como escribir la compensación en un DB transaccional en la misma transacción que los agregados calculados. El uso de estos receptores de bajo nivel , el hecho de que diferentes grupos de consumidores lógicos utilicen el mismo grupo de consumidores de Azure probablemente no debería (consejos normativos, no prácticos) ser particularmente problemáticos, pero debe usar nombres diferentes en caso de que sea importante o cambie a EventProcessorHosts .

Ahora, en información más útil, EventProcessorHosts probablemente se construye sobre EventHubReceivers . Son una cosa de nivel superior y hay soporte para permitir que varias máquinas trabajen juntas como un grupo de consumidores lógico. A continuación, he incluido un fragmento de código ligeramente editado de mi código que crea un EventProcessorHost con un montón de comentarios para explicar algunas opciones.

//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)

Notará que le dije a Azure que creara un nuevo Grupo de consumidores si no existe, si no es así, recibirá un mensaje de error encantador. Honestamente, no sé cuál es el propósito de esto porque no incluye la cadena de conexión de almacenamiento que debe ser la misma en todas las instancias para que la coordinación del EventProcessorHost (y presumiblemente se comprometa) funcione correctamente.

Aquí proporcioné una imagen de Azure Storage Explorer de los contratos de arrendamiento y presumiblemente compensaciones de un grupo de consumidores con el que estaba experimentando en noviembre. Tenga en cuenta que si bien tengo un testhub y un contenedor testhub-testcg, esto se debe a nombrarlos manualmente. Si estuvieran en el mismo contenedor, serían cosas como "$ Default / 0" vs "testcg / 0".

Como puedes ver hay un blob por partición. Mi suposición es que estas manchas se utilizan para dos cosas. El primero de ellos es el arrendamiento de Blob para distribuir particiones entre las instancias que se muestran here , el segundo es el almacenamiento de las compensaciones dentro de la partición que se han confirmado.

En lugar de que los datos se envíen a los Grupos de consumidores, las instancias que consumen piden datos al sistema de almacenamiento en algún desplazamiento en una partición. EventProcessorHosts es una buena forma de tener un grupo de consumidores lógicos en el que cada partición solo está siendo leída por un consumidor a la vez, y el progreso que el grupo de consumidores lógicos ha hecho en cada partición no se olvida.

Recuerde que el rendimiento por partición se mide de modo que si está aprovechando al máximo el ingreso solo puede tener dos consumidores lógicos que estén al día. Como tal, querrá asegurarse de tener suficientes particiones y unidades de rendimiento que pueda:

1. Lee todos los datos que envíes.
2. Póngase al día dentro del período de retención de 24 horas si se retrasa por algunas horas debido a problemas.

En conclusión: los grupos de consumidores son lo que necesitas. Los ejemplos que lee que usan un grupo de consumidores específico son buenos, dentro de cada grupo de consumidores lógicos use el mismo nombre para el Grupo de consumidores de Azure y haga que diferentes grupos de consumidores lógicos usen grupos diferentes.

Todavía no he usado Azure Stream Analytics, pero al menos durante la versión preliminar está limitado al grupo de consumidores predeterminado . Así que no use el grupo de consumidores predeterminado para otra cosa, y si necesita dos lotes separados de Azure Stream Analytics, es posible que deba hacer algo desagradable. ¡Pero es fácil de configurar!