Узлы событий Azure и несколько групп потребителей

Question

Нужна помощь по использованию концентраторов событий Azure в следующем сценарии. Я думаю, что потребительские группы могут быть подходящим вариантом для этого сценария, но я не смог найти конкретный пример в Интернете.

Вот грубое описание проблемы и предлагаемое решение с использованием концентраторов событий (Я не уверен, если это оптимальное решение. Будет ли оценят ваше мнение)

У меня есть несколько источников событий, которые генерируют большое количество данных о событиях (данные телеметрии от датчиков), которые необходимо сохранить в нашей базе данных, и некоторый анализ, такой как средний, min-max, должен быть выполнен в параллельно.

Отправитель может отправлять данные только на одну конечную точку, но концентратор событий должен предоставлять эти данные обоим обработчикам данных.

Я думаю об использовании двух групп потребителей, сначала это будет кластер экземпляров рабочей роли, которые позаботятся о сохранении данных в нашем хранилище ключей, а вторая группа потребителей будет механизмом анализа (вероятно, с анализом Azure Stream).

Во-первых, как настроить группы потребителей и есть ли что-то, что мне нужно сделать на стороне отправителя/получателя, чтобы копии событий отображались во всех группах потребителей?

Я читал много примеров в Интернете, но они либо используют client.GetDefaultConsumerGroup();, и/или имеют все разделы, обработанные несколькими экземплярами одной и той же рабочей роли.

Для моего сценария, когда событие срабатывает, она должна быть обработана двумя различными ролями рабочих параллельно (тот, который сохраняет данные и второй, который делает некоторый анализ)

спасибо!

Answer 1

TLDR: Выглядит разумно, просто создайте две группы потребителей, используя разные имена с помощью CreateConsumerGroupIfNotExists.

Группы потребителей - это, прежде всего, концепция, так что точно, как они работают, зависит от того, как реализованы ваши подписчики. Как вы знаете, концептуально они представляют собой группу подписчиков, работающих вместе, чтобы каждая группа получала все сообщения и при идеальных (не будет) обстоятельствах, вероятно, каждый раз потребляет каждое сообщение. Это означает, что каждая группа потребителей будет «все разделы обрабатываются несколькими экземплярами одной и той же роли». Вы хотите это.

Это может быть реализовано по-разному. Microsoft предоставила два способа напрямую использовать сообщения от концентраторов событий, а также возможность использовать такие вещи, как Streaming Analytics, которые, вероятно, построены поверх двух прямых способов. Первый способ - Event Hub Receiver, второй - более высокий уровень - Event Processor Host.

Я не использовал Event Hub Receiver прямо так этот конкретный комментарий основан на теории о том, как эти виды систем работают и домыслы из документации: В то время как они created от EventHubConsumerGroups это служит небольшой цели, как эти приемники не согласовывают с одной другой. Если вы их используете, вам понадобится (и может!) Выполнить всю координацию и совершить смещения самостоятельно, что имеет преимущества в некоторых сценариях, таких как запись смещения в транзакционную БД в ту же транзакцию, что и вычисленные агрегаты.Использование этих low level receivers, имеющих разные логические группы потребителей, использующих одну и ту же группу потребителей Azure, вероятно, не должно быть (нормативные, а не практические рекомендации), особенно проблематичными, но вы должны использовать разные имена, если это имеет значение, или вы переходите на EventProcessorHosts.

Теперь на более полезную информацию, EventProcessorHosts, вероятно, построены сверху EventHubReceivers. Они являются более высокоуровневыми, и есть поддержка, позволяющая нескольким машинам работать вместе как логическая группа потребителей. Ниже я включил слегка отредактированный фрагмент кода, который делает EventProcessorHost с кучей комментариев, оставшихся в объяснении некоторых вариантов.

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

Вы заметите, что я сказал Azure, чтобы сделать новую группу потребителей, если она не существует, вы получите сообщение об ошибке, если прекрасном нет. Я, честно говоря, не знаю, в чем цель этого, потому что она не включает в себя строку подключения к хранилищу, которая нуждается в, чтобы она была одинаковой для всех экземпляров, чтобы координация EventProcessorHost (и, предположительно, фиксация) работала должным образом.

Здесь я предоставил картинку от Azure Storage Explorer аренды лизинга и предположительно смещения из группы потребителей, с которой я экспериментировал в ноябре. Обратите внимание, что хотя у меня есть testhub и testhub-testcg, это связано с тем, что их вручную называет. Если бы они были в одном контейнере, это были бы такие вещи, как «$ Default/0» и «testcg/0».

Как вы можете видеть, на каждый раздел есть один блок. Мое предположение состоит в том, что эти капли используются для двух вещей. Первый из них - аренда Blob для распределения разделов между экземплярами, см. here, вторая - сохранение смещений внутри раздела, который был зафиксирован.

Вместо того, чтобы данные попадали в группы потребителей, экземпляры-потребители запрашивают у системы хранения данные с некоторым смещением в одном разделе. EventProcessorHosts - хороший способ высокого уровня наличия логической группы потребителей, в которой каждый раздел считывается только одним пользователем за раз, и когда прогресс, который логическая группа потребителей сделал в каждом разделе, не забывается.

Помните, что пропускная способность каждой секции измеряется так, что если вы достигнете максимального выходного сигнала, у вас могут быть только два логических потребителя, все из которых имеют скорость. Таким образом, вы захотите убедиться, что у вас достаточно перегородок и пропускных единиц, которые вы можете:

1. Прочитать все данные, которые вы отправляете.
2. Займитесь в течение 24-часового периода хранения, если вы отстаете на несколько часов из-за проблем.

В заключение: группы потребителей - это то, что вам нужно. Примеры, которые вы читаете, которые используют определенную группу потребителей, хороши, в каждой логической группе потребителей используются одно и то же имя для Azure Consumer Group и разные логические группы потребителей используют разные.

Я еще не использовал Azure Stream Analytics, но, по крайней мере, во время предварительного просмотра вы являетесь limited to the default consumer group. Поэтому не используйте группу потребителей по умолчанию для чего-то еще, и если вам нужны две отдельные партии Azure Stream Analytics, вам может понадобиться сделать что-то неприятное. Но его легко настроить!