Версия сайта для слабовидящих
24 января 2022 года вышел новый релиз Apache Kafka. Главные новинки самой последней на сегодня стабильной версии 3.1.0: добавленные фичи, улучшения и исправленные баги краткий обзор для разработчиков распределенных приложений Kafka Streams и администраторов кластера этой платформы потоковой передачи событий.
Новинки Apache Kafka 3.1.0 для администратора кластера
В свежем релизе Apache Kafka 3.1.0 добавлена всего одна новая фича, но также внесены более 30 улучшений и исправлены почти 50 ошибок. Сперва рассмотрим, новинки, наиболее важные для администратора кластера. Теперь Apache Kafka поддерживает Java 17. Также добавлены дополнительные конфигурации для управления соглашением об именах внутренних топиков MirrorMaker2, которые ранее были жестко закодированы в исходном коде: heartbeats, контрольные точки и синхронизация смещения.
Это затрудняло запуск утилиты MirrorMaker2 для зеркального копирования данных с помощью группы потребителей, которые читают из выбранного набора топиков в кластере Kafka, где не разрешено автоматическое создание топиков. Ранее нужно было заранее создавать эти внутренние топики вручную согласно правилам кластера Kafka. В релизе 3.1.0 добавлены методы ReplicationPolicy, которые определяют, как именуются внутренние топики MirrorMaker2 на основе некоторой новой конфигурации.
В релиз вошли две новые метрики от контроллеров ZooKeeper и KRaft: ActiveBrokerCount и FencedBrokerCount. Они соответственно отображают количество активных и изолированных брокеров, известных контроллеру.
Исправлена несогласованность в названиях метрик измерения задержек на клиенте в мили- и нано-секундах. В частности, метрики bufferpool-wait-time-total, io-waittime-total и iotime-total объявлены устаревшими и вместо них в новом релизе Kafka 3.1.0 с теми же значениями используются bufferpool-wait-time-ns-total, io-wait-time-ns-total и io-time-ns-total соответственно.
Далее подробно рассмотрим добавленную новую фичу – расширение SASL/OAUTHBEARER с поддержкой OIDC.
Аутентификация и авторизация с OAuth/OIDC
Эта фича вызвана востребованностью OAuth/OIDC для авторизации и аутентификации интернет-сервисов. OAuth/OIDC позволит любому пользователю Apache Kafka настроить готовую конфигурацию для подключения к службе внешнего провайдера удостоверений: Okta, Auth0, Azure и пр. Код реализует стандартный тип предоставления клиентских учетных данных OAuth. Использование стандартного набора технологий позволяет организациям выбирать провайдеров, совместимых с OAuth/OIDC, вместо самостоятельного определения, разработки и управления инфраструктурой идентификации, безопасности и политик. Можно общаться с провайдерами по стандартным протоколам, определенные в RFC, используя код, написанный для зрелых open-source библиотек на популярных языках программирования. Новая фича Apache Kafka 3.1.0 — расширение SASL/OAUTHBEARER с поддержкой OIDC, т.е. аутентификация OAuth через SASL/OAUTHBEARER, позволяет интегрироваться с провайдерами, совместимыми с OAuth. Теперь клиенты Kafka могут передавать токен доступа JWT брокеру при инициализации соединения в качестве средства аутентификации. Таким образом, Kafka может использовать эти стандарты для авторизации и аутентификации.
Однако, OAuth 2 — это гибкая структура с несколькими способами выполнения одних и тех же действий, по-своему реализуемая разными провайдерами. Поэтому из-за гибкости OAuth, организационных требований и незначительных различий в реализации провайдера точные средства и логика извлечения и валидации маркер доступа JWT, могут различаться в каждом конкретном случае. Обобщенная стандартная реализация OAuth специально не была включена в KIP-255 для Apache Kafka, чтобы не дублировать функциональные возможности уже существующих open-source библиотек. Кроме того, вместо определения конкретной зависимости библиотеки JWT/JWS/JWE, целесообразнее позволить пользователям Kafka использовать тот вариант, который им больше всего подходит.
Реализация KIP-255 предоставила конкретный пример реализации, которая позволяла клиентам предоставлять незащищенный токен доступа JWT брокеру при инициализации соединения только в рамках разработки. Производственное применение этой фичи потребует реализации AuthenticateCallbackHandler, которая может обрабатывать экземпляр OAuthBearerTokenCallback. Таким образом, точная реализация остается на усмотрение пользователя. Впрочем, сообщество предоставило несколько реализаций Java с открытым исходным кодом, которые можно включить в путь к классам клиента Kafka с поддержкой OAuth и нужным образом настроить.
Фича не вносит никаких изменений в общедоступном интерфейсе, используется существующий API AuthenticateCallbackHandler. Изменение состоит из пары реализаций AuthenticateCallbackHandler: одной для входа в систему на клиенте и одной для проверки на брокере. Как это работает, показано ниже на UML-диаграмме последовательности.
Изменения в Kafka Streams
С точки зрения разработчика наиболее значимыми можно назвать следующие улучшения и исправления ошибок в Kafka Streams. В частности, протокол быстрой перебалансировки EAGER, по умолчанию используемый с Kafka 2.4, объявлен устаревшим. Его поддержка будет прекращена в будущем выпуске, поэтому пользователям следует подготовиться к завершению обновления своих приложений до кооперативного протокола в версии 3.1, о чем мы расскажем завтра. Добавлено поле TaskId в StreamsException, которое устанавливается для любого исключения, которое происходит из конкретной задачи или связано с ней. Это позволит упаковывать любое исключение, возникшее во время обработки и переданное обработчику необработанных исключений, (новый StreamsUncaughtExceptionHandler или старый общий UncaughtExceptionHandler), как StreamsException. В рамках реализации добавлен новый API в класс StreamsException, чтобы раскрыть TaskId.
Добавлены пользовательские разделители в соединениях по внешнему ключу (FK), которые ранее в Kafka Streams работали только, если обе соединяемые таблицы используют разделитель по умолчанию. Это ограничение обусловлено тем, что топики подписки и ответа в реализации жестко привязаны к использованию разделителя по умолчанию. Если таблица внешнего ключа не партиционирована вместе с топиком подписки, поиск по внешнему ключу может быть перенаправлен на экземпляр Streams, у которого нет состояния для таблицы внешнего ключа, что приводило к отсутствию записей соединения. Аналогично, если первичная таблица не разделена совместно с топиком ответа, то ответы на подписку перенаправлялись на экземпляр, который не содержит исходной (инициирующей) записи, что приводило к неудачному сравнению хэша и отброшенному результату соединения. В новом релизе поддерживаются соединения по внешнему ключу для таблиц с пользовательскими разделителями через расширение интерфейса FK-соединений. Пользовательские разделители передаются как часть нового объекта TableJoined, аналогичного существующим объектам Joined и StreamJoined. TableJoined содержит оба разделителя и реализует NamedOperation. Прежние методы FK-соединения, которые принимают Named в качестве параметра, объявлены устаревшими и заменены новыми версиями, которые вместо этого принимают TableJoined. Для этого добавлены новые интерфейсы KTable, аналогичные существующим методам с Named, которые будут удалены в следующем мажорном релизе.
Apache Kafka для инженеров данных
Код курса
DEVKI
Ближайшая дата курса
27 мая, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Расширена семантика существующих интерфейсов ReadOnlySessionStore и ReadOnlyWindowStore с открытыми конечными точками для поддержки неограниченных диапазонов. Они теперь поддерживают использование нулевых значений как способ представления неограниченных диапазонов.
Добавлена новая метрика общего времени блокировки, которая измеряет общее время, в течение которого поток Kafka Streams был заблокирован в Kafka с момента его запуска. Пользователи могут периодически делать выборки значений этой метрики, что пригодится для отладки производительности приложения Kafka Streams. Например, чтобы сравнить долю времени, в течение которого приложение было заблокировано в Kafka, по сравнению с временем непосредственной обработки записей.
Как безболезненно обновиться до версии 3.1 и избежать возможных побочных эффектов, связанных с некоторыми архитектурными изменениями платформы, читайте в нашей следующей статье.
Все подробности по администрированию и использованию Apache Kafka для потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков больших данных в Москве:
Источники
