Вопрос или проблема
Я использую Event Hubs для брокерства событий, публикуемых из системы, использующей нативный клиент C# для Event Hubs. Кроме того, я использую клиент Kafka в Databricks для публикации событий в тот же хаб. Порядок важен, поэтому я использую ключ раздела, чтобы обеспечить совместное расположение связанных событий.
Однако я заметил, что вычисленный раздел ключа отличается между клиентами. Я понимаю, что разделение Event Hubs по ключу вычисляется внутри хаба и абстрагировано от клиента. Клиент Kafka, похоже, использует MurmurHash для вычисления разделения внутри клиента. Поэтому результаты для одного и того же ключа отличаются в разных процессах.
Существует ли способ заставить клиент Kafka перенести разделение на Event Hubs, чтобы получить тот же результат, что и интерфейс нативного Event Hubs?
Разделы всегда вычисляются / предоставляются на стороне клиента, согласно сетевому протоколу Kafka.
Клиент Confluent dotnet основан на librdkafka, которая не по умолчанию использует хэш murmur2. Она использует CRC32. Посмотрите на конфигурацию partitioner – https://docs.confluent.io/platform/current/clients/librdkafka/html/md_CONFIGURATION.html
Ответ или решение
Выбор Разделов для Event Hubs с Использованием Клиентов Kafka и Native Event Hub
Когда речь заходит о бронировании событий с помощью Azure Event Hubs, особенно в контексте смешанного использования клиентов, таких как нативный клиент C# и Kafka-клиент в Databricks, важно учитывать несколько критических аспектов, особенно когда речь идет об обеспечении порядка обработки событий.
Проблема Разделения
Как вы правильно отметили, принципиальной проблемой является различие в вычислении разделов для одноименных ключей в разных клиентах. В то время как нативный клиент Event Hubs полагается на внутреннюю логику для назначения разделов в зависимости от ключа, клиент Kafka, как правило, использует алгоритм хеширования для выполнения этой задачи. Важным моментом здесь является то, что различия в алгоритмах могут привести к расхождениям в назначении разделов, что крайне нежелательно для сценариев с критичным порядком обработки событий.
Принцип Работы Разделов
Разделы в Kafka и Event Hubs рассчитываются на стороне клиента. Этот принцип является частью протокола работы Kafka. Это значит, что даже незначительная разница в алгоритме хеширования может привести к тому, что одно и то же событие, отправленное из разных источников, будет помещено в разные разделы. В то время как нативный клиент Event Hubs использует свои собственные алгоритмы, сами клиенты Kafka могут по умолчанию применять другие алгоритмы, такие какCRC32, что только усугубляет проблему.
Возможные Решения
-
Стандартизация Хеширования: Один из вариантов – разрабатывать heshing-алгоритм для клиента Kafka, который точно соответствует логике нативного Event Hub. Для этого вам может понадобиться создать пользовательский партиционер, который будет использовать те же правила, что и нативный клиент, что обеспечит единообразие назначения разделов.
-
Параметры Конфигурации: Если вы используете библиотеку Confluent, проверьте параметры конфигурации, связанные с партиционированием. Возможно, вы сможете задать партиционер, который использует тот же алгоритм, как и у нативного клиента.
-
Логика Обработки на Уровне Приложения: Если разработка пользовательского партиционера не является идеальным решением, можно также рассмотреть возможность обработки событий на уровне приложения. Это может включать в себя сбор всех событий в одном месте и последующую отправку через одного клиента, что устранит проблему различных партиционирующих логик.
-
Использование Списков Задач: Если у вас нет возможности изменить клиента, можно рассмотреть возможность встраивания механизма, который будет контролировать, какие ключи обрабатываются каким клиентом, что позволит минимизировать конфликты различных партиционирований.
Заключение: При использовании Azure Event Hubs для передачи событий из смешанных источников необходимость обеспечения порядка событий критически важна. Понимание различий в механизмах партиционирования поможет вам принять взвешенное решение для оптимизации обработки событий. Выбор подходящего решения зависит от инфраструктурных ограничений и ваших требований к упрощению обработки событий.