Архитектура потокового рабочего времени в реальном времени

Question

Я работаю над потоковым приложением, используя Spark Streaming, я хочу индексировать свои данные в эластичный поиск.

Мой анализ: Я могу напрямую подталкивать данные от Spark к эластичному поиску, но я чувствую, что в этом случае оба компонента будут плотно соединены.

Если это работа с искровым сердечником, мы можем записать этот вывод в HDFS и использовать logstash, чтобы получить данные из HDFS и подталкивать его к поиску упругой информации.

Решение по мне: Я могу передавать данные из Spark Streaming в Kafka, а из Kafka мы можем читать эти данные с помощью Logstash и нажимать на ES.

Просьба предложить.

Answer 1

Прежде всего, это здорово, что вы продумали разные подходы.

Есть несколько вопросов, которые вы должны спросить, прежде чем приходить к хорошему дизайну:

1. временных шкал? Spark -> ES - это бриз и рекомендуется, если вы начинаете с PoC.
2. Эксплуатационная полоса пропускания? внедрение большего количества компонентов приведет к увеличению операционных проблем. Из моих личных впечатлений, убедившись, что вы искрообразовываете работу, стабильна сама по себе трудоемкая работа. Вы также хотите добавить Kafka, поэтому вам нужно потратить больше времени, пытаясь получить контроль, другие операционные системы правы.
3. Масштаб? Если он будет иметь больший масштаб, наличие постоянной шины сообщений может помочь поглотить противодавление и все еще масштабироваться довольно хорошо.

Если бы у меня было время и дело с крупными масштабами, Spark streaming -> Kafka -> ES выглядит лучшим выбором. Таким образом, когда ваш кластер ES нестабилен, у вас все еще есть возможность воспроизведения Kafka.

Я немного туман на Kafka -> HDFS -> ES, так как это может повлиять на производительность пакетного слоя между Source и Sink. Также, честно говоря, я не знаю, насколько хороша логсташ с HDFS, поэтому не могу комментировать.

Плотная связь является предметом обсуждения. Есть люди, которые возражают против этого, ссылаясь на проблемы повторного использования, но есть также люди, которые спорят об этом, поскольку иногда он может создать более простой дизайн и облегчить рассуждение всей системы. Также расскажите о преждевременных оптимизациях :) У нас были успехи с Spark -> ES непосредственно в умеренных масштабах притока данных. Так что не уменьшайте мощность простейшего дизайна именно так :)