Комментарии 9
Можно (и зачастую нужно) идентификаторы операторам назначать в коде. Они не изменятся при добавлении новых.
Да, именно так. Для stateful-заданий пользовательское указание идентификаторов для каждого оператора является скорее обязательным условием, так как рано или поздно столкнемся с эволюцией приложения.
Более того такое назначение идентификаторов является одним из пунктов чеклиста "Production Readiness Checklist".
В нашем проекте мы построили декораторы, заставляющие разработчиков указывать id при каждой трансформации потока. Если есть интерес, то могу рассказать отдельной статьей
Я сталкивался с задачами стриминга подобного рода, и нам показалось, что несколько секунд разницы между Spark и Flink не стоят того, чтобы добавлять новый стек. А у вас есть какие-то бенчмарки или примеры о заметном снижении эффективности Spark для таких задач?
К сожалению бенчмарки наша команда не делала, но мы полагались на опыт соседних команд, которые проводили сравнение под базовые задачи дедупликации на трафике в ~5-10млн rps. Flink показывал при этом лучшие результаты на одних и тех же ресурсах по latency. При этом нужно учитывать, что в наших задачах важен именно latency. Если сообщение "отдадим" слишком поздно, то оно уже никому не будет нужно.
несколько секунд разницы между Spark и Flink не стоят того, чтобы добавлять новый стек
поддерживаю, если у вас нет подобных требований. Spark может на подобных задачах выдавать latency более секунды, а Flink отработает шустрее благодаря внутренней архитектуре, ориентированной на true-стримминг.
В сравнении с Flink я бы добавил необходимость для Spark очень тонкой настройки, для которой нужны опытные люди. В Flink эта настройка минимальна, а следовательно и порог вхождения ниже. С другой стороны в Spark появился экспериментальный режим Continuous Processing, который обещает минимальную задержку под at-least-once, но у нас нет опыта его использования (если вы использовали - интересно узнать реальные цифры/проблемы/кейсы).
В дополнение могу порекомендовать доклад на SmartData 2023 "Spark Streaming: брать или не брать?", который как раз затрагивает задачи использования Spark, а когда все же лучше глянуть на другие инструменты.
Как минимум в задачах не требующих reduce-части (джойнов, агрегаций и т.д.) будет концептуальная разница. Например, если есть задача читать очень много данных из топика в кафке и писать их, скажем, в hdfs. В этом случае Spark будет запускать "микробатчи" на N тасков (в пределе по количеству партиций в топике) и тут начинаются проблемы. Из-за того, что микробатч - единая сущность, таски не смогут приступить к обработке следующих порций пока ВЕСЬ микробатч не завершится. А это значит, что завершенные таски будут просто стоять и ждать пока не завершатся все остальные. Что на больших объемах будет создавать совершенно лишние тормоза. И это если еще не брать в расчет выполнение в конкурентной среде или с динамическим выделением ресурсов - там ситуация будет еще хуже, т.к. разброс во времени выполнения каждого таска будет увеличиваться. Флинк же обеспечивает "нативный" стриминг, где таски друг друга не ждут
Всем кто хочет попробовать Flink в работе, рекомендую платформу для облачного использования Flink - https://www.ververica.com/cloud + там есть курсы для освоения flink
Кажется, что сравнивать Flink со Spark не совсем корректно… это разные инструменты для разных типов задач… скорее имеет смысл сравнивать Flink с Kafka/Kafka streams…
Отличное описание работы флинка
Введение в Apache Flink: осваиваем фреймворк на реальных примерах