Потоковая аналитика с использованием Apache Kafka

#apache-spark #memory-management #cassandra #apache-kafka

#apache-spark #управление памятью #cassandra #apache-kafka

Вопрос:

Мы собираем потоковые данные с устройства (Android, iOS). Поток данных — websocket -> logstash -> kafka -> spark -> cassandra. Объем оперативной памяти составляет 16 ГБ. Наше приложение основано на платформе OTT, и при потоковой передаче видео оно отправляет события в kafka для целей аналитики. Текущая ситуация такова, что память будет быстро переполнена при параллельном воспроизведении 4 или 5 видеороликов.

В чем может быть проблема? Это какая-либо ошибка конфигурации? Есть ли какой-либо другой лучший подход для наших требований?

1. Вы запускаете все это на одном компьютере с 16 ГБ?

2. ДА. Изначально мы использовали один AWS объемом 16 ГБ, а позже обновили его до 32 ГБ

3. Итак, Kafka, Spark, Cassandra и т.д. Являются распределенными системами. Вы можете масштабировать их для обеспечения устойчивости обоих (что, я надеюсь, вы уже рассматриваете!) но также производительность / пропускная способность по мере необходимости.

4. теперь мы запускаем потоковую передачу kafka и spark на отдельных серверах. Итак, kafka теперь стабилен. Я сомневаюсь, правильно ли я следую архитектуре? Может ли моя система обрабатывать более 10 000 пользовательских действий одновременно с такой архитектурой?

Ответ №1:

Я отвечу на ваш общий вопрос широким ответом.

Является ли Logstash / Kafka / Spark / Cassandra «правильной» архитектурой?

В этом подходе нет ничего особенно плохого. Это зависит от того, какую обработку вы выполняете, и почему вы отправляете ее в Cassandra. Вы найдете множество людей, использующих этот подход, в то время как другие могут использовать другую потоковую обработку, например, потоки Kafka, а также не всегда использовать хранилище данных (поскольку Apache Kafka сохраняет данные) — зависит от того, что потребляет данные впоследствии.

Может ли моя система обрабатывать более 10 000 пользовательских действий одновременно с такой архитектурой?

Да. Нет. Это зависит от слишком многих факторов, чтобы дать ответ. 10 000 пользователей, выполняющих простое действие с небольшими объемами данных, сильно отличаются от 10 000 пользователей, требующих сложной обработки больших объемов данных.

Единственный способ получить ответ на этот вопрос и оценить свой архитектурный выбор в целом — проанализировать поведение вашей системы по мере увеличения [моделируемого] числа пользователей. Появляются ли конкретные узкие места, указывающие на необходимость большего масштаба оборудования или даже выбора другой технологии.