Kafka Streams¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: Kafka Streams 4.1.0, JVM library, processing.guarantee=exactly_once_v2. Проверка источников: 2026-11-02. Baselines не объявляются latest/security recommendations.

Архитектура и роль¶

FACT. JVM library в обычном приложении; application.id идентифицирует stream application/group и internal resources. Topology разделяется на tasks по partitions, thread может исполнять несколько tasks. Не требуется отдельный Flink-style cluster manager, но нужны deployment/HA самого приложения.

Внутренние механизмы и движение данных¶

KStream описывает records, KTable — updates keyed state; joins/aggregations используют local state stores и changelog topics. Repartition topic перемещает key distribution, changelog восстанавливает state после task migration. Local RocksDB state directory ускоряет restart, но authoritative recovery требует доступного changelog/input retention.

flowchart TB
  Kafka[Input partitions] --> Tasks[Application tasks and stream threads]
  Tasks --> State[Local keyed state]
  State --> Changelog[Kafka changelog]
  Tasks --> Output[Transactional Kafka outputs]
  Changelog --> Restore[Task migration restore]
  Restore --> State

Ordering и guarantees¶

processing.guarantee=exactly_once_v2 координирует Kafka inputs, state/changelog и output records в transaction protocol поддерживаемой topology. Producer fencing/transaction timeouts важны при recovery. External JDBC/HTTP side effects из processor не становятся частью Kafka transaction. Ordering остаётся partition/task scope.

Версия и первичная документация.

Масштабирование и backpressure¶

Parallelism ограничен input/repartition partitions, streams threads и key skew. Standby replicas сокращают restore work ценой ресурсов; warmup/migration settings зависят от версии. Interactive queries читают распределённый local state, для global lookup приложение реализует routing/retries.

Failure / recovery / replay¶

Task restart восстанавливает committed state; aborted processing может физически исполниться снова. Изменение topology/internal topic names требует compatibility plan. Application reset может удалить progress/state и повторить effects; выполнять на изолированной generation с documented reset scope.

Версия и первичная документация.

Эксплуатация и мониторинг¶

State restore lag/rate, commit latency/failures, transaction errors, task migration/rebalances, thread health, RocksDB memory/disk и end-to-end watermark. application.id reuse независимыми deployments объединит membership/resources; отдельные environments/versions требуют осознанных namespaces.

Ограничения и критерии выбора¶

Хорош для Kafka-centric transformations/joins с application-owned JVM deployment. Для heterogeneous sources, сложного event-time контроля и большого shared processing estate Flink может дать иной operational model. «Library» не означает zero operations.

FinTech / iGaming и реальные источники¶

INFERENCE: keyed event enrichment, player state projections и transactional Kafka derived topics. Company-specific KafkaStreams4.1 financial deployment/guarantees в текущем registry UNKNOWN. Сравнение с Flink построено по supported mechanisms, не придуманному benchmark.

Практический пример¶

Практика конфигурации:

application.id=betting-enrichment-v1
bootstrap.servers=kafka:9092
processing.guarantee=exactly_once_v2
num.stream.threads=2

Это config fragment, не исполняемая topology; threads=2 — HYPOTHETICAL. Replay/recovery protocol разобран в глубокой теме EOS.

Типичные ошибки проектирования¶

Считать external SQL частью EOS; переиспользовать application.id для несовместимой topology; очищать changelog без retention plan; путать KTable update и append fact.

Вопросы на собеседовании¶

Local state потерян — данные потеряны? Не обязательно: можно восстановить из retained changelog при корректном committed progress.

Нужен JVM cluster manager? Отдельный engine manager нет, но приложение нужно размещать/перезапускать.

Почему больше threads не помогает? Ограничители — partitions/hot key или external sink.

Практические упражнения¶

Опишите migration topology с изменённым repartition key: internal topics, restore, separate application.id, comparison и controlled cutover.