Kinesis的事件采购 - 重播和持久性

Question

我正在尝试使用Amazon Kinesis作为平台的中央事件日志来实现事件驱动的体系结构.这个想法与Nordstrom与Hello-Retail项目提出的想法非常相似.

我之前和Apache Kafka做过类似的事情,但是Kinesis似乎是Kafka的一个经济有效的替代品,我决定试一试.但是,我面临着与事件持久性和重放相关的一些挑战.我有两个问题:

1. 你们是使用Kinesis这样的用例还是你推荐使用它？
2. 由于Kinesis无法永久保留事件(如Kafka所做的那样),如何处理来自消费者的重播？

我目前正在使用lambda函数(Firehose也是一个选项)将所有事件持久保存到Amazon S3.然后,可以从存储中读取过去的事件,然后开始收听来自流的新事件.但我对这个解决方案不满意.消费者无法使用Kinesis的检查点(Kafka的消费者抵消).另外,Java的KCL还不支持AFTER_SEQUENCE_NUMBER,这在这种实现中很有用.

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 中而不进行预处理，然后使用各种工具提取我需要的数据。通过这样做，我消除了许多需要管理的故障点。