Гайды
Kafka Streams: потоковая обработка данных
application.id, KStream и KTable, окна, state stores и changelog, EOS и ограничения по сравнению с Flink.
~12 мин чтения
Kafka Streams: потоковая обработка данных
Kafka Streams — библиотека на JVM для stateful и stateless обработки потоков из Kafka с моделью топология (граф процессоров). Данные читаются consumer group'ом Streams, состояние хранится в внутренних changelog-топиках и RocksDB (локально на узле). Опирается на те же концепты, что Apache Kafka: топики, партиции и оффсеты и Kafka Consumers и consumer groups.
1. Когда Streams, а когда «голый» consumer
| Kafka Streams | Consumer + свой код |
|---|---|
| Окна, join'ы, агрегации из коробки | Полный контроль, любой язык |
| Встроенные state stores и restore из changelog | Сами проектируете хранилище состояния |
| EOS v2 с транзакциями библиотеки | Сами стыкуются с idempotency |
Streams — внутри процесса JVM; для тяжёлых CPU-задач масштабируют инстансы с тем же application.id (разные задачи на разные партиции).
2. Application id и топология
application.id — имя логической группы Streams: определяет consumer group, префиксы внутренних топиков и каталог state store. Смена application.id = новая цепочка offset'ов и часто новые внутренние топики.
StreamsBuilder строит граф: stream(), table(), операторы map, filter, groupByKey, aggregate, join, windowedBy.
При смене топологии или application.id остаются внутренние топики и каталоги RocksDB; для dev используйте application.reset (скрипт Kafka) с пониманием, что offset'ы и state сбросятся. В проде планируйте retention changelog-топиков и диск под restore, иначе rolling restart после инцидента превратится в часы catch-up.
3. KStream и KTable
- KStream — поток событий (каждая запись — факт).
- KTable — материализованное представление последнего значения по ключу (changelog compaction на уровне Kafka для changelog-топика).
GlobalKTable — реплика всех партиций на каждом узле для маленьких справочников в join.
4. Окна (windows)
Tumbling, Hopping, Session windows — для метрик «за 5 минут», сессий пользователя и т.д. Время: event time (из поля записи) vs processing time (часы обработчика).
5. Состояние и fault tolerance
Состояние в RocksDB + changelog в Kafka. При падении узла другой инстанс восстановит state из changelog (может быть долго на больших сторах — планируйте партиции и retention changelog).
6. Serdes
Нужны Serde для ключа и значения на каждом этапе. Для Avro — интеграция со Schema Registry; см. Avro и Schema Registry.
7. Interactive Query (IQ)
REST поверх metadata Streams позволяет читать локальные state stores для отладки или read-your-writes API (осторожно с консистентностью и сетью).
8. Ресурсы и тюнинг (кратко)
num.stream.threads— потоки обработки на процесс.cache.max.bytes.buffering— микробатчинг операторов.commit.interval.ms— как часто commit'ить offset'ы и генерировать changelog.
9. Ограничения
- JVM-экосистема.
- Join'ы чувствительны к ко-партиционированию (одинаковый ключ → одна партиция в обоих топиках).
- Операционная сложность: много внутренних топиков; мониторинг — в Мониторинг Kafka.
Связь с экосистемой
- Потоковая обработка «тяжелее» — часто Flink / Spark Streaming; Streams — удобный middle ground без отдельного кластера обработки.
10. Rebalance и rolling deploy
Static membership (group.instance.id) уменьшает shuffle партиций при кратковременном рестарте пода. При деплое избегайте одновременного рестарта всех реплик Streams — rolling update + health/readiness.
11. EOS и производительность
Exactly-once v2 (processing.guarantee) комбинирует транзакционный producer и consumer; выше задержка и нагрузка на брокер. Для многих сценариев достаточно at-least-once + идемпотентный sink.