Вышел Apache Kafka 3.0, узнайте о новых функциях, выпущенных в Apache Kafka

Всем привет! Хорошие новости для всех разработчиков, индустрии и всех клиентов, использующих Apache Kafka: вышла новая версия (3.0). Вчера (21 сентября 2021 г.) была выпущена новая версия самой известной платформы для потоковой передачи событий, используемой тысячами компаний для высокопроизводительных конвейеров данных, потоковой аналитики, интеграции данных и критически важных приложений.

Apache Kafka 3.0 представляет множество новых функций, критические изменения API и улучшения KRaft, встроенного механизма консенсуса Apache Kafka, который заменит Apache ZooKeeper .

Хотя KRaft еще не рекомендован для производства (список известных пробелов), в метаданные и API KRaft было внесено много улучшений. Особого внимания заслуживает поддержка единовременного переназначения и переназначения разделов.

Начиная с Apache Kafka 3.0, производитель по умолчанию включает самые надежные гарантии доставки (acks = all, enable.idempotence = true). Это означает, что теперь пользователи по умолчанию получают упорядоченность и надежность.

Также не пропустите усовершенствования перезапуска задач Kafka Connect, улучшения KStreams в синхронизации на основе меток времени и более гибкие параметры конфигурации MirrorMaker2.

Универсальные изменения

  • Поддержка Java 8 не рекомендуется во всех компонентах проекта Apache Kafka в версии 3.0. Это даст пользователям время адаптироваться к следующему основному выпуску (4.0), когда планируется удалить поддержку Java 8.
  • Поддержка Scala 2.12 также не рекомендуется во всех частях Apache Kafka 3.0. Как и в случае с Java 8, у пользователей будет время адаптироваться, поскольку поддержка Scala 2.12 планируется удалить в следующем основном выпуске (4.0).

Брокер Kafka, производитель, потребитель и администратор

  • KIP-630: Kafka Raft Snapshot
    Основная функция, представленная в версии 3.0, - это возможность для контроллеров KRaft и брокеров KRaft создавать, реплицировать и загружать моментальные снимки для раздела метаданных с именем __cluster_metadata. Этот раздел используется кластером Kafka для хранения и репликации информации метаданных о кластере, такой как конфигурация брокера, назначение разделов темы, лидерство и т. Д. По мере роста этого состояния Kafka Raft Snapshot обеспечивает эффективный способ хранения, загрузки и репликации этой информации. .
  • KIP-746: Пересмотр записей метаданных KRaft
    Опыт и непрерывное развитие с момента появления первой версии контроллера Kafka Raft выявили необходимость пересмотра некоторых типов записей метаданных, которые используются, когда Kafka настроен для работы без ZooKeeper ( ZK).
  • KIP-730: Генерация идентификатора производителя в режиме KRaft
    В версиях 3.0 и KIP-730 контроллер Kafka теперь полностью берет на себя ответственность за создание идентификатора производителя Kafka. Контроллер делает это как в режимах ZK, так и в KRaft. Это приближает нас к выпуску моста, который позволит пользователям перейти от развертываний Kafka, использующих ZK, к новым развертываниям, использующим KRaft.
  • KIP-679: Производитель включает самую надежную гарантию доставки по умолчанию.
    Начиная с версии 3.0, производитель Kafka по умолчанию включает идемпотентность и подтверждение доставки всеми репликами. По умолчанию это усиливает гарантии доставки записей.
  • KIP-735: Увеличить время ожидания сеанса потребителя по умолчанию
    Значение по умолчанию свойства конфигурации Kafka Consumer session.timeout.ms увеличено с 10 до 45 секунд. Это позволит потребителю по умолчанию лучше адаптироваться к временным сбоям сети и избежать последовательной перебалансировки, когда кажется, что потребитель покидает группу только временно.
  • KIP-709: Расширение запросов OffsetFetch для приема нескольких идентификаторов групп
    Запрос текущих смещений группы потребителей Kafka был возможен в течение некоторого времени. Но для получения смещений нескольких групп потребителей требуется индивидуальный запрос для каждой группы. В версии 3.0 и с KIP-709 API-интерфейсы fetch и AdminClient расширены для поддержки одновременного чтения смещений нескольких групп потребителей в рамках одного запроса / ответа.
  • KIP-699: Обновите FindCoordinator для одновременного разрешения нескольких координаторов
    Поддерживающие операции, которые могут быть применены к нескольким группам потребителей одновременно эффективным способом, в значительной степени зависят от способности клиентов обнаруживать координаторов этих групп эффективно. Это стало возможным с KIP-699, который добавляет поддержку обнаружения координаторов для нескольких групп с помощью одного запроса. Клиенты Kafka были обновлены для использования этой оптимизации при разговоре с новыми брокерами Kafka, которые поддерживают этот запрос.
  • KIP-724: Отказ от поддержки форматов сообщений v0 и v1
    Четыре года, прошедшие с момента его появления в июне 2017 года с Kafka 0.11.0, формат сообщения v2 был форматом сообщений по умолчанию. Таким образом, при достаточном количестве воды (или ручьев, если можете), протекавшей под мостом, основной выпуск 3.0 дает нам хорошую возможность отказаться от старых форматов сообщений, а именно v0 и v1. Сегодня эти форматы используются редко. В версии 3.0 пользователи получат предупреждение, если они настроят своих брокеров на использование форматов сообщений v0 или v1. Эта опция будет удалена в Kafka 4.0 (подробности и последствия отказа от форматов сообщений v0 и v1 см. В KIP-724).
  • KIP-707: будущее KafkaFuture
    Когда KafkaFuture type был представлен для облегчения реализации Kafka AdminClient, версии до Java 8 все еще широко использовались, а Java 7 официально поддерживалась Kafka. Перенесемся на несколько лет позже, и теперь Kafka работает на версиях Java, которые поддерживают типы CompletionStage и CompletableFuture class. В KIP-707 KafkaFuture добавляет метод для возврата объекта CompletionStage и, таким образом, повышает удобство использования KafkaFuture с обратной совместимостью.
  • KIP-466: добавлена ​​поддержка List ‹T› сериализации и десериализации
    KIP-466 добавляет новые классы и методы для сериализации и десериализации общих списков - функция, полезная как для клиентов Kafka, так и для потоков Kafka.
  • KIP-734: Улучшение AdminClient.listOffsets для возврата метки времени и смещения для записи с самой большой меткой времени
    Расширены возможности пользователей по отображению смещений тем / разделов Kafka. С KIP-734 пользователи теперь могут запросить AdminClient вернуть смещение и метку времени записи с самой высокой меткой времени в теме / разделе. (Это не следует путать с тем, что AdminClient уже возвращается как последнее смещение - это смещение следующей записи, которая будет записана в тему / раздел.) Это расширение существующего API ListOffsets позволяет пользователям проверять работоспособность раздел, спрашивая, какое смещение самой последней записанной записи и какова ее временная метка.

Kafka Connect

  • KIP-745: API Connect для перезапуска коннектора и задач
    В Kafka Connect коннектор представлен во время выполнения как группа из экземпляра класса Connector и одного или нескольких экземпляров класса Task, а большинство операций с коннекторами доступны через Connect REST API можно применить к группе в целом.
  • Заметным исключением с самого начала были конечные точки перезапуска для экземпляров Connector и Task. Чтобы перезапустить соединитель в целом, пользователям приходилось выполнять отдельные вызовы для перезапуска экземпляра Connector и экземпляров Task.
  • В версии 3.0 KIP-745 дает пользователям возможность перезапустить либо все, либо только сбой экземпляров коннектора и задачи одним вызовом. Эта функция является дополнительной возможностью, и предыдущее поведение REST API перезапуска остается неизменным.
  • KIP-738: Удаление внутренних свойств конвертера Connect
    После прекращения поддержки в предыдущем основном выпуске (Apache Kafka 2.0), internal.key.converter и internal.value.converter удалены как свойства конфигурации и префиксы в Worker Connect. конфигурация. В дальнейшем внутренние темы Connect будут использовать JsonConverter исключительно для хранения записей без встроенных схем. Любые существующие кластеры Connect, в которых использовались разные конвертеры, должны будут перенести свои внутренние разделы в новый формат (подробности о пути обновления см. В KIP-738).
  • KIP-722: включить переопределение клиента коннектора по умолчанию
    Начиная с Apache Kafka 2.3.0, работник коннектора может быть настроен таким образом, чтобы позволить конфигурациям коннектора переопределять свойства клиента Kafka, используемые коннектором. Эта функция широко использовалась, и теперь, когда появилась возможность основного выпуска, возможность переопределения свойств клиента соединителя включена по умолчанию (для connector.client.config.override.policy по умолчанию установлено значение Все).
  • KIP-721: Включить контексты журнала коннектора в конфигурации Connect Log4j
    Еще одна функция, которая была представлена ​​еще в 2.3.0, но не была включена по умолчанию до этого момента, - это контексты журнала коннектора. Это меняется в версии 3.0, и контекст коннектора добавляется по умолчанию в шаблон log4j logs работника Connect. При обновлении предыдущей версии до версии 3.0 формат строк журнала, экспортируемых log4j, изменяется путем добавления контекста соединителя, где это необходимо.

Кафка Ручьи

  • KIP-695: Дальнейшее улучшение синхронизации временных меток Kafka Streams
    KIP-695 расширяет семантику того, как задачи Streams выбирают выборку записей, и расширяет значение и доступные значения свойства конфигурации max.task.idle.ms. Для этого изменения потребовался новый метод currentLag в потребительском API Kafka, который может возвращать задержку потребителя определенного раздела, если она известна локально и без обращения к брокеру Kafka.
  • KIP-715: Отображение зафиксированного смещения в потоках
    Начиная с версии 3.0, в интерфейс TaskMetadata добавлены три новых метода: commitOffsets, endOffsets и timeCurrentIdlingStarted. Эти методы могут позволить приложениям Streams отслеживать ход выполнения и состояние своих задач.
  • KIP-740: очистка общедоступного API в TaskId
    KIP-740 представляет собой существенное обновление класса TaskId. Некоторые методы и все внутренние поля устарели, а новые геттеры subtopology () и partition () заменяют старые поля topicGroupId и partition (см. Также KIP-744 для соответствующих изменений и поправки к KIP-740).
  • KIP-744: перенос TaskMetadata и ThreadMetadata в интерфейс с внутренней реализацией
    KIP-744 развивает изменения, предложенные KIP-740, на один шаг дальше и отделяет реализацию от общедоступного API ряда классов. Для этого вводятся новые интерфейсы TaskMetadata, ThreadMetadata и StreamsMetadata, в то время как существующие классы с такими же именами устарели.
  • KIP-666: Добавление методов на основе Instant в ReadOnlySessionStore
    API интерактивных запросов расширен новым набором методов в интерфейсах ReadOnlySessionStore и SessionStore, которые принимают аргументы типа данных Instant. Это изменение повлияет на любые реализации настраиваемого хранилища сеансов интерактивных запросов только для чтения, в которых потребуется реализовать новые методы.
  • KIP-622: Добавьте currentSystemTimeMs и currentStreamTimeMs в ProcessorContext
    ProcessorContext добавляет два новых метода в 3.0, currentSystemTimeMs и currentStreamTimeMs. Новые методы дают пользователям возможность запрашивать кэшированное системное время и время потоков соответственно, и их можно единообразно использовать в производственном и тестовом коде.
  • KIP-743: Удалите значение конфигурации 0.10.0–2.4 конфигурации встроенных метрик Streams.
    Поддержка устаревшей структуры метрик для встроенных метрик в Streams повышена в версии 3.0. KIP-743 удаляет значение 0.10.0–2.4 из свойства конфигурации built.in.metrics.version. Это оставляет самое последнее значение как единственное допустимое значение этого свойства на данный момент (значение по умолчанию с версии 2.5).
  • KIP-741: Изменить значение SerDe по умолчанию на null
    Предыдущее значение по умолчанию свойств SerDe по умолчанию удалено. Потоки, используемые по умолчанию для ByteArraySerde. Начиная с версии 3.0, нет значения по умолчанию, и пользователи должны либо установить свои SerDes по мере необходимости в API, либо установить значение по умолчанию с помощью DEFAULT_KEY_SERDE_CLASS_CONFIG и DEFAULT_VALUE_SERDE_CLASS_CONFIG в своей конфигурации потоков. Предыдущее значение по умолчанию почти всегда не применялось к реальным приложениям и вызывало больше путаницы, чем удобства.
  • KIP-733: Изменить конфигурацию коэффициента репликации по умолчанию для потоков Kafka.
    При возможности основного выпуска значение по умолчанию для свойства конфигурации Streams replication.factor изменяется с 1 на -1. Это позволит новым приложениям Streams использовать коэффициент репликации по умолчанию, определенный на брокере Kafka, и, следовательно, не потребуется устанавливать это значение конфигурации при переходе в рабочую среду. Обратите внимание, что для нового значения по умолчанию требуется Kafka Brokers версии 2.5 или выше.
  • KIP-732: исключить eos-alpha и заменить eos-beta на eos-v2
    Еще одно значение конфигурации Streams, объявленное устаревшим в версии 3.0, - even_once в качестве значения свойства processing.guarantee. Значение even_once соответствует исходной реализации семантики Exactly Once (EOS), доступной для любых приложений Streams, которые подключаются к кластеру Kafka версии 0.11.0 или новее. Эта первая реализация EOS была заменена второй реализацией EOS в Streams, которая была представлена ​​значением even_once_beta в свойстве processing.guarantee. В дальнейшем имя точно_once_beta также устарело и заменено новым именем точно_once_v2. В следующей основной версии (4.0) будут удалены и excitly_once, и even_once_beta, в результате чего точно_once_v2 останется единственным вариантом для гарантии доставки EOS.
  • KIP-725: Оптимизация конфигураций для WindowedSerializer и WindowedDeserializer
    Свойства конфигурации default.windowed.key.serde.inner и default.windowed.value.serde.inner устарели в пользу одного нового свойства windowed.inner.class .serde для использования клиентом-потребителем. Пользователям Kafka Streams рекомендуется настроить оконный SerDe, передав его вместо этого в конструктор SerDe, а затем предоставив SerDe везде, где он используется в топологии.
  • KIP-633: исключение 24-часового периода по умолчанию для льготного периода в Streams
    В Kafka Streams оконным операциям разрешено обрабатывать записи вне своего окна в соответствии со свойством конфигурации, которое называется льготным периодом. Раньше эта конфигурация была необязательной, и ее легко было пропустить, поэтому по умолчанию использовалось 24 часа. Это частый источник путаницы для пользователей оператора подавления, поскольку он буферизует записи до истечения льготного периода и, следовательно, добавляет 24-часовую задержку. В версии 3.0 классы Windows расширены фабричными методами, которые требуют, чтобы они создавались с настраиваемым льготным периодом или вообще без льготного периода. Старые фабричные методы, которые применяли льготный период по умолчанию в 24 часа, устарели вместе с соответствующими API-интерфейсами grace (), которые несовместимы с новыми фабричными методами, которые уже устанавливали эту конфигурацию.
  • KIP-623: добавление опции «internal-themes» к инструменту сброса потокового приложения
    Использование Streams инструмента сброса приложения kafka-streams-application-reset становится более гибким с добавлением нового параметра командной строки: - внутренние темы. Новый параметр принимает список разделенных запятыми названий тем, соответствующих внутренним темам, которые можно запланировать для удаления с помощью этого инструмента приложения. Объединение этого нового параметра с существующим параметром - пробный запуск позволяет пользователям подтверждать, какие темы будут удалены, и при необходимости указывать их подмножество перед фактическим выполнением операции удаления.

MirrorMaker

  • KIP-720: прекращение поддержки MirrorMaker v1
    Начиная с версии 3.0 первая версия MirrorMaker устарела. В дальнейшем разработка новых функций и основные улучшения будут сосредоточены на MirrorMaker 2 (MM2).
  • KIP-716: Разрешить настройку местоположения темы смещения-синхронизации с помощью MirrorMaker2
    В версии 3.0 пользователи теперь могут настраивать, где MirrorMaker2 создает и хранит свою внутреннюю тему, которую он использует для преобразования смещений группы потребителей. Это позволит пользователям MirrorMaker2 поддерживать исходный кластер Kafka как кластер только для чтения и использовать другой кластер Kafka для хранения записей смещения (которые являются целевым кластером Kafka или даже третьим кластером за пределами исходного и целевого кластеров).

Выводы

Apache Kafka 3.0 - важный шаг вперед для проекта Apache Kafka. Чтобы узнать больше, Загрузите Apache Kafka 3.0, чтобы начать работу с последней версией.

Другие статьи об Apache Kafka и обмене сообщениями, которые могут вам понравиться



10 лучших курсов для изучения Apache Kafka в 2021 году
Возможно, вы слышали об Apache Kafka, системе обмена большими данными следующего поколения, которая обрабатывает миллиарды… средних .com





10 лучших курсов по микросервисам Java с Spring Boot и Spring Cloud в 2021 году
Мои любимые онлайн-курсы по изучению микросервисов на Java с использованием Spring Boot и Spring Cloud для начинающих в 2021 году от… medium.com