В конце декабря 2020 года вышел новый релиз Apache Kafka – главной Big Data технологии для потоковой передачи событий, интеграции распределенных систем и аналитики больших данных. Читайте далее о новых функциональных возможностях и исправленных ошибках в свежей версии 2.7.0: еще один шаг к отказу от Zookeeper, генерация уведомительных исключений и улучшения Kafka Streams.
Кафка 2.7.0: что нового?
В Apache Kafka 2.7.0 внесено достаточно много изменений [1]:
- добавлено 5 новых фичей;
- 55 улучшений;
- исправлена 91 ошибка.
Наиболее значимыми в этом релизе можно отметить следующие нововведения [2]:
- уверенное продвижение к отмене ZooKeeper как обязательного компонента Kafka-кластера, о чем мы рассказывали здесь. Пока информация о лидере раздела Kafka и синхронизированной реплике (in-sync replica, ISR) хранится в ZooKeeper. Обновить эту информацию могут контроллер или лидер раздела, что может вызвать задержки в отражении изменений ISR и привести к получению устаревших данных в ответ на запросы метаданных. Поэтому был добавлен новый межброкерский API (AlterIsr) для изменения синхронизированной реплики. Он дает контроллеру исключительную возможность обновлять состояние лидеров разделов и ISR, позволяя запросам метаданных всегда отражать последнее состояние.
- Также изменена Core Raft Implementation, который теперь включает отдельный модуль Raft как основной протокол консенсуса. Пока не будет завершена интеграция с контроллером (брокером в кластере Kafka, отвечающим за управление состоянием разделов и реплик), существует автономный сервер, который можно использовать для тестирования производительности реализации Raft.
- добавлен API конфигурации SCRAM на стороне брокера, что позволяет управлять учетными данными SCRAM через протокол Kafka. Инструмент kafka-configs обновлен для использования новых API-интерфейсов протокола, что еще более приближает к замене ZooKeeper встроенным кворумом.
- Теперь прерванная транзакция с не сброшенными данными не вызывает фатальное, а вводит новое исключение TransactionAbortedException, позволяя повторить попытку. Например, когда producer Java-клиента прерывает транзакцию с любыми ожидающими данными, выдается уведомление о том, что записи не отправляются, а не о том, в что приложение произошел неустранимый сбой.
- Поддержка формата PEM для закрытых ключей, сертификатов SSL и закрытых ключей. Поскольку почта с улучшенной конфиденциальностью (PEM, Privacy-Enhanced Mail) является стандартным форматом для хранения и распространения криптографических ключей и сертификатов, это позволяет использовать сторонних поставщиков, использующих такой формат.
- Возможность ограничивать скорость создания соединений на брокерах для каждого IP, чтобы регулировать нагрузку на ЦП.
- Ограничение операций создания топиков, разделов и удаления топиков, API-интерфейсы которых напрямую влияют на общую нагрузку на контроллер Kafka. Чтобы предотвратить перегрузку кластера из-за большого количества одновременных созданий топиков и разделов или удалений топиков, в релизе Apache Kafka 2/7/0 введена новая квота, ограничивающая эти операции.
- Добавлена схема управления версиями для новых фичей, чтобы информировать брокера и клиентов Kafka об изменении их функциональных возможностей и последовательного обновления с помощью всего одного перезапуска.
- В Kafka Connect добавлен класс DirectoryConfigProvider для поддержки пользователей, которым необходимо предоставить секреты для ключей, хранящихся в файловой системе контейнера, например, в среде Kubernetes.
- Наконец, продолжается работа по выделению уровней хранения данных, чтобы обеспечить бесконечное масштабирование и более быстрое время перебалансировки.
Новинки Kafka Streams для разработчика Big Data
Также отметим обновления в Kafka Streams, важные в релизе всей Кафка-платформы для разработчика распределенных приложений для потоковой аналитики больших данных [2]:
- генерация исключений MissingSourceTopicException при удалении исходных топиков из запущенного приложения Kafka Streams, позволяя разработчику своевременно реагировать на ошибку. Это предупреждает ситуацию перебалансировки, вызванную завершением потоков StreamThread, пока приложение «зависает», ожидая, что встроенные клиенты-потребители стараются плавно остановить работу.
- итерация хранилищ состояний Kafka Streams в обратном направлении, т.е. не только от самых старых к новейшим, а наоборот, например, когда пользователь хочет вернуть последние N записей, нет другого выбора, кроме как использовать неэффективный подход, состоящий в обходе.
- переименование неявных экземпляров сериализаторов/десериализаторов (SerDes) в kafka-streams-scala. Напомним, каждое приложение Kafka Streams должно предоставлять SerDes для типов данных ключей записи и значений записи, например, java.lang.String, чтобы материализовать данные. В частности, такая информация SerDes требуется операциям stream(), table(), to(), repartition(), groupByKey(), groupBy(). Предоставить SerDes можно, установив по умолчанию в экземпляре конфигурации java.util.Properties или через явное указание при вызове соответствующих методов API [3].
- добавление показателей сквозной задержки записи, чтобы измерить разницу между моментом возникновения события и тем, когда это событие обрабатывается и отражается в выходных результатах. Например, разработчики приложений Kafka Streams могут создавать события в ответ на действия пользователя, имея представления о том, сколько времени потребуется, чтобы отразить это новое событие в результатах [4].
- добавление метрик о производительности RocksDB – встроенного в Кафка хранилища данных. Мониторинг экземпляров RocksDB, запущенных в приложении Kafka Streams, позволяет реагировать на увеличенные требования RocksDB к памяти и дискам, а также на другие проблемы производительности, связанные с этим встроенной СУБД, до того, как приложение выйдет из строя. Также эта информация пригодится в случае сбоя для анализа его причин.
- Скользящие окна агрегирования в DSL – Kafka Streams реализует сеансовые, кувыркающиеся и прыгающие скачкообразные окна как оконные методы агрегирования, о чем мы писали здесь. Хотя скачкообразное изменение окон с небольшим предварительным временем может имитировать поведение скользящего окна, производительность этой реализации невысока, т.к. приводит к множеству перекрывающихся и часто избыточных окон, требующих дорогостоящих вычислений. Скользящие окна агрегирования в Kafka Streams повышают эффективность выполнения скользящих агрегатов, когда при поступлении новой записи создаются новые временные окна и обновляются существующие.
А уже в марте 2021 года Confluent анонсировала новый выпуск этой Big Data платформы, включив туда долгожданный KIP-500 с отказом от Zookeeper, о чем мы расскажем завтра. Как использовать эти и другие возможности Apache Kafka для разработки распределенных приложений потоковой аналитики больших данных и эффективного администрирования кластеров, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
