Использование Центры событий Azure для потоковой передачи данных из приложений Apache Kafka

В этой статье объясняется, как использовать Центры событий Azure для потоковой передачи данных из приложений Apache Kafka без самостоятельной настройки кластера Kafka.

Обзор

Центры событий Azure предоставляет конечную точку Apache Kafka в концентраторе событий, которая позволяет пользователям подключаться к концентратору событий по протоколу Kafka. Конечную точку Kafka концентратора событий часто можно использовать из приложений без каких-либо изменений в коде. Вы изменяете только конфигурацию, то есть обновляете строку подключения в конфигурациях, чтобы она указывала на конечную точку Kafka, предоставленную концентратором событий, а не на кластер Kafka. Затем можно запустить потоковую передачу событий из приложений, использующих протокол Kafka, в центры событий, которые эквивалентны разделам Kafka.

Примечание

Центры событий для экосистем Kafka поддерживают Apache Kafka версии 1.0 и более поздних версий.

Сопоставление концепций Apache Kafka и Центра событий Azure

По сути, Kafka и Центры событий очень похожи. Это секционированные журналы, созданные для потоковой передачи данных, при этом клиент определяет, какую часть сохраненного журнала он хочет прочитать. В следующей таблице показано составление понятий Kafka и Центров событий.

Понятия Kafka Понятия Центров событий
Кластер Пространство имен
Раздел Центр событий
Partition (Раздел) Partition (Раздел)
Группа потребителей Группа потребителей
Offset Offset

Основные различия между Apache Kafka и Центры событий Azure

Хотя Apache Kafka — это программное обеспечение, которое обычно требуется установить и затем начать с ним работу, концентраторы событий — это полностью управляемая облачная служба. Вам не нужно вести мониторинг и управлять серверами, дисками, или сетями и задумываться над использованием или настройкой брокеров — эти компоненты просто отсутствуют. Создайте пространство имен, которое является конечной точкой с полным доменным именем, а затем создайте концентраторы событий (разделы) в этом пространстве имен.

Дополнительные сведения о Центрах событий и пространствах имен см. в статье Особенности Центров событий. Выступая в качестве облачной службы, концентраторы событий используют один стабильный виртуальный IP-адрес в качестве конечной точки, поэтому клиентам не нужно знать о брокерах или машинах в кластере. Хотя концентраторы событий реализуют один и тот же протокол, разница заключается в том, что весь трафик Kafka для всех секций прогнозируется через эту конечную точку и не требует доступа к брандмауэру для всех брокеров кластера.

Масштабирование в Центрах событий определяется количеством приобретенных единиц пропускной способности (TU) или единиц обработки. При включении функции автоматического расширения для пространства имен стандартного уровня Центры событий при достижении предельной пропускной способности автоматически выполняют вертикальное увеличение масштаба единиц пропускной способности. Эта функция также работает с поддержкой протокола Apache Kafka. Для пространства имен уровня Premier можно увеличивать число единиц обработки, назначенных пространству имен.

Apache Kafka — верное решение для вашей рабочей нагрузки?

Тем, кто прежде занимался созданием приложений с помощью Apache Kafka, также будет полезно узнать, что Центры событий Azure являются частью парка служб, которые также включают в себя Служебную шину Azure и службу Сетка событий Azure.

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

Сведения о различиях между шаблонами и тем, какой шаблон лучше подойдет для конкретной службы, см. в руководстве по использованию параметров асинхронного обмена сообщениями в Azure. Как пользователь Apache Kafka вы можете обнаружить, что пути взаимодействия, которые вы уже настроили с Kafka, могли быть реализованы куда проще и наделены еще более мощными возможностями с помощью службы "Сетка событий" или "Служебная шина".

Если вам нужны специальные функции Apache Kafka, которые недоступны в концентраторах событий для интерфейса Apache Kafka, или если шаблон реализации превышает квоты Центров событий, можно также запустить собственный кластер Apache Kafka в Azure HDInsight.

Безопасность и проверка подлинности

Каждый раз при публикации или использовании событий из концентраторов событий для Kafka клиент пытается получить доступ к ресурсам концентраторов событий. Необходимо обеспечить доступ к ресурсам с помощью полномочной сущности. При использовании протокола Apache Kafka с клиентами можно настроить конфигурацию для проверки подлинности и шифрования с помощью механизмов SASL. При использовании Центров событий для Kafka требуется TLS-шифрование (так как все данные в транзите с Центрами событий шифруются с помощью TLS), это можно сделать, указав параметр SASL_SSL в файле конфигурации.

Концентраторы событий Azure предоставляют несколько вариантов авторизации доступа к защищенным ресурсам.

  • OAuth 2.0
  • Подписанный URL-адрес (SAS)

OAuth 2.0

Концентраторы событий интегрируются со службой Azure Active Directory (Azure AD), которая предоставляет сервер централизованной авторизации, совместимый с OAuth 2.0. С помощью Azure AD вы можете использовать управление доступом на основе ролей Azure (Azure RBAC), чтобы предоставить точные разрешения для удостоверений клиентов. Эту функцию можно использовать с клиентами Kafka, указав SASL_SSL в качестве протокола и OAUTHBEARER в качестве механизма. Дополнительные сведения о ролях и уровнях Azure для доступа к области см. в статье Авторизация доступа с помощью Azure AD.

bootstrap.servers=NAMESPACENAME.servicebus.windows.net:9093
security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;
sasl.login.callback.handler.class=CustomAuthenticateCallbackHandler

Примечание

Приведенные выше свойства конфигурации предназначены для языка программирования Java. Примеры использования OAuth с Центрами событий для Kafka на разных языках программирования см. на сайте GitHub.

Подписанный URL-адрес

Концентраторы событий также предоставляют подписанные URL-адреса (SAS) для делегированного доступа к концентраторам событий для ресурсов Kafka. Авторизация доступа с помощью механизма на основе токенов OAuth 2.0 обеспечивает более высокую безопасность и простоту использования по сравнению с SAS. Встроенные роли также могут устранить необходимость авторизации на основе списков ACL, которые должны поддерживаться и управляться пользователем. Эту функцию можно использовать с клиентами Kafka, указав SASL_SSL в качестве протокола и PLAIN в качестве механизма.

bootstrap.servers=NAMESPACENAME.servicebus.windows.net:9093
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="{YOUR.EVENTHUBS.CONNECTION.STRING}";

Важно!

Замените {YOUR.EVENTHUBS.CONNECTION.STRING} строками подключения для вашего пространства имен Центров событий. Инструкции по получению строки подключения см. в статье Получение строки подключения Центров событий. Пример конфигурации см. здесь: sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="Endpoint=sb://mynamespace.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=XXXXXXXXXXXXXXXX";

Примечание

При использовании проверки подлинности SAS с клиентами Kafka установленные подключения не отключаются при повторном формировании ключа SAS.

Примечание

Созданные маркеры подписанных URL-адресов не поддерживаются при использовании Центров событий для конечной точки Apache Kafka.

Примеры

Пошаговые инструкции по созданию концентратора событий и доступу к нему с помощью SAS или OAuth см. в статье Краткое руководство: потоковая передача данных с концентраторами событий с помощью протокола Kafka.

Другие функции Центры событий Azure

Функция "Концентраторы событий для Apache Kafka" — это один из трех протоколов, параллельно доступных в концентраторах событий Azure, в дополнение к HTTP и AMQP. Вы можете осуществлять запись в одном из этих протоколов и чтение — в другом, чтобы текущие поставщики Apache Kafka могли продолжить публикацию с помощью Apache Kafka, но приложение-читатель могло воспользоваться преимуществами встроенной интеграции с интерфейсом AMQP Центра событий, например "Azure Stream Analytics" или "Функции Azure". И наоборот: вы можете легко интегрировать Центры событий Azure в сети маршрутизации AMQP в качестве целевой конечной точки, и в то же время считывать данные, используя средства интеграции Apache Kafka.

Кроме того, такие функции Центров событий, как Сбор, позволяют очень экономично выполнять долгосрочную архивацию с помощью хранилища BLOB-объектов Azure и Azure Data Lake Storage, а геоаварийное восстановление также работает с функцией "Центры событий для Kafka".

Идемпотентность

Центры событий Azure для Apache Kafka поддерживает как идемпотентных производителей, так и идемпотентных потребителей.

Одним из основных принципов Центры событий Azure является концепция доставки по крайней мере один раз. Такой подход гарантирует, что события всегда будут доставляться. Это также означает, что потребители, такие как функция, могут получать события несколько раз, даже несколько раз. По этой причине важно, чтобы потребитель поддерживал шаблон идемпотентного потребителя .

Различия функций в Apache Kafka

Цель Центров событий для Apache Kafka — предоставить доступ к Центры событий Azure возможностям для приложений, которые заблокированы в API Apache Kafka и в противном случае должны быть обеспечены кластером Apache Kafka.

Как упоминалось выше, парк обмена сообщениями Azure предоставляет широкие возможности для разнообразных ситуаций обмена сообщениями, и, хотя в настоящее время следующие функции в службе поддержки Центров событий для API Apache Kafka не поддерживаются, мы указали, где и каким образом сможет быть доступна нужная возможность.

Transactions

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

Сжатие

Функция Сжатие на стороне клиента Apache Kafka сжимает пакет нескольких сообщений в одно сообщение на стороне производителя и распаковывает пакет на стороне потребителя. Брокер Apache Kafka обрабатывает пакет как специальное сообщение.

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

Полезные данные любого события Центров событий являются потоком байтов, и содержимое можно сжать с помощью выбранного алгоритма. Формат кодирования Apache Avro поддерживает сжатие нативно.

потоки Kafka.

Потоки Kafka — это клиентская библиотека для Stream Analytics, которая является частью проекта Apache Kafka с открытым исходным кодом, но отделена от брокера потока событий Apache Kafka.

Наиболее распространенная причина, по которой клиенты Центров событий Azure запрашивают поддержку потоков Kafka, заключается в том, что они заинтересованы в продукте "ksqlDB" от Confluent. ksqlDB — это частный проект с общим исходным кодом, который лицензируется таким образом, что ни один из поставщиков SAAS, PAAS, IAAS или других аналогичных веб-служб, которые конкурируют с продуктами или службами Confluent, не может использовать или предлагать поддержку ksqlDB. Практически, если вы используете ksqlDB, необходимо работать либо с Kafka непосредственно, либо использовать облачные предложения Confluent. Условия лицензионного соглашения также могут повлиять на клиентов Azure, предлагающих услуги для цели, исключенной из лицензии.

Автономно и без ksqlDB, потоки Kafka имеют меньше возможностей, чем многие альтернативные платформы и службы, которые интегрируются с концентраторами событий Azure сегодня и большинство из которых имеют встроенные потоковые интерфейсы SQL.

Перечисленные службы и платформы обычно могут получать потоки событий и эталонные данные непосредственно из различных наборов источников через адаптеры. Потоки Kafka могут получать данные только из Apache Kafka, в силу чего и проекты аналитики ограничены использованием Apache Kafka. Чтобы использовать данные из других источников, необходимо сначала импортировать данные в Apache Kafka с помощью платформы Kafka Connect Framework.

Если вы вынуждены использовать платформу Kafka Streams в Azure, Apache Kafka в HDInsight предоставит этот вариант. Apache Kafka в HDInsight предоставляет полный контроль над всеми аспектами настройки Apache Kafka, в то время как сохраняется полная интеграция с различными аспектами платформы Azure — от размещения в домен сбоя/обновления до сетевой изоляции и мониторинга интеграции.

Дальнейшие действия

В этой статье приведены ознакомительные сведения о Центрах событий для компонента Kafka. См. сведения в руководстве для разработчиков Apache Kafka по Центрам событий Azure.

Пошаговые инструкции по созданию концентратора событий и доступу к нему с помощью SAS или OAuth см. в статье Краткое руководство: потоковая передача данных с концентраторами событий с помощью протокола Kafka.

Кроме того, ознакомьтесь с примерами OAuth на сайте GitHub.