15 июня 2023 года опубликован очередной выпуск самой популярной распределенной платформы потоковой передачи событий. Разбираемся с новинками Apache Kafka 3.5.0, особенно важными для разработчиков, дата-инженеров и администраторов кластера.
Обновления брокеров, контроллеров, продюсеров и потребителей
Релиз Apache Kafka 3.5.0 богат на новинки: в нем 50 улучшений и почти 80 исправленных ошибок. Тем не менее, возможность миграции кластеров Kafka в режим использования протокола KRaft вместо внешнего сервиса синхронизации метаданных Zookeeper согласно KIP-500, «на лету», т.е. без простоев, по-прежнему является функцией раннего доступа и пока подходит только для тестирования в непроизводственной среде. Перечислим самые важные изменения брокеров, контроллеров, продюсеров, потребителей и клиента администрирования:
- Обновлен API KRaft и инструмент kafka-storage.sh для поддержки механизма SCRAM для аутентификации между брокерами с помощью протокола KRaft, который должен заменить Zookeeper для кворум-серверов.
- Назначение разделов с поддержкой стойки для потребителей, чтобы повысить надежность и быстродействие кластера. Предыдущий выпуск 3.4.0 содержал только изменения протокола, обеспечивающего привязку потребителей к локальным зонам доступности с поддержкой назначения приложений-потребителей по разделам топика с учетом стойки в кластере. Кластеры Kafka часто распределяются по нескольким зонам доступности, особенно в облачных развертываниях. Реплики каждого раздела распределяются по разным зонам доступности, чтобы гарантировать, что зональный сбой не повлияет на доступность раздела. Локальность данных, когда потребители считывают сообщения из разделов в той же зоне доступности, повышает производительность системы. Если количество реплик меньше, чем количество зон доступности или стоек, некоторые разделы могут не иметь реплик в каких-то зонах доступности. Ранее потребителям, работающим в этих зонах доступности, приходилось получать данные от лидера в другой зоне доступности, что увеличивает задержку обработки данных из-за накладных расходов их передачи по сети. Поэтому в релизе 3.5.0 обновлены встроенные средства назначения разделов с учетом распределения данных по стойкам.
- В конфигурацию продюсера (ConfigProvider) добавлен новый класс EnvVarConfigProvider для извлечения настроек из переменных среды.
- Устранено ограничение протокола репликации между брокерами, которое может привести к потере данных в случае сбоя брокера в случае некорректной перезагрузки. Если брокер внезапно перезагрузился, но некоторые журналы не сбросились из кэша страниц, данные об этом брокере теряются. В большинстве случаев контроллер удаляет этого брокера из набора всех синхронизованных реплик (ISR, In-Sync Replica). Восстановившись после сбоя или перезагрузки, брокер сможет наверстать упущенное, т.е. реплицировать данные. Но если при этом произойдет сбой лидера одного из разделов, такой брокер может стать лидером и привести к потере данных. Поэтому в выпуск 3.5.0 внесено изменение в протокол репликации, чтобы лидер узнавал эпоху брокера из fetch-запроса подписчика, а не напрямую использовал метаданные брокера.
Изменения в Kafka Connect и Kafka Streams
Реализована полная поддержка распределенного режима в выделенных кластерах MirrorMaker 2.0, включая запуск нескольких экземпляров и обработку автоматических реконфигураций. Также добавлена поддержка семантики строго однократной доставки в MirrorSourceConnector. Улучшена поддержка смещений в Kafka Connect благодаря конечным точкам REST API для управления смещением коннекторов. Пока выпуск 3.5.0 содержит только конечные точки для перечисления смещений, а конечные точки для обновления и удаления смещений появятся в будущем выпуске. Добавлена возможность использовать incrementalAlterConfig для синхронизации конфигураций топика при его зеркалировании между кластерами.
В Kafka Streams внедрены следующие улучшения:
- Расширение ProductionExceptionHandler для охвата исключений сериализации: теперь метод handleSerializationException() добавлен в интерфейс ProductionExceptionHandler для обработки любых ошибок сериализации, возникающих при создании записей. О том, как обработать исключения, связанные с изменением формата или структуры данных, на стороне приложения-потребителя, мы недавно писали здесь. Интерфейс ProductionExceptionHandler обеспечивает настраиваемый обмен сообщениями об ошибке (например, отчет в пользовательскую систему метрик), если Kafka Streams не удается сериализовать сообщение в нижестоящий приемник.
- Добавлены версионные хранилища состояний для повышения точности соединений при обработке неупорядоченных записей. Ранее хранилища состояний, используемые Kafka Streams, поддерживали только самое последнее значение, связанное с каждым ключом. Это не позволяло Kafka Streams обеспечивать правильную семантику временного соединения для потоковых таблиц.
- Kafka Streams теперь включает встроенные сериализаторы-десериализаторы (Serde) в общедоступный интерфейс для большинства примитивных типов, включая логические значения.
- В пакет org.apache.kafka.common.serialization, который является частью общедоступного интерфейса добавлен класс BooleanSerde для логических значений.
В заключение отметим, что даже в свежем выпуске уже обнаружились уязвимости, которые устраняются установкой обновления. Какие потенциальные проблемы безопасности были обнаружены в самой популярной платформе потоковой передачи событий, читайте в нашей новой статье. А здесь вы узнаете, какие ошибки исправлены в отладочном выпуске этого релиза. О новинках релиза 3.6.0 мы рассказываем в этом материале.
Освойте администрирование и эксплуатацию Apache Kafka для потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
Источники
