Не думаю, что кто-то может сказать: «Да, Framework X определенно может справиться с вашей рабочей нагрузкой», потому что это во многом зависит от того, что вам нужно от обработки сообщений, например относительно надежности обмена сообщениями и того, как ваши потоки данных могут быть разделены.
Вы можете быть заинтересованы в BenchmarkingDistributedStreamProcessingEngines . В статье используются версии Storm / Flink / Spark, которым несколько лет (похоже, они были выпущены в 2016 году), но, может быть, авторы захотят позволить вам использовать их тест для оценки более новых версий трех платформ?
Очень распространенная установка для потоковой аналитики - использовать источник данных -> Kafka / Pulsar -> аналитическая среда -> долговременное хранилище данных. Это позволяет отделить обработку от загрузки данных и позволяет выполнять такие вещи, как повторная обработка исторических данных, как если бы они были новыми.
Я думаю, что первым шагом для вас должно быть выяснить, сможете ли вы получить необходимый объем данных через Kafka / Pulsar. Либо создайте набор тестов вручную, либо извлеките некоторые данные, которые, по вашему мнению, могут быть репрезентативными для вашей производственной среды, и посмотрите, сможете ли вы передать их через Kafka / Pulsar с необходимой вам пропускной способностью / задержкой.
Не забудьте рассмотреть возможность разделения ваших данных. Если некоторые из ваших потоков данных могут быть обработаны независимо (т.е. порядок не имеет значения), вам не следует помещать их в одни и те же разделы. Например, вероятно, нет причин смешивать измерения датчиков и потоки видеопотока. Если вы можете разделить ваши данные на независимые потоки, вы с меньшей вероятностью столкнетесь с узкими местами как в Kafka / Pulsar, так и в аналитической среде. Отдельные потоки данных также позволят вам намного лучше распараллелить обработку в аналитической среде, например, вы можете запустить, например, подача видео и обработка сенсора на разных машинах.
Как только вы узнаете, можете ли вы получить достаточную пропускную способность через Kafka / Pulsar, вы должны написать небольшой пример для каждой из 3 платформ. Для начала я бы просто получил и отбросил данные из Kafka / Pulsar, которые должны сообщить вам заранее, есть ли узкое место на пути аналитики Kafka / Pulsar ->. После этого вы можете расширить пример, чтобы сделать что-то интересное с данными примера, например, сделайте немного обработки, как то, что вы, возможно, захотите сделать в производстве.
Вам также необходимо учитывать, какие виды обработки вам необходимы для ваших потоков данных. Как правило, вы платите штраф за производительность за гарантированную обработку по крайней мере один раз или ровно один раз. Для некоторых типов данных (например, видеопотока) иногда может быть уместно терять сообщения. Выбрав необходимую гарантию, вы можете соответствующим образом настроить аналитические структуры (например, отключить взлом в Storm) и попробовать сравнительный анализ своих тестовых данных.
Просто, чтобы ответить на некоторые ваши вопросы более четко:
Случай использования анализа / мониторинга данных в реальном времени звучит так, как будто он достаточно хорошо подходит для систем Storm / Flink. Подключите его непосредственно к Kafka / Pulsar, а затем сделайте любую аналитику, которая вам нужна, звучит так, как будто она может работать для вас.
Повторная обработка исторических данных будет зависеть от того, какие запросы вам нужно делать. Если вам просто нужен временной интервал + идентификатор, вы, вероятно, можете сделать это с помощью Kafka плюс фильтр или соответствующее разбиение. Kafka позволяет начать обработку с определенной временной отметки, и если ваши данные разделены по идентификатору или вы фильтруете их в качестве первого шага в своей аналитике, вы можете начать с предоставленной временной отметки и прекратить обработку, когда нажмете сообщение вне временного окна. Это применимо только в том случае, если временная метка, которая вас интересует, - это когда сообщение было добавлено в Kafka. Я также не верю, что Kafka поддерживает разрешение менее миллисекунды для генерируемых временных отметок.
Если вам нужно выполнить более сложные запросы (например, вам нужно посмотреть на временные метки, сгенерированные вашими датчиками), вы можете посмотреть, используя Cassandra или Elasticsearch или Solr как ваше постоянное хранилище данных.Вы также захотите выяснить, как вернуть данные из этих систем обратно в вашу аналитическую систему.Например, я считаю, что Spark поставляется с соединителем для чтения из Elasticsearch, в то время как Elasticsearch предоставляет соединитель для Storm.Вы должны проверить, существует ли такой соединитель для вашей комбинации хранилища данных и аналитической системы, или быть готовым написать свой собственный.
Редактировать: Обрабатывать, чтобы ответить на ваш комментарий.
Я не знал, чтоKafka или Pulsar поддерживают временные метки, указанные пользователем, но, несомненно, они оба do .Я не вижу, что Pulsar поддерживает временные метки менее миллисекунды, хотя?
Идея, которую вы описываете, определенно может быть поддержана Кафкой.
Вам нужна возможность запустить клиента Kafka / Pulsar в определенное время и читать вперед.Похоже, Pulsar пока не поддерживает это, но Кафка поддерживает.
Вы должны гарантировать, что когда вы записываете данные в раздел, они поступают в порядке отметки времени.Это означает, что вам не разрешено, например, написать первое сообщение 1 с отметкой времени 10, а затем сообщение 2 с отметкой времени 5.
Если вы можете быть уверены, что пишете сообщения для Кафки, описанный вами пример будет работать,Затем вы можете сказать: «Начните с метки времени« прошлой ночью в полночь », и Кафка начнет там.Когда поступают живые данные, они получат их и добавят в конец своего журнала.Когда потребительская / аналитическая инфраструктура прочитает все данные с последней полуночи до текущего времени, она начнет ждать поступления новых (живых) данных и обрабатывает их по мере поступления. Затем вы можете написать собственный код в своей аналитической среде дляубедитесь, что он останавливает обработку, когда достигает первого сообщения с отметкой времени «завтра вечером».
Что касается поддержки меток времени менее миллисекунды, я не думаю, что Кафка или Пульсар будут поддерживать их из коробки, но вы можете обойти это достаточно легко.Просто добавьте метку времени менее миллисекунды в сообщение в качестве настраиваемого поля.Если вы хотите начать, например, с отметки времени 9 мс 10 нс, вы просите Kafka начать с 9 мс и использовать фильтр в среде аналитики, чтобы отбрасывать все сообщения между 9 мс и 9 мс 10 нс.