KIP-500, который позволяет наконец-то избавиться от Zookeeper в кластере Apache Kafka, заменив его Quorum Controller – далеко не единственное важное обновление в релизе 2.8.0. Сегодня рассмотрим, какие еще улучшения реализованы в новой версии главной Big Data платформы потоковой обработки событий, выпущенной в апреле 2021 года.
Apache Kafka 2.8.0: новинки главных 18-ти KIP’ов
Замена Zookeeper самоуправляемым кворумом метаданных реализована не только в рамках широко известного KIP-500, но также отражена в следующих предлагаемых улучшениях Kafka (KIP, Kafka Improvement Proposal) [1]:
- KIP-595 – определяет протокол Raft для внутреннего топика @metadata, который содержит метаданные и конфигурации топиков вместо Zookeeper;
- KIP-631 – определяет управляемую событиями модель контроллера, включая новый жизненный цикл брокера и схемы записи метаданных;
- KIP-590 – определяет новый протокол, позволяющий пересылать клиентские запросы от брокеров к контроллеру.
Кроме этих KIP’ов для исключения Zookeeper из кластера Apache Kafka, новый релиз богат на улучшения разных компонентов платформы:
- 6 улучшений для брокеров, продюсеров и потребителей;
- 1 новая фича в Kafka Connect в рамках KIP-661;
- 7 добавлений в Kafka Streams.
Что именно представляет собой каждое из реализованных улучшений, мы рассмотрим далее.
Администрирование кластера Kafka
Код курса
KAFKA
Ближайшая дата курса
2 июля, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
6 KIP для брокеров, продюсеров и потребителей
Ключевые обновления Apache Kafka 2.8.0 включают следующие обновления относительно брокеров, прод.серов и потребителей сообщений [1]:
- KIP-700 – добавление API для описания кластера. Раньше, чтобы получить информацию о кластере, клиент администратора AdminClient Kafka использовал API метаданных брокера, который прежде всего ориентирован на поддержку клиентов (потребителя и производителя). Producer и Connsumer следуют другим шаблонам, чем AdminClient. KIP-700 отделяет AdminClient от API метаданных, позволяя администратору Kafka напрямую запрашивать у брокеров информацию о кластере без ущерба для производителя и потребителя. Подробнее о том, что такое AdminClient, когда его использовать и как, читайте в нашей новой статье. О другом новом API, полезном для администратора кластера, мы рассказываем здесь.
- KIP-684 — поддержка взаимной аутентификации TLS на слушателях SASL_SSL. Исторически Kafka отключала аутентификацию клиента TLS (mutual TLS authentication) для слушателей SASL_SSL, даже при настройке ssl.client.auth для всего брокера. Чаще всего, при использовании аутентификации SASL без необходимости распространения хранилища ключей, принудительная аутентификация клиента TLS для клиентов SASL_SSL нежелательна. Поэтому KIP-684 позволяет комбинировать аутентификацию TLS с идентификацией клиента на основе SASL для каждого слушателя. Это полезно для компаний со строгими правилами корпоративной безопасности, в частности, с обязательной взаимной проверкой подлинности TLS. KIP-684 основан на параметрах конфигурации с префиксом слушателя на базе решений из KIP-103, где предлагается разделение внешнего и внутреннего трафика [2].
- KIP-676 – иерархия ведения журналов. Библиотека логирования Java-программ Log4j использует иерархическую модель для настройки логирующих регистраторов в приложении. Уровни иерархии определяются разделяющими знаками в имени регистратора. Если отдельный регистратор не настроен явно, он наследует конфигурацию вышестоящего. Исторически сложилось так, что API-интерфейсы брокера Kafka для просмотра уровней журнала не соблюдали эту иерархию, сообщая только о конфигурации корневого регистратора для любого ненастроенного индивидуального регистратора. KIP-676 исправляет это, представляя конфигурации регистратора аналогично структуре ведения журнала.
- KIP-673 – создание JSON с новой автоматически сгенерированной схемой. Брокеры Kafka предлагают логи запросов/ответов на уровне отладки вместо полуструктурированных журналов, создаваемых переопределением toString классов запроса/ответа. KIP-673 настраивает логи, структурируя их в формате JSON, чтобы их было легче анализировать и использовать с помощью инструментальных средств ведения журналов.
- KIP-612 – ограничение скорости создания подключений к брокеру, чтобы повысить стабильность Big Data системы и уберечь ее от роста накладных расходов при множестве новых соединений, включая запросы от авторизованных клиентов. KIP-612 позволяет устанавливать ограничение на скорость, с которой брокер принимает новые соединения, как в целом, так и на отдельные IP-адреса.
- KIP-516 – идентификаторы топиков. Теперь в Apache Kafka8.0 топики определяются не только по названию, а на основании уникальных id, которые отличаются друг от друга на протяжении всего их существования. По сравнению с названиями топиков, идентификаторы более эффективны с точки зрения сетевой передачи и хранения в памяти. Клиенты могут получать идентификаторы топиков в ответах на запросы метаданных.
Улучшения Kafka Connect: отображение конфигураций задач в REST API с KIP-661
Kafka Connect предоставляет REST API, позволяющий вызывающим абонентам просматривать конфигурацию работающих коннекторов, чтобы определить их загруженность. В Apache Kafka Connect коннекторы обрабатывают конфигурацию до фактического начала выполнения, в некоторых случаях сопоставляя ее с каждой отдельной задачей, которая будет выполнять фактическую работу по передаче данных в Kafka или из нее. До релиза 2.8.0 можно было видеть номинальную конфигурацию, но не фактические разрешенные конфигурации, используемые отдельными запущенными задачами.
KIP-661 добавляет новую конечную точку API и метод tasksConfig(String connName, Callback<Map<ConnectorTaskId, Map<String, String>>> callback), позволяющий вызывающим абонентам получать фактическую конфигурацию времени выполнения задач соединителя.
Новая конечная точка Connect REST API: / {connector} / tasks-config, доступна через GET-запрос и возвращает конфигурацию всех задач для коннектора. Это полезно для разработчиков в режиме отладки и помогает администраторам Kafka-кластера понять, на что и в каком объеме влияет сбой отдельной задачи [3].
Завтра мы продолжим разбирать важные обновления релиза 2.8.0 и рассмотрим, какие KIP’ы делают Kafka Streams еще удобнее и эффективнее для потоковой обработки событий.
Apache Kafka для инженеров данных
Код курса
DEVKI
Ближайшая дата курса
2 июня, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Больше деталей об администрировании кластеров Apache Kafka и разработке распределенных приложений потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
