#apache-spark #redis #spark-streaming
#apache-spark #redis #spark-streaming
Вопрос:
Мы создаем систему потоковой обработки в реальном времени с spark streaming, которая использует большое количество (миллионы) аналитических моделей, применяемых к RDDs во многих различных типах входящих потоков метрических данных (более 100000). Эти потоки являются исходными или преобразованными потоками. Каждый RDD должен проходить через аналитическую модель для обработки. Поскольку мы не знаем, какой узел кластера spark будет обрабатывать какие конкретные RDD из разных потоков, нам нужно сделать ВСЕ эти модели доступными на каждом вычислительном узле Spark. Это создаст огромные накладные расходы на каждом узле spark. Мы рассматриваем возможность использования сеток данных в памяти для предоставления этих моделей на вычислительных узлах spark. Правильный ли это подход?
Или
Должны ли мы избегать использования Spark streaming все вместе и просто использовать сетки данных в памяти, такие как Redis (с pub / sub), для решения этой проблемы. В этом случае мы будем передавать данные на конкретные узлы Redis, которые содержат конкретные модели. конечно, нам придется выполнять все биннинг / окно и т. Д..
Пожалуйста, предложите.
Ответ №1:
Мне кажется, что вам нужна комбинация механизма потоковой обработки и распределенного хранилища данных. Я бы спроектировал систему следующим образом.
- Распределенное хранилище данных (Redis, Cassandra и т. Д.) Может содержать данные, к которым вы хотите получить доступ со всех узлов.
- Получать потоки данных через комбинированную систему приема данных (Kafka, Flume, ZeroMQ и т. Д.) И обрабатывать их в системе потоковой обработки (Spark Streaming [предпочтительно ;)], Storm и т. Д.).
- В функциях, которые используются для обработки записей потока, необходимые данные должны извлекаться из хранилища данных и, возможно, кэшироваться локально по мере необходимости.
- Вам также может потребоваться обновить хранилище данных из spark streaming по мере необходимости приложения. В этом случае вам также придется беспокоиться о проверке версий данных, которые вы хотите извлечь на шаге 3.
Надеюсь, это имело смысл. Трудно дать какие-либо дополнительные подробности реализации без точной вычислительной модели. Надеюсь, это поможет!
Комментарии:
1. Спасибо Татхагате. Я думаю о подобных линиях. Проблема в пункте номер (3) выше — что кэшировать на каждом локальном узле Spark?. Извлечение данных из Redis при каждом вычислении набора данных на любом узле Spark потребует огромных затрат. Есть ли какой-либо способ направить потоки на определенный набор ИЗВЕСТНЫХ узлов spark? В этом случае я могу кэшировать набор данных, необходимых для этих наборов узлов.
2. Нет хорошего способа направить потоки на определенный узел в кластере Spark. Это связано с тем, что это противоречит философии выполнения детерминированных задач (например, задач сокращения карты), которые должны выполняться на любом узле spark и давать тот же результат. Вам придется кэшировать данные в своем собственном кэше. Может быть, просто одноэлементная потокобезопасная хэш-карта, которая инициализируется по требованию, когда выполняется первая задача, требующая ее.