Предотвращение потери данных, когда медленные потребители вызывают обратное давление при потоковой обработке (spark, aws).

«Есть ли более стандартное решение для потоковой передачи?» — Возможно. Есть много разных способов сделать это, не сразу понятно, есть ли еще «стандарт». Это всего лишь мнение, и вы вряд ли получите конкретный ответ на эту часть.

«Так ли это просто на практике?» — у SQS и Kinesis разные шаблоны использования:

• Use SQS if you want to always process all messages, AND have a single logical consumer
  • think of this like a classic queue where messages need to be "consumed" from the queue.
  • определенно более простая модель для понимания и использования, но по сути она действует как буфер
• Use Kinesis if you want to easily skip messages, OR have multiple logical consumers
  • think of this like a stream with 'skip' functionality, where multiple consumers can be at different points in the stream, or filtering to consume specific message types
  • требует больше усилий для использования, но предоставляет больше возможностей для использования сообщений и борьбы с обратным давлением
  • обратите внимание, что (по умолчанию) Kinesis отбрасывает данные в стрим, если он старше 24 часов, хотя его можно увеличить до 7 дней

Для вашего случая использования, когда у вас есть «огромный объем входящих данных в реальном времени, которые не могут быть немедленно обработаны», я бы сосредоточил ваши усилия на Kinesis, а не на SQS, поскольку модель Kinesis также лучше согласуется с другими потоковыми механизмами, такими как Spark/Kafka. .