Архитектурные рекомендации для AWS пожарных рукавов или аналогичных объектов при сборе большого количества событий в режиме реального времени - PullRequest
0 голосов
/ 16 апреля 2020

Я хотел бы спросить вас о том, как получить совет относительно обработки многих событий приложения в AWS. Мое приложение отправляет множество различных событий обо всем, что пользователь делал в режиме реального времени. Для сбора этих событий я использую AWS firehose (kinesis) - у меня есть несколько потоков данных, где я делаю sh несколько разных событий. Некоторые события перед сохранением на S3 / Redshift содержат данные, которые я хочу извлечь и сохранить в других базах данных (DynamoDB) или в других файлах S3 - для этого случая я использую лямбду, которая назначается определенному c потоку.

Моя проблема в том, что бизнес добавляет все больше и больше новых событий, которые они должны собирать или что-то делать с данными, и для каждого нового события или «групповых» событий мне нужно создавать отдельный поток данных + s3 / rs / es + lambda для извлечения данных. Кроме того, события на S3 хранятся в одном формате, и невозможно сгруппировать эти события, например, по userId из приложения или даже по имени события в имени файла потока. В идеале s3 с этими событиями должен выглядеть как события / {user_id} / {date} / {имя-события} {timestamp}. json.

Возможно, я неправильно использую пожарный шланг или у меня неправильное представление о firehose в моем случае, возможно, есть другие, более качественные услуги на AWS для моего случая, которые могут дать мне больше контроля. Может быть, простые SQS + лямбды в качестве слушателя на S3 - лучшее решение в этом случае?

Спасибо за любой совет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...