Если «тяжеловесные» фреймворки (такие как Apache Spark или Flink) можно сравнить с мощной, но требовательной к ресурсам отдельной электростанцией, то «легковесные» фреймворки — это высокоэффективные генераторы, встроенные прямо в ваши микросервисы. Они не требуют выделения независимого кластера для обработки. Вместо этого они образуют неразрывный симбиоз с брокером событий (Apache Kafka) и системой управления контейнерами (CMS, например, Kubernetes).

В этой главе мы разберём, как работает эта парадигма, почему она стала «золотым стандартом» для stateful-микросервисов, и как с её помощью решать сложнейшие задачи обогащения данных и агрегации в реальном времени.

Это двенадцатая глава цикла. Она опирается на главу V (state stores, rebalance, cooperative sticky), главу VII (RocksDB, LSM, changelog, TTL), главу X (BPC как минимализм) и главу XI (тяжёлые фреймворки как противоположный полюс). Здесь мы замыкаем спектр: от простейшего poll-process-produce через embedded library до распределённых титанов Big Data.

IАрхитектурный сдвиг: брокер как фундамент

Главное отличие «легковесной» модели заключается в перераспределении ответственности. Фреймворк отказывается от управления кластером, полностью делегируя эти задачи инфраструктуре:

Благодаря этому приложение развёртывается как обычный микросервис. Параллелизм контролируется стандартным механизмом групп потребителей (Consumer Groups), а данные одного ключа гарантированно обрабатываются на одном физическом узле, обеспечивая локальность данных.

IIМагия внутреннего состояния и changelog

По умолчанию «легковесные» фреймворки используют внутреннее состояние (например, локальные key-value хранилища вроде RocksDB на SSD-дисках). Это обеспечивает микросекундные задержки при чтении и записи, недостижимые для внешних сетевых БД.

Но что происходит, когда инстанс падает или мы добавляем новый узел для масштабирования? Здесь на сцену выходит журнал изменений (changelog).

1. Каждое обновление локального состояния асинхронно публикуется в скрытый внутренний топик брокера (changelog).
2. При сбое или масштабировании новый инстанс подписывается на этот топик и «проигрывает» события, восстанавливая своё состояние с нуля.
3. Compaction гарантирует, что объём восстановления пропорционален размеру состояния, а не числу обработанных событий.
4. Checkpoint file позволяет начать восстановление с последней позиции, а не с нуля.

Вам не нужно настраивать сложные механизмы контрольных точек (checkpoints) или внешние хранилища — брокер событий уже сделал это за вас.

IIIГетерогенное железо как преимущество

Поскольку каждый микросервис сам управляет своим локальным диском и состоянием, вы можете гибко подбирать железо. Один сервис, требующий огромной пропускной способности IOPS, можно запустить на инстансах с дорогими NVMe SSD, а другой, с большим, но редко читаемым состоянием — на дешёвых HDD.

В «тяжеловесных» кластерах такое разделение ресурсов крайне затруднено: TaskManager'ы гомогенны, и вы не можете дать одному job'у NVMe, а другому — HDD в одном кластере.

IVБесшовное масштабирование и hot standby

Масштабирование «легковесного» микросервиса — это по сути тот же процесс, что и восстановление после сбоя. Когда вы добавляете новый инстанс, CMS перераспределяет партиции. Новый узел должен загрузить состояние из changelog, прежде чем начать обрабатывать новые события. Это может занять время и вызвать временную задержку (lag).

Решение: горячие реплики (hot standby replicas)

Чтобы минимизировать простой при масштабировании или сбоях, Kafka Streams поддерживает концепцию горячих реплик.

Фреймворк запускает фоновые задачи, которые просто читают changelog-топики и держат локальное состояние в «тёплом» виде на резервных узлах. Когда основной узел падает или требуется добавить мощности, контроллер групп потребителей мгновенно переключает трафик на узел, у которого состояние уже полностью готово. Это обеспечивает почти нулевое время простоя (zero-downtime) при перераспределении нагрузки.

VKafka Streams vs Samza: две модели embedded

Многие ставят Kafka Streams и Samza в один ряд как «легковесные библиотеки». Но у них принципиально разные модели, и это влияет на выбор.

VIПаттерн обогащения: Stream-Table Join в действии

Одна из «киллер-фич» легковесных фреймворков — возможность выполнять реляционные соединения (JOIN) между бесконечными потоками событий и материализованными таблицами прямо в памяти, без обращения к внешним БД.

Сценарий: анализ рекламных конверсий

Представьте, что у вас есть поток кликов и просмотров рекламы (события). Вам нужно соединить их со справочником рекламных объявлений (сущности), чтобы понять, какой клиент владеет рекламой, и посчитать итоговую конверсию.

// Материализуем справочник рекламы в локальную таблицу (KTable)
KTable<AdId, Advertisement> adCatalog = builder.table("ads-topic");

// Берём поток пользовательских сессий (KStream)
KStream<UserId, UserAction> userSessions = builder.stream("sessions-topic");

// Группируем, агрегируем и соединяем со справочником
userSessions
    .groupByKey()
    .aggregate(...)  // Считаем конверсии
    .join(adCatalog, (conversion, ad) -> {
        // Обогащаем результат метаданными рекламы
        if (ad == null) return null;  // Обработка tombstone
        return new EnrichedReport(conversion, ad.getClientName());
    })
    .to("enriched-reports-topic");

Как это работает под капотом?

1. Соподразделение (co-partitioning). Фреймворк автоматически гарантирует, что поток агрегатов и таблица справочника разбиты на партиции по одному и тому же ключу (AdId) и имеют одинаковое количество разделов.
2. Локальность. Событие из потока и соответствующая строка из таблицы всегда попадают на один и тот же инстанс. JOIN происходит в локальной оперативной памяти (RocksDB) за микросекунды.
3. Обработка удалений (tombstones). Если реклама удаляется из справочника, в топик приходит событие с null. Фреймворк корректно обрабатывает это, позволяя разработчику решить, что делать с «осиротевшими» агрегатами.

По своей сути, эта топология эквивалентна сложному SQL-запросу с FULL OUTER JOIN и GROUP BY, но выполняется она непрерывно, в реальном времени и с высокой производительностью.

VIICo-partitioning и GlobalKTable

Для stream-table join оба источника должны быть соподразделены: одинаковое число партиций и один и тот же partitioner. Kafka Streams не проверяет это автоматически — если партиции не совпадают, JOIN выдаст неполные результаты тихо и без ошибок.

Альтернатива — GlobalKTable: таблица, полностью реплицируемая на каждый инстанс. Она не требует co-partitioning и позволяет JOIN по произвольному полю через KeyValueMapper.

VIIIWindowing: окна в embedded-мире

Stream-table join — только один паттерн. Оконные операции — то, что делает Kafka Streams полноценным фреймворком:

// Tumbling window: заказы за каждый час
stream.groupByKey()
    .windowedBy(TimeWindows.ofSizeWithNoGrace(Duration.ofHours(1)))
    .count();

// Hopping window: rolling count за 15 минут, обновление каждую минуту
stream.groupByKey()
    .windowedBy(TimeWindows.ofSizeAndGrace(
        Duration.ofMinutes(15), Duration.ofMinutes(1))
        .advanceBy(Duration.ofMinutes(1)))
    .count();

// Session window: сессия пользователя с gap 30 минут
stream.groupByKey()
    .windowedBy(SessionWindows.ofInactivityGapWithNoGrace(
        Duration.ofMinutes(30)))
    .count();

Все четыре типа окон из главы V доступны из коробки: tumbling, hopping, sliding, session. Плюс — event time и grace period из главы VI.

IXExactly-once v2: атомарность из коробки

Kafka Streams предоставляет exactly_once_v2: атомарная транзакция, которая объединяет запись в state store, публикацию в output topic и коммит offset. Либо всё фиксируется, либо всё откатывается.

processing.guarantee=exactly_once_v2

Это ключевое отличие от BPC (глава X), где нужна ручная идемпотентность. В Kafka Streams достаточно включить одну настройку.

XInteractive Queries: state store как замена БД

State store — не только внутренний кэш для обработчика. Его можно читать снаружи через REST API — это заменяет отдельную БД для query-сценариев.

@GetMapping("/customers/{id}/total")
public Long getTotal(@PathVariable String id) {
    ReadOnlyKeyValueStore<String, Long> store = streams.store(
        StoreQueryParameters.fromNameAndType(
            "customer-totals",
            QueryableStoreTypes.keyValueStore()));
    return store.get(id);
}

Это даёт:

• CQRS без внешней БД. Read model живёт прямо в state store.
• Миллисекундный отклик. Нет сети между приложением и хранилищем.
• Автоматическую актуализацию. Состояние обновляется по мере поступления событий.

XIОграничения Kafka Streams

Kafka Streams — не серебряная пуля. Честный разговор об ограничениях:

1. JVM-lock. Только Java/Scala. Для Go/Python/Node.js нужны альтернативы (Faust, Node-rdkafka) или переход на BPC.
2. State store размер. RocksDB растёт бесконечно, нет TTL (KIP-1225 ещё не реализован). Нужна ручная очистка через punctuator (глава VII).
3. Инфраструктурный налог. Нужна Kafka, Schema Registry, Kafka Connect, мониторинг.
4. Нет savepoints. Обновление топологии = reset local state. Альтернатива — новое имя store (глава VII).
5. Co-partitioning не проверяется. Тихие ошибки при несовпадении партиций.
6. Global state. Для больших таблиц не подходит — репликация × N.

XIITesting Kafka Streams

TopologyTestDriver driver = new TopologyTestDriver(topology, config);

TestInputTopic<String, OrderEvent> input = driver.createInputTopic(
    "orders", new StringSerializer(), new OrderEventSerializer());

TestOutputTopic<String, Long> output = driver.createOutputTopic(
    "customer-totals", new StringDeserializer(), new LongDeserializer());

input.pipeInput("order-1", new OrderEvent("cust-42", 150.0));

assertThat(output.readValueToMap()).containsEntry("cust-42", 1L);

driver.close();

XIIIOperational side: метрики и проблемы

Типичные production-проблемы

• Rebalancing deadlock. Агрессивное автомасштабирование → постоянные rebalance (см. главу IX).
• State store growth. RocksDB растёт без TTL — нужен punctuator cleanup.
• Co-partitioning mismatch. Тихие ошибки в JOIN.
• Changelog lag. Восстановление может занять часы.

XIVCosts: Kafka Streams vs BPC vs Flink

XVKSQL и Samza SQL: декларативный streaming

Если ваша команда не хочет писать топологии на Java, индустрия предлагает SQL поверх лёгких библиотек.

-- ksqlDB: session windows для рекламы
CREATE STREAM ad_views (
    userId VARCHAR KEY,
    adId VARCHAR,
    eventTime TIMESTAMP
) WITH (
    KAFKA_TOPIC = 'ad_views',
    VALUE_FORMAT = 'JSON',
    TIMESTAMP = 'eventTime'
);

CREATE TABLE sessions AS
SELECT userId,
       COUNT(*) AS view_count,
       WINDOWSTART AS session_start,
       WINDOWEND AS session_end
FROM ad_views
WINDOW SESSION (30 MINUTES)
GROUP BY userId
EMIT CHANGES;

XVIЧеклисты и связь с циклом

Связь с предыдущими главами

Чеклист выбора Kafka Streams

• Команда пишет на Java/Scala (или готова использовать Faust для Python)
• Backend — Kafka, без планов миграции на другой брокер
• State умеренный (до 50–100 GB на инстанс)
• Нужны stream-table joins для обогащения
• Нужны оконные агрегации (tumbling, hopping, sliding, session)
• Нужна атомарность state + output + offset (exactly_once_v2)
• Нужны Interactive Queries для CQRS
• Готовы к инфраструктурному налогу: Kafka, Schema Registry, Connect, мониторинг
• Готовы к JVM-lock или используете Faust/Node-rdkafka
• Co-partitioning проверен вручную для всех JOIN
• Reimplemented TTL через punctuator для растущих stores
• TopologyTestDriver используется в CI
• Метрики RocksDB, changelog lag, rebalance rate настроены
• Standby replicas включены для критичных сервисов
• Cost сравнён с BPC и Flink для конкретного сценария

Ключевые выводы главы

1. Брокер как фундамент. Kafka берёт на себя shuffle, changelog и HA. Фреймворк — только библиотека.
2. Changelog + checkpoint — механизм восстановления state без внешних хранилищ.
3. Гетерогенное железо — преимущество embedded-модели: NVMe для fraud detection, HDD для аналитики.
4. Hot standby replicas — recovery за секунды вместо минут.
5. Kafka Streams vs Samza: Kafka-only vs pluggable backend.
6. Stream-table joins — killer feature для обогащения в реальном времени.
7. Co-partitioning не проверяется автоматически. GlobalKTable — альтернатива.
8. Windowing из коробки: tumbling, hopping, sliding, session.
9. exactly_once_v2 — атомарность state + output + offset.
10. Interactive Queries — чтение state извне через REST API.
11. Ограничения: JVM-lock, state store size, no savepoints, infrastructure tax.
12. Testing: TopologyTestDriver, EmbeddedKafkaCluster, Testcontainers.
13. Operational: метрики RocksDB, changelog lag, rebalance rate.
14. Costs: между BPC и Flink по операционным расходам.
15. KSQL/ksqlDB — декларативный streaming поверх Kafka Streams.

Глава XII цикла «Событийно-управляемая архитектура». Источники: Apache Kafka, Confluent, Conduktor, практические кейсы production-систем, FinCodeCow experience.