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

Question

Я смотрю на создание архитектуры для следующего и хотел посмотреть, что другие думают об этом.

Предположим, что система запускает некоторый нетривиальный алгоритм (так что это не просто сумма чего-то и т. Д.) Для данных, собранных для каждого пользователя. У некоторых пользователей будет 10 строк данных, у некоторых будет десятки тысяч. Данные будут представлять собой географические позиции пользователя с течением времени. Было бы более 10-100 миллионов пользователей, и данные о многих пользователях приходили каждый день, потенциально каждую минуту для некоторых.

Периодически (1/5/15 минут, в основном, как можно скорее), я бы хотел запустить этот нетривиальный алгоритм для каждого пользователя, который выдавал бы пару цифр, которые затем будут сообщены вне.

Один из способов моделирования, который должен храниться в базе данных NoSQL и обрабатывать данные каждого пользователя в кластере Akka. Любая рекомендация для БД?

Данные пользователя здесь, в основном, являются журналом добавления, который когда-то был добавлен, данные не будут меняться - но он постоянно растет, а некоторые пользователи имеют непропорционально большее количество данных, чем другие. Чтобы обрабатывать данные для каждого пользователя, все это должно быть загружено в память где-то, поэтому наилучшим возможным сценарием является то, что все данные хранятся в памяти и повторно обрабатываются с интервалом в одну минуту - недостатком является то, что мне нужны терабайты RAM, и если серверы с памятью опускаются, все данные должны быть перезагружены, и это займет некоторое время.

Answer 1

В настоящее время я работаю над аналогичной проблемой. Моя система насчитывает около 35 000 миллионов «записей», каждая запись имеет около 4-5 значений. В настоящее время я могу обрабатывать их (нетривиальная обработка) примерно через 20 часов на одном рабочем столе среднего уровня (6-я ядерная AMD с вращающимися пластинами).

Для хранения я попробовал почти все, начиная с Postgres, переехал в Cassandra, Hypertable. Затем я понял, что мой прецедент связан только с воспроизведением данных в последовательности, без необходимости произвольного доступа либо в записи, либо при чтении. Я нашел Chronicle, и это именно то, что я искал. Поскольку у меня не было достаточного количества ОЗУ для хранения всех данных, мне нужно было все читать с диска, а с хроникой я получил около 800 000 записей в секунду.

Я не знаю текущую версию хроники, но версия, которую я использовал, создала «индексный» файл, который я нашел, был лишним. С тех пор я использую свой собственный код, который является в основном Chronicle (файлы с отображением памяти) без индексного файла, что позволяет мне получать до 1.300.000 записей в секунду на моем довольно среднем диске со скоростью вращения 30 МБ/сек.

Еще один момент для хранения - сжатие данных. Это имеет огромное значение. Я написал сжатие для своих данных: bit aligned (когда я сжимаю значение до 3 бит, он действительно просто пишет 3 бита, а не 8). Я нашел использование сжатия с использованием границ байта на 30-40% хуже (по моим данным). Например, я ожидал бы, что данные GPS от одного человека не будут быстро меняться, поэтому для каждой последовательной точки данных может потребоваться всего несколько бит.

Поскольку мне не нужна обработка в реальном времени, как и вы, моя основная цель заключалась в максимально возможной производительности обработки на одной (или хотя бы на нескольких) машинах. Я попробовал Akka, Hadoop (это всего лишь PITA, не рекомендовал бы его), где играл Apache Spark. Моя проблема заключалась в том, что большинство из них предназначено для работы в большом кластере и не так быстро, как я хочу, на одной машине (или, по крайней мере, я не мог сделать их так быстро, как хотелось).

Я закончил тем, что сам реализовал цепочку обработки, которая, как я уже говорил, составляет около 500 000 записей/секунд обработки с I/O.Поскольку мои данные легко разделяются на независимые осколки, я могу масштабироваться без необходимости координировать узлы.

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

В любом случае, я надеюсь, что это поможет.