29 июля 2024 года вышло очередное обновление Apache Kafka. Разбираемся с главными новинками релизе 3.8: поддержка JBOD в многоуровневом хранилище, детальная настройка уровня сжатия, улучшение безопасности и удаление неоднозначных конфигураций.
ТОП-7 новинок Apache Kafka 3.8
Многоуровневое хранилище (Tiered Storage) для надежного долговременного хранения данных, опубликованных в Kafka, без ущерба высокой пропускной способности, было реализовано еще в выпуске 3.6, о чем мы писали здесь. Однако, раньше эта функция раннего доступа, рекомендуемая для тестирования в непроизводственных средах, не поддерживала JBOD (Just a Bunch Of Disks) в кластерах на базе KRaft. Вообще поддержка JBOD в KRaft-кластерах впервые вышла в релизе 3.7 как функция раннего доступа. В выпуске 3.8 она перешла в статус производственного использования. Теперь с полноценной поддержкой JBOD можно вести несколько каталогов журналов для каждого брокера, чтобы запускать крупные развертывания с несколькими устройствами хранения на разных узлах кластера Kafka с протоколом Kafka. Это еще один шаг к полному отказу от Apache Zookeeper как внешнего сервиса синхронизации метаданных, который будет полностью упразднен в мажорном релизе Kafka 4.0.
До сих пор Apache Kafka использовал только уровень сжатия по умолчанию. С версии 3.8 включен механизм конфигурации продюсера, брокера и топика для указания уровня сжатия. Добавлены 3 новых целочисленных параметра для кодеков gzip, lz4 и zstd: compression.gzip.level, compression.lz4.level и compression.zstd.level. Кодек snappy исключен, поскольку он не поддерживает ни один уровень сжатия. На уровне продюсера параметр сжатия определяет, как он сжимает исходные записи с использованием указанного кодека и уровня сжатия:
- если compression.type равен none или snappy, то значение уровня сжатия compression.<codec>.level игнорируется;
- для кодека gzip уровень сжатия задается в диапазоне от 1 до 9, для lz4 от 1 до 17, для zstd от -131072 до 22. Если параметр compression.<codec>.level не находится в допустимом диапазоне, возникнет ошибка.
- Когда уровень сжатия compression.<codec>.level не задан, используется значение по умолчанию.
Когда брокер Kafka получает сжатые продюсером записи и кодек сжатия топика установлен в значение producer или совпадает с кодеком продюсера, записи добавляются в логи. Если продюсер использовал другой уровень сжатия, записи не пересжимаются. Иначе брокер повторно сжимает записи с указанным кодеком и уровнем сжатия. Бенчмаркинговое тестирование показало, что оптимальная настройка параметра сжатия может улучшить пропускную способность публикации примерно в 1,5 раза.
Еще в прошлом выпуске 3.7 добавлен новый упрощенный протокол перебалансировки потребителей, который переносит сложность с потребителя на координатора группы внутри брокера и является инкрементным. Он предполагает, что конфигурация offsets.commit.required.acks, равная по умолчанию -1, никогда не должна переопределяться, чтобы учитывать семантику верхнего водяного знака и гарантировать, что последние полученные смещения будут напрямую доступны для следующих запросов на выборку. Однако, это неправильно используется при перебалансировке, т.е. записи метаданных группы в журнал. Чтобы сократить риск от некорректного использования конфигурации offsets.commit.required.acks, в выпуске Kafka 3.8 она признана устаревшей и будет устранена в релизе 4.0.
Еще из значимых обновлений выпуска 3.8 стоит отметить возможность клиентов Kafka, т.е. продюсеров и потребителей повторять процесс загрузки при обновлении метаданных, если ни один из известных брокеров недоступен. Для этого добавлен ключ metadata.recovery.strategy, по умолчанию равный none. Если установлено значение rebootstrap, клиент повторяет процесс загрузки с помощью обращения к bootstrap.servers. Если значение параметра reconnect.backoff.max.ms очень низкое, брокер не считается недоступным, и в этом случае перезагрузка не произойдет.
В целях повышения безопасность в Kafka 3.8 добавлена возможность ограничивать файлы, доступные поставщикам конфигурации файлов и каталогов, чтобы избежать неограниченного доступа. Также добавлена конфигурация remote.fetch.max.wait.ms – максимальный тайм-аут удаленной выборки для запросов DelayedRemoteFetch при чтении из удаленного хранилища. Это позволяет настраивать тайм-аут в зависимости от рабочей нагрузки.
Из значимых улучшений Kafka Streams стоит отметить совместно используемые хранилища состояний, что позволяет использовать данные в хранилище состояний в нескольких приложениях без дублирования на уровне топика и настраиваемое назначение задач для потоков, что заменяет существующую внутреннюю конфигурацию задач assignor. Также добавлено несколько новых метрик для поиска утечек памяти и проблем с производительностью в приложениях Kafka Streams.
Наконец, для Kafka Connect изменено поведение свойства tasks.max.enforce, которое при установке в значение false позволяло коннектору генерировать количество задач больше максимального. Однако коннекторы, которые генерируют слишком много задач, завершаются ошибкой, как и существующие наборы задач, которые превышают свойство tasks.max. Чтобы предупредить риск возникновения такой ошибки, свойство tasks.max.enforce объявлено в Kafka 3.8 устаревшим и будет удалено в следующем мажорном релизе.
Научитесь администрированию и эксплуатации Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
Источники
