我正在尝试使用 Amazon Kinesis 作为平台的中央事件日志来实施事件驱动架构。这个想法与Nordstrom 在 Hello-Retail 项目中提出的想法几乎相同。
我以前用 Apache Kafka 做过类似的事情，但 Kinesis 似乎是 Kafka 的一种具有成本效益的替代品，我决定试一试。然而，我面临着一些与事件持久性和重放相关的挑战。我有两个问题：
我目前正在使用 lambda 函数（Firehose 也是一个选项）将所有事件持久保存到 Amazon S3。然后，可以从存储中读取过去的事件，然后开始监听来自流的新事件。但我对这个解决方案不满意。消费者无法使用 Kinesis 的检查点（Kafka 的消费者偏移量）。另外，Java 的KCL 还不支持 AFTER_SEQUENCE_NUMBER，这在这种实现中会很有用。
第一个问题。是的，当我需要在存储到 S3 之前处理接收到的日志/事件数据时，我正在使用 Kinesis Streams。当我不使用 Kinesis Firehose 时。
第二个问题。Kinesis Streams 最多可以存储 7 天的数据。这不是永远的，但应该有足够的时间来处理您的事件。取决于正在处理的事件的值......
如果我不需要在存储到 S3 之前处理事件流，那么我使用 Kinesis Firehose 写入 S3。现在我不必担心事件失败、持久性等。然后我用最好的工具处理存储在 S3 中的数据。我经常使用 Amazon Athena 和 Amazon Redshift。
您没有提及您正在处理多少数据或如何处理它。如果它很大，多 MB/秒或更高，那么我肯定会使用 Kinesis Firehose。您必须使用 Kinesis Streams 管理性能。
我对 Kinesis Streams 的一个问题是我不喜欢客户端库，因此我更喜欢自己编写所有内容。Kinesis Firehose 减少了自定义应用程序的编码，因为您只需将数据存储在 S3 中，然后再进行处理。
我喜欢将 S3 视为我的大数据湖。我更喜欢将所有内容都放入 S3 而不进行预处理，然后使用各种工具提取我需要的数据。通过这样做，我消除了许多需要管理的故障点。