Под batch update вы имеете ввиду случай когда партнер выгружает большой файл и нам его нужно прокачать? Если так то да, но к слову таких партнеров было не много, с большинством удалось договориться на поставку данных в реальном времени.
По цифрам, график на первом слайде вполне реальный :) Там в пике порядка 100 тыс/сек, если брать среднесуточное среднее то порядка 60 тыс/сек
В целом можно было сделать и на Akka, использовать свою реализацию Akka persistence с хранением / чтением состояния в HBase (тут стоило бы оценить сколько оперативной памяти потребуется на хранение всей истории визитов всех активных пользователей).
Мы все же решили отказаться от Akka в пользу простоты и прозрачности решения (тут как раз не хватало экспертизы с Akka, например тогда Akka была еще версии 2.3 и там было довольно много проблем с Akka cluster, например)
Изначально мы разрабатывали описанное в статье решение параллельно со «старым» realtime модулем. Когда новый сегментатор заработал на 100% трафика мы смогли отказаться от решения на Akka. Основное бизнес преимущество новой схемы по сравнению со старой в том, что тут мы каждый раз анализируем все данные пользователя, в старой же схеме в реальном времени анализировалась лишь пользовательская текущая активная сессия, чего не всегда хватало
Да, все верно. Выгрузки партнеров также могут быть как потоковые (прямая поставка в Kafka через различные интеграции) так и периодические выгрузки в виде файлов, эти файлы по приходу так же загружались в Kafka
Под batch update вы имеете ввиду случай когда партнер выгружает большой файл и нам его нужно прокачать? Если так то да, но к слову таких партнеров было не много, с большинством удалось договориться на поставку данных в реальном времени.
По цифрам, график на первом слайде вполне реальный :) Там в пике порядка 100 тыс/сек, если брать среднесуточное среднее то порядка 60 тыс/сек
В целом можно было сделать и на Akka, использовать свою реализацию Akka persistence с хранением / чтением состояния в HBase (тут стоило бы оценить сколько оперативной памяти потребуется на хранение всей истории визитов всех активных пользователей).
Мы все же решили отказаться от Akka в пользу простоты и прозрачности решения (тут как раз не хватало экспертизы с Akka, например тогда Akka была еще версии 2.3 и там было довольно много проблем с Akka cluster, например)