Apache Kafka 4.3: що змінюється для Streams, share-груп і операторів

Apache Kafka 4.3 приносить одразу 25 KIP‑ів (Kafka Improvement Proposals) і помітно зміщує акценти в бік керованості, надійності та підготовки до версій 5.0 і 6.0. Огляд ключових змін опублікував канал Confluent Developer, зосередившись на Kafka Streams, нових контролях для share-груп і механізмах ізоляції брокерів.

Заголовки як «першокласні громадяни» в Kafka Streams

Одна з найпомітніших змін — повноцінна підтримка заголовків записів у Kafka Streams.

KIP‑1271: заголовки в state stores

До цього заголовки подій (headers) — наприклад, для trace‑ID у розподіленому трейсингу чи feature‑flags для подальшої обробки — губилися після станоутворювальних операцій. У state store зберігалися ключ, значення та часовий штамп, але не заголовки.

KIP‑1271 змінює це: у Processor API з’являються нові інтерфейси state store, які дозволяють зберігати заголовки разом із рештою даних. Це відкриває шлях до:

• коректного збереження метаданих на всіх етапах обробки;
• кращої підтримки розподіленого трейсингу;
• більш гнучких патернів маршрутизації та фільтрації на основі заголовків.

KIP‑1285: конфігурація збереження заголовків у DSL

KIP‑1285 переносить ці можливості в Kafka Streams DSL:

• можна глобально ввімкнути збереження заголовків для всіх state stores у топології;
• або ж вибірково активувати для окремих state stores.

Підтримка реалізована і в topology test driver, тож поведінку із заголовками можна перевіряти в юніт‑тестах як для Processor API, так і для DSL. Для команд, які активно використовують headers як транспорт метаданих, це знімає важливе обмеження попередніх версій.

Share-групи: тонке налаштування продуктивності

Kafka 4.3 продовжує розвиток концепції «queues for Kafka» (KIP‑932), додаючи нові можливості для тонкого тюнінгу share‑груп.

KIP‑1240: дворівнева модель конфігурацій

Новий KIP вводить два рівні налаштувань:

1. Кластерні «рейки безпеки» (guardrails)
2. задаються операторами на рівні брокера;
3. відображають протестовані best practices;

4. гарантують, що окремі застосунки не «з’їдять» кластер.

5. Конфігурації конкретної share‑групи

6. задаються в межах кластерних лімітів;
7. дозволяють адаптувати поведінку під конкретний кейс.

Контроль delivery count і renew‑ack

Серед нових параметрів:

• Delivery count
• на брокері можна задати нижню й верхню межу для всіх share‑груп;

• кожна група в межах цих лімітів виставляє власне значення, балансуючи між гарантіями доставки та навантаженням.

• Керування acknowledgement type renew

• для share‑груп у режимі explicit acknowledgements можна дозволити або заборонити використання renew;
• renew (з’явився в 4.2) потрібен для довготривалих задач: клієнт сигналізує брокеру, що йому потрібно більше часу на обробку конкретного повідомлення;
• якщо renew вимкнено, доступні лише accept, release та reject; спроба використати renew призведе до помилки invalid record state.

У підсумку кілька share‑груп у спільному кластері можуть працювати більш незалежно й бути налаштованими під власні SLA, не заважаючи одна одній.

Операції з кластером: «cordon» для брокерів і дисків

Для операторів Kafka 4.3 приносить знайому з Kubernetes концепцію cordoning — ізоляції ресурсів без повної зупинки сервісу.

KIP‑1066: ізоляція брокерів і log‑директорій

Новий механізм дозволяє:

• cordon‑ити log‑директорію
• вона продовжує обслуговувати наявні репліки;

• але не отримує нових призначень партицій.

• cordon‑ити брокер

• якщо всі log‑директорії брокера ізольовані, сам брокер фактично теж переходить у стан «no new work»;
• при цьому клієнти продовжують працювати з уже розміщеними на ньому репліками.

Це спрощує сценарії:

• масштабування кластера вгору/вниз;
• заміни або видалення дисків;
• виведення брокера з експлуатації.

Оператори отримують «першокласний» інструмент, щоб сказати кластеру: «сюди нові партиції не класти», не влаштовуючи при цьому простоїв для клієнтів.

Еволюція Kafka Streams: стан, прибирання й обробка помилок

Окрім заголовків, Kafka 4.3 містить низку змін, спрямованих на коректність і керованість Kafka Streams.

KIP‑1035: offsets під контролем state store

Раніше:

• offsets changelog‑ів зберігалися окремо у checkpoint‑файлах;
• state store жив своїм життям;
• не було способу атомарно оновити і стан, і offset.

KIP‑1035 пропонує модель, де persistent state stores самі керують своїми committed changelog offsets. Це потрібно для:

• кращої коректності відновлення стану;
• більш передбачуваної поведінки RocksDB;
• підготовки до майбутніх транзакційних state stores.

KIP‑1259: прибирання локального стану

З’являється новий опційний параметр для автоматичного очищення старих локальних state‑файлів і директорій. Це:

• зменшує ризики накопичення «сміття» на диску;
• особливо актуально для середовищ із частими перезапусками або міграціями задач.

Функція не ввімкнена за замовчуванням — значення потрібно задати явно.

KIP‑1270: контрольовані винятки в global ktable

До 4.3 ProcessingExceptionHandler працював лише для звичайних streams‑тасків. Помилка в global ktable могла просто «покласти» весь застосунок.

Тепер:

• ProcessingExceptionHandler застосовується і до задач global ktable;
• обробка глобальних таблиць стає більш узгодженою з рештою Kafka Streams;
• з’являється контрольований шлях обробки винятків замість негайного падіння.

У Kafka 5.0 ця поведінка буде ввімкнена за замовчуванням, тож 4.3 — зручний момент для тестування.

Метрики, безпека, Connect: дрібні, але важливі покращення

Реліз також містить низку точкових оновлень:

• удосконалення JMX‑метрик для сховища;
• покращення OAuth client assertion;
• обмеження буфера координатора для запобігання out‑of‑memory;
• нові конфіги для craft fetch;
• стандартизація метрик MirrorMaker;
• краща «видимість» конекторів і SMT у Kafka Connect.

Ці зміни не настільки гучні, як нові KIP‑и для Streams чи share‑груп, але вони впливають на щоденну експлуатацію кластерів і спостережуваність.

Погляд уперед: підготовка до Kafka 5.0 і 6.0

Частина нововведень 4.3 прямо орієнтована на майбутні мажорні релізи.

Новий протокол ребалансування

• KIP‑848 раніше представив більш ефективний і менш деструктивний механізм ребалансування consumer‑ів.
• KIP‑1071 поширив його на Kafka Streams.

План міграції:

• Kafka 5.0
• новий механізм ребалансування стає дефолтним;
• «класичні» конфіги будуть депрекейтед;

• їх ще можна буде використовувати, але в логах з’являться наполегливі рекомендації перейти на новий протокол.

• Kafka 6.0

• класичний механізм ребалансування буде повністю видалений.

Реліз 4.3 — слушний момент, щоб почати тестувати новий протокол і планувати міграцію.

Відмова від Scala‑обгортки для Kafka Streams DSL

Scala‑DSL для Kafka Streams оголошено застарілим і заплановано до видалення в Kafka 5.0. Рекомендація однозначна: якнайшвидше мігрувати на Java DSL.

Craft‑mode і централізація конфігурацій топіків

У craft‑mode саме контролер створює топіки, а отже:

• дефолтні значення для кількості партицій, фактору реплікації та інших параметрів топіка мають належати контролеру;
• мета — уніфікувати застосування налаштувань по всьому кластеру.

Починаючи з Kafka 5.0:

• брокерські topic‑level конфіги будуть ігноруватися;
• пріоритет матимуть значення з конфігурації контролера.

Це ще один сигнал, що екосистема Kafka рухається до більш централізованого, керованого підходу до конфігурацій.

Джерело

YouTube: Apache Kafka 4.3 | 25 KIPs, Kafka Streams, Share Group Controls, Broker Isolation, and more