amazon-web-services - 使用Kinesis进行事件来源-重放和持久性

Question

我正在尝试使用Amazon Kinesis作为平台的中央事件日志来实现事件驱动的架构。这个想法与Nordstrom's with the Hello-Retail project提出的想法几乎相同。

以前我曾用Apache Kafka做过类似的事情，但Kinesis似乎是Kafka的一种经济高效的替代品，因此我决定尝试一下。但是，我面临一些与事件持久性和重播有关的挑战。我有两个问题:

你们在这种情况下使用Kinesis吗？还是建议您使用它？

由于Kinesis无法永远保留事件(就像Kafka一样)，如何处理消费者的重放？

我当前正在使用lambda函数(Firehose也是一个选项)将所有事件持久化到Amazon S3。然后，人们可以从存储中读取过去的事件，然后开始监听来自流的新事件。但是我对这种解决方案不满意。消费者无法使用Kinesis的检查点(Kafka的消费者补偿)。另外，Java的 KCL does not support the AFTER_SEQUENCE_NUMBER yet，在这种实现中将很有用。

Answer 1

第一个问题。是的，当我需要在存储到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，然后使用各种工具提取所需的数据。通过这样做，我消除了许多需要管理的故障点。