Выбор потоковой системы зависит от модели выполнения, состояния и допустимого ожидания. Объясняем Spark и Flink с учётом Real-time Mode, без рейтинга скорости.
Сначала определить, когда нужен ответ
Представим условный сервис доставки. Руководителю достаточно регулярно обновляемого счётчика заказов, а оператору нужен сигнал о задержке конкретного курьера вскоре после события. Оба результата используют поток сведений, но допустимое ожидание различается. До выбора системы полезно назвать действие пользователя и срок, после которого информация теряет для него смысл.
Spark и Flink — системы обработки данных, которые поддерживают потоковые задачи. Старое противопоставление «Spark работает только порциями, Flink только по событиям» слишком грубо для актуального сравнения. На официальной странице Spark Structured Streaming представлены микропакетное выполнение и Real-time Mode. Поэтому при обсуждении нужно указывать не только продукт, но и выбранный режим, версию и поддерживаемые возможности.
Микропакет объединяет поступившие сведения
При микропакетном подходе поток рассматривается как последовательность небольших порций. Обработка очередной порции обновляет результат. Для условного счётчика заказов такой способ может подходить, если его фактическая задержка соответствует ожиданиям пользователя. Подробный принцип разобран в статье о микропакетах Structured Streaming. Здесь важно сравнить его с другим способом организации выполнения.
Real-time Mode в Spark предназначен для непрерывного выполнения определённых потоковых задач. В текущем официальном обзоре отдельно указаны ограничения поддерживаемых источников, операций и приёмников результата. Наличие режима не означает, что любое существующее вычисление автоматически станет подходить для него. Также нельзя обещать конкретное время ответа только по названию режима: требуется проверка полного пути события.
Flink строится вокруг потоков и состояния
В обзоре архитектуры Flink система описана как обработчик ограниченных и неограниченных потоков. Неограниченный поток продолжает поступать без заранее известного конца, поэтому нельзя ждать появления всех будущих событий. Обработка должна работать по мере поступления. Ограниченный набор тоже может обрабатываться Flink, поэтому называть его инструментом исключительно для бесконечного потока неверно.
Многие задачи требуют состояния — сохранённого контекста прошлых событий. Для нашего курьера это могут быть сведения о предыдущей отметке и незавершённой доставке. При новом событии система использует этот контекст. Сам принцип не является исключительной особенностью Flink: сравнение должно учитывать, какие конкретно вычисления нужны и какие возможности выбранный режим каждой системы предоставляет для них.
Восстановление — часть сравнения, а не приложение к нему
В документации Flink о состоянии восстановление связывается с контрольными снимками и повторным чтением потока. Снимок сохраняет согласованную точку обработки. Для нужных гарантий важны настройки и возможность источника вернуться к соответствующим событиям. Свойства восстановления нельзя считать включёнными и достаточными только потому, что выбрано известное название продукта.
Для условного сигнала предложим проверить остановку между чтением события и передачей результата. Что будет после восстановления: сигнал потеряется, повторится или будет обработан согласованным способом? Ответ зависит и от приёмника. Корректное внутреннее состояние системы ещё не доказывает отсутствие повторного внешнего действия. Поэтому в сравнении нужен описанный сценарий сбоя, а не одна строка о надёжности.
Низкая задержка не заменяет правила времени
Если событие пришло поздно, быстрая обработка сама по себе не определяет, как изменить итог прошлого периода. Для нашего сервиса нужно согласовать, к какому моменту относится событие и когда результат считается достаточно полным. Общее различие задач раскрывает материал о пакетной и потоковой обработке. Ни выбор Spark, ни выбор Flink не отменяет этих договорённостей.
Для сравнения двух вариантов возьмём одинаковые события, включая опоздания, всплеск поступления и восстановление. Проверим правильность результата, фактическое ожидание пользователя, расход ресурсов и сложность поддержки. Здесь нет измеренного теста и универсального победителя по цене или скорости. Существующая инфраструктура и опыт команды тоже должны войти в описание условий, чтобы сравнивались полные решения.
Что изучать дальше
Запишите одну потоковую задачу: событие, нужный контекст, ожидаемое действие и допустимое ожидание. Затем уточните поддержку этих требований в конкретных версиях и режимах инструментов. Для изучения Spark посмотрите программу «PySpark для инженеров и аналитиков данных». Это направление обучения, а не заявление о том, что любой режим доступен в любом окружении.
