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