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
Ближайшая дата курса
9 декабря, 2024
Продолжительность
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
Ближайшая дата курса
20 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Больше деталей об администрировании кластеров Apache Kafka и разработке распределенных приложений потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
