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

На сцену выходят «тяжеловесные» фреймворки потоковой обработки — Apache Spark, Apache Flink, Apache Storm и Apache Beam. Они не просто обрабатывают события; они управляют целыми распределёнными кластерами, обеспечивая беспрецедентную масштабируемость и отказоустойчивость. Но за эту мощь приходится платить — архитектурной сложностью.

Это одиннадцатая глава цикла. Она опирается на главу V (watermarks, windowing), главу VI (event time), главу VII (state stores, RocksDB, checkpoint), главу IX (FaaS как противоположный полюс) и главу X (BPC как минимализм). Здесь мы замыкаем спектр: от простейшего poll-process-produce до распределённых титанов Big Data.

IНаследие пакетной обработки: от Hadoop к real-time

Чтобы понять философию «тяжеловесных» фреймворков, нужно взглянуть на их историю. Они родились из эпохи пакетной обработки (Apache Hadoop и MapReduce), когда объёмы данных выросли настолько, что их невозможно было обработать на одном сервере. Инженерам понадобились инструменты для массового параллелизма, распределённого хранения и автоматического восстановления после сбоев тысяч узлов.

Со временем запросы сместились от ночных пакетных заданий к аналитике в режиме, близком к реальному времени. Так появились Spark Streaming, Flink и Storm. Они унаследовали кластерную архитектуру предков, но адаптировали её для непрерывного потребления событий из брокеров.

IIВнутренняя анатомия: Master, Worker и Zookeeper

Главная отличительная черта «тяжеловесного» фреймворка — наличие независимого выделенного кластера. Архитектура разделена на две основные роли:

Для координации и обеспечения высокой доступности (HA) исторически использовался Apache Zookeeper. Он решает, какой узел является главным, если текущий Master выходит из строя. Современные фреймворки учатся обходиться без него: Flink использует Kubernetes HA, Spark — Zookeeper или встроенный recovery mode.

IIISpark vs Flink: две разные модели

Многие ставят Spark и Flink в один ряд как «движки потоковой обработки». Но у них принципиально разные модели, и это критично для выбора.

IVПлюсы и минусы: цена мощи

Сильные стороны

1. Аналитическая мощь. Идеальны для ETL, сложного сеансового анализа, выявления аномалий и агрегации с поддержкой состояния.
2. Зрелость экосистемы. Огромное сообщество, отличная документация, интеграция с Data Lakes (Iceberg, Delta, Hudi).
3. Масштаб. Способны обрабатывать миллионы событий в секунду, распределяя нагрузку на сотни узлов.
4. Event time и watermarks. Полноценная работа с запоздалыми событиями, idle sources, allowed lateness.
5. SQL на потоках. Flink SQL и Spark SQL позволяют писать streaming jobs декларативно.

Слабые стороны (в контексте микросервисов)

1. Операционный «налог». Отдельный кластер, мониторинг, алертинг, выделение ресурсов — дублирование функций CMS и брокера событий.
2. JVM-лок (для классических версий). Привязка к Java/Scala ограничивает выбор языков для команд.
3. Сложность материализации. Глобальные JOIN и бесконечная материализация потоков в таблицы часто реализованы, но плохо документированы.
4. Startup time. Развёртывание кластера — минуты, а не секунды. Не подходит для FaaS-парадигмы.
5. Стоимость при простое. Кластер работает 24/7, даже если нет событий.

VЭволюция развёртывания: от «голого железа» до Kubernetes

То, как вы развёртываете «тяжеловесный» фреймворк, определяет, насколько хорошо он впишется в вашу микросервисную архитектуру. Существует три основных пути:

VIМагия выживания: checkpointing и два типа state

В распределённой системе сбои — норма. «Тяжеловесные» фреймворки решают это через механизм контрольных точек (checkpoints): моментальные снимки состояния приложения, периодически сохраняемые в надёжное хранилище (HDFS, S3).

При сбое узла Master восстанавливает задачу на новом рабочем узле, загружая последнюю контрольную точку. Фреймворк синхронизирует два типа состояния:

Связь с главой VII: в Kafka Streams аналогом checkpoint является changelog topic. Во Flink — checkpoint в S3/HDFS. Это два разных подхода к одной задаче: сохранение state для восстановления после сбоя.

VIIExactly-once и two-phase commit

Flink предоставляет exactly-once через checkpointing + two-phase commit для external sinks. Это принципиально отличается от Kafka Streams exactly_once_v2:

VIIIWatermarks и event time: связь с главой VI

Watermarks — ключевое отличие тяжёлых фреймворков от BPC и FaaS. Это механизм определения «прошлое прошло»:

WatermarkStrategy.<Event>forBoundedOutOfOrderness(
        Duration.ofSeconds(30))
    .withTimestampAssigner((event, ts) ->
        event.getOccurredAt().toEpochMilli())
    .withIdleness(Duration.ofMinutes(5));

• forBoundedOutOfOrderness — допускаем опоздание до 30 секунд.
• withTimestampAssigner — откуда берём event time.
• withIdleness — если источник замолчал 5 минут, исключаем его из watermark.

Flink предоставляет полную поддержку того, что в главе VI обсуждалось для Kafka Streams: watermarks, allowed lateness, idle sources, watermark alignment. Разница — в уровне абстракции и мощности: Flink работает с сотнями источников одновременно.

IXShuffle и External Shuffle Service (ESS)

Самая большая боль при масштабировании stateful-приложений — операция shuffle. Когда вы группируете данные по ключу (groupByKey), события с одинаковыми ключами должны физически попасть на один рабочий узел.

Если вы добавляете или удаляете рабочие узлы «на лету», данные, которые уже были перемешаны старыми узлами, могут стать недоступны для новых. Исторически это решалось либо остановкой приложения, либо использованием External Shuffle Service (ESS) — выделенного хранилища, которое буферизует данные между задачами.

XFlink 2.0: disaggregated state (ForSt)

Flink 2.0 (март 2025) представил disaggregated state backend (ForSt): состояние живёт в remote object storage (S3), а не на локальном диске TaskManager. State pages in/out по мере необходимости.

Что это даёт:

• Decouples state size от диска. Не нужно выделять SSD под каждый TaskManager.
• Ускоряет rescaling. TaskManagers просто начинают читать другие key partitions из S3.
• Упрощает эксплуатацию. State — это просто объекты в S3, а не тома на локальных дисках.

Trade-offs:

• Latency. Page in/out из S3 занимает десятки миллисекунд, а не микросекунды, как локальный RocksDB.
• Стоимость. Оплата за S3 API calls + storage.
• Не для всех workloads. Для latency-sensitive задач (real-time fraud detection) лучше embedded RocksDB.

Связь с главой VII: Flink 2.0 ForSt — это эволюция того же подхода, что обсуждался для Kafka Streams (внутренний vs внешний state). Разница — в уровне абстракции.

XIFlink SQL и Spark SQL: декларативный streaming

Современное развитие тяжёлых фреймворков — SQL на потоках. Flink SQL и Spark SQL позволяют писать streaming jobs декларативно, без Java/Scala кода.

-- Flink SQL: session windows для рекламы
SELECT
    userId,
    COUNT(*) AS view_count,
    SESSION_START(eventTime, INTERVAL '30' MINUTE) AS session_start,
    SESSION_END(eventTime, INTERVAL '30' MINUTE) AS session_end
FROM ad_views
GROUP BY
    userId,
    SESSION(eventTime, INTERVAL '30' MINUTE);

Это радикально снижает порог входа: аналитики и data engineers могут писать streaming jobs без знания Java API. SQL становится языком для ETL и аналитики в реальном времени.

XIITesting тяжёлых jobs

Как тестировать Flink job без production кластера?

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

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

• Checkpoint timeout. State слишком большой или диск медленный.
• Backpressure. Один оператор медленнее остальных — весь pipeline ждёт.
• Task skew. Одни partitions получают больше событий — нужен rebalance.
• Watermark stagnation. Idle source замораживает watermark (см. главу VI).

XIVCosts: managed vs self-hosted

XVСравнение Flink vs Spark vs Beam vs Storm

XVIПрактический пример: session windows для рекламы

Представьте, что нужно объединить потоки «Просмотров рекламы» и «Кликов по рекламе» для расчёта конверсии в сеансовом окне: если пользователь не кликает и не смотрит рекламу 30 минут, сеанс закрывается.

DataStream<Event> clickStream = ...;
DataStream<Event> viewStream = ...;

clickStream
    .union(viewStream)                          // 1. Объединяем потоки
    .keyBy(e -> e.getUserId())                  // 2. Группируем по пользователю (shuffle)
    .window(EventTimeSessionWindows
        .withGap(Time.minutes(30)))             // 3. Сеансовое окно
    .aggregate(new SessionAggregator())         // 4. Агрегация
    .addSink(producerToKafka);                  // 5. Результат в Kafka

Фреймворк берёт на себя управление state окон, watermarks и обработкой запоздалых событий. Разработчику остаётся только описать бизнес-логику агрегатора.

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

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

Чеклист выбора тяжёлого фреймворка

• Есть ли реальная потребность в обработке > 100k msg/s?
• Нужны ли watermarks и event-time с точностью до миллисекунд?
• Нужны ли сложные JOIN трёх и более потоков?
• Нужна ли интеграция с Data Lake (Iceberg, Delta, Hudi)?
• Есть ли команда с экспертизой Big Data (Flink/Spark)?
• Готовы ли выделить SRE-команду для эксплуатации кластера?
• Выбран ли Flink (true streaming, low latency) или Spark (micro-batch, analytics)?
• Решён ли вопрос развёртывания: managed vs K8s operator vs standalone?
• Настроены ли checkpoints, HA, monitoring?
• Настроен ли state backend: RocksDB или ForSt (S3)?
• Настроен ли exactly-once с transactional sinks?
• Настроены ли watermarks, idle sources, allowed lateness?
• Есть ли тесты через MiniCluster / TestHarness?
• Настроены ли алерты на checkpoint failures, backpressure, skew?
• Оценена ли стоимость managed vs self-hosted?

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

1. Тяжёлые фреймворки — это не замена микросервисам. Это мощный бэкенд для сложных аналитических задач.
2. Spark vs Flink — разные модели. Spark — micro-batch, Flink — true streaming. Выбор зависит от latency-требований.
3. Checkpointing синхронизирует operator state (offsets) и keyed state (агрегаты).
4. Exactly-once во Flink — через checkpoint + two-phase commit для external sinks.
5. Watermarks — полная поддержка event time, idle sources, allowed lateness.
6. Shuffle — физическое перемещение данных по ключу. ESS или динамическое масштабирование без ESS.
7. Flink 2.0 ForSt — state в S3, decoupling от локальных дисков TaskManager.
8. Flink SQL / Spark SQL — декларативный streaming для аналитиков.
9. Testing — MiniCluster, TestHarness для unit и integration тестов.
10. Operational — метрики checkpoint, backpressure, skew; типичные production-проблемы.
11. Costs — managed vs self-hosted, trade-offs.
12. Kubernetes integration — современный золотой стандарт. Flink/Spark на K8s — managed workloads.

Глава XI цикла «Событийно-управляемая архитектура». Источники: Apache Flink, Apache Spark, Apache Beam, Apache Storm, Confluent, Databricks, практические кейсы production-систем.