В конце февраля вышел очередной релиз Apache Kafka за номером 3.7. Поддержка JBOD в KRaft-кластерах, новый протокол перебалансировки потребителей, мониторинг метрик клиента на брокере, новинки Streams и Connect, и другие изменения самой популярной платформы потоковой передачи событий для дата-инженера и администратора.
Изменения в брокерах, продюсера, контроллерах и Admin Client
27 февраля выпущена версия Apache Kafka 3.7, которая содержит 6 новых фич, более 45 улучшений и почти 80 исправленных ошибок. Одним из достаточно значимых изменений стала обработка сбоя диска брокера JBOD в KRaft, чтобы полностью отказаться от Zookeeper. Вообще возможность миграции кластеров Kafka из ZooKeeper в систему метаданных KRaft, готовая к промышленному развертыванию, была доступна еще в выпуске 3.6, о чем мы писали здесь. А в релизе 3.7 добавлена поддержка JBOD (Just a Bunch Of Disks) в кластерах на базе KRaft, позволяющая вести несколько каталогов журналов для каждого брокера. JBOD стал важной функцией Kafka, позволяющей запускать крупные развертывания с несколькими устройствами хранения на каждого брокера. Чтобы обеспечить доступность кластера, в случае сбоя лидера раздела контроллер должен выбрать нового лидера из одной из других синхронизированных реплик. В релизе 3.8 поддержка JBOD стала доступной для производственного использования.
Ранее контроллер не проверял корректность работы лидера, предполагая, что каждый брокер работает корректно, если он еще является активным членом кластера. Однако, поскольку в KRaft членство в кластере основано на своевременных запросах подтверждения, отправляемых каждым брокером активному контроллеру, а не на эфемерном zNode в /brokers/ids, как в в ZooKeeper, при сбое одного каталога журналов брокер не сможет быть ни ведущим, ни ведомым для каких-либо разделов в этом каталоге журналов. Тогда контроллер не знает, что ему необходимо обновить лидерство и ISR для реплик в этом каталоге журналов, поскольку брокер будет продолжать отправлять контрольные запросы. Поэтому поддержка JBOD в KRaft позволяет избежать необходимости делать RPC-вызовы для перечисления всех разделов в каталоге журналов. Хотя эта функция пока не рекомендуется для производственного использования, в будущем с ее помощью можно ускорить отказ от ZooKeeper.
Еще одной интересной функцией раннего доступа можно назвать новый упрощенный протокол перебалансировки потребителей, который переносит сложность с потребителя на координатора группы внутри брокера и полностью обновляет протокол, делая его инкрементным по своей природе. Он обеспечивает те же гарантии, что и текущий протокол, но лучше и эффективнее, в том числе больше не полагаясь на барьер глобальной синхронизации. Также сокращено время, необходимое клиенту для обнаружения нового лидера раздела, что сокращает сквозную задержку запросов на создание/выборку при смене лидера, включая перезапуск брокера, переназначение раздела и пр. Здесь же можно отметить про экспоненциальную отсрочку для клиентов Kafka, которая изменяет время задержки повторной попытки повтора неудачных запросов. Это позволит уменьшить медленную конвергенцию метаданных после сбоя брокера из-за перегрузки.
В новом релизе AdminClient может напрямую общаться с кворумом контроллера KRaft и добавить регистрацию контроллера, поддерживая такие операции, как DESCRIBE_QUORUM и INCREMENTAL_ALTER_CONFIGS, для динамического изменения уровней log4j на контроллере KRaft. Это помогает при отладке сценариев, когда другие части системы не работают.
С протоколом KRaft связано еще одно обновление: возможность независимой остановки процессов KRaft в случаях, когда операторы работают в комбинированном режиме, т.е. контроллер и брокер развернуты на одном узле. Раньше можно было остановить только обоих, а теперь это доступно и по отдельности. Командная строка для остановки узлов Kafka с версии 3.7. включает пару необязательных и взаимоисключающих параметров [—process-role] ИЛИ [—node-id] для использования с shell-оболочкой ./bin/kafka-server-stop.sh.
В Apache Kafka 2.7 добавлена поддержка метрик клиента на стороне брокера через стандартизированный интерфейс телеметрии, а также возможность изменения их конфигурации через создание, чтение, обновление и удаления ресурсов с использованием существующих RPC-вызовов и инструмента kafka-configs.sh. Еще добавлены дополнительные показатели для измерения производительности KRaft: ActiveControllersCount, CurrentMetadataVersion, TimedOutBrokerHeartbeatCount и пр. Появилась метрика CurrentControllerId, которая позволяет пользователям находить текущий контроллер, просматривая метрики любого брокера/контроллера Kafka.
В релизе 3.7 добавлена защита транзакций на стороне сервера, предотвращающая их зависание для смещения потребителей в разделах топика. А, чтобы лучше отслеживать производительность, устранять и предотвращать проблемы с многоуровневым хранилищем Kafka, поддерживаются дополнительные метрики этой функции. Все версии клиентских запросов старше Apache Kafka 2.1 теперь помечены как устаревшие и вводит новые метрики для мониторинга наличия таких запросов. Поддержка этих запросов будет прекращена в выпуске 4.0.
С версии 3.7. в Apache Kafka разрешена динамическая перезагрузка сертификатов с разными доменными и субъектными именами (DN/SAN, Subject Alternative Name). Возможность настройки позволяет предотвратить проверки, гарантирующие, что отличительное имя домена DN и альтернативные имена субъектов SAN одинаковы в старом и новом хранилищах ключей при их перезагрузке.
Наконец, Java 11 больше не поддерживается для всех модулей сервера и инструментов: kafka-server-common, kafka-server, kafka_2.13, kafka-storage, kafka-metadata, kafka-group-coordinator, kafka-raft, kafka-shell, kafka-tools. Это сделано для подготовки к выпуску Kafka 4.0. Однако, для всех остальных модулей (включая клиенты, Kafka Streams и Kafka Connect) по-прежнему потребуется Java 11.
В заключение отметим, что появился официальный Docker-образ Apache Kafka на базе JVM, позволяющий ускорить тестирование и развертывание.
Новинки Kafka Streams и Connect
Для повышения надежности в Kafka Streams добавлена вторая стратегия назначения задач с учетом стойки. Теперь информация о том, на какой стойке кластера развернуты клиенты, есть в интерфейсе назначения разделов, чтобы учитывать это при их назначении на разделы топика Kafka. Это позволит сократить трафик между стойками и ускорить обработку данных. При этом протокол перебалансировки клиентов остается прежним, изменена только логика назначения: путь чтения в лидере группы на клиентах.
Для этого добавлен новый интерфейс для обработки случаев, когда резервные задачи имеют зарегистрированные хранилища состояний, загрузку пакета записей и остановку обновлений. Также конфигурации хранилища DSL по умолчанию расширена до пользовательских типов, чтобы разработчик мог подключать любые хранилища состояний, используя новый интерфейс, поддерживающий в т.ч. RocksDB и резидентные хранилища. Еще введено версионирование хранилищ состояний, обращаться к которым можно с помощью запросов VersionedKeyQuery и MultiVersionedKeyQuery. Они позволяют выполнять поиск одного ключа, запрашивать самое последнее значение, историческое значение или диапазон исторических значений для предоставленного ключа. Упрощены требования к ненулевому ключу в Kafka Streams, которые ранее не допускались.
Также добавлены новые интерактивные запросы TimestampedKeyQuery и TimestampedRangeQuery с меткой времени для хранилищ состояний «ключ-значение» с меткой времени. Это изменение повышает безопасность типов API, возвращая значение, только если оно выдано в хранилище значений ключа с меткой времени. Запросы типа RangeQueries позволяют запрашивать диапазон ключей, результаты выполнения которых теперь можно упорядочить для каждого раздела в порядке возрастания или убывания или оставить порядок неуказанным.
Также стоит отметить изменения в Kafka Connect, среди которых динамическая настройка лога для всего кластера и отдельных рабочих процессов. Новые коннекторы теперь можно создавать в состоянии «ОСТАНОВЛЕНО» или «ПАУЗА», что облегчает их миграцию. В частности, при создании коннектора у него можно заполнить новое необязательное поле с начальным состоянием (initial_state). Еще в Kafka Connect добавлен конвертер BooleanConverter, поддерживающий сериализацию и десериализацию логического примитива в схеме благодаря изменениям в org.apache.kafka.connect.storage.Converter и org.apache.kafka.connect.storage.HeaderConverter. Наконец, устарела избыточная конечная точка для получения конфигураций задач Connect, которая будет удалена в выпуске 4.0.
Узнайте больше про администрирование и эксплуатацию Apache Kafka для потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
Источники
