AWS Kinesis Firehose和Streams在处理时间上有任何不同吗？

Question

通过阅读两种产品（Firehose和Streams）的文档，听起来Firehose实时“接近”，在产生消息和发布消息之间可能会有60秒的延迟，而Streams文档没有提到这种潜力延迟。

有没有人有任何关于消息传递时间差异的现实洞察？

[注释]

链接到Firehose FAQ提的延迟，根据缓冲器大小为S3事件。

Answer 1

它看起来像我一样Kinesis Firehose是或多或少的缓冲区收集数据，直到缓冲区运行完整或其中最旧的消息是N秒（其中N由用户配置;我认为900秒是最大），此时整个缓冲区内容被写入其目的地（例如S3）。与Streams不同，缩放无需担心。

我无法对Kinesis Streams做出相当评论，因为我没有与他们合作过。但Streams不仅仅是分区键所建议的缓冲区。对于Firehose正在尝试解决的同一问题采用不同的方法，但在处理它的方式/位置方面更加灵活。

也许这将是任何使用的神秘性什么是什么更好的比我可以:) https://www.sumologic.com/wp-content/uploads/DemystifyingAmazonKinesis_infographic.pdf

Answer 2

挖掘到这进一步后，我发现，在流水中，缓冲器/时间设置确实添加额外的延迟。然而，Firehose的用例（至少对我来说）并不正确。看起来，如果您可以允许延迟，那么Firehose就是更简单的方法，显然如果您只是为了下游分析而采集数据。对于实时，Kinesis Streams是前进的方向，因为延迟取决于应用程序。

Answer 3

通过Kinesis Streams，您可以将处理时间缩短到一秒以内。在我目前的流中，Kinesis部分的延迟似乎为5.5毫秒，而用Lambda函数处理记录的延迟为330毫秒。这是批量大小为1，这意味着lambda函数处理记录一个接一个。

Kinesis Streams可能有点贵。为了节省一些资金，我在另一个具有更高吞吐量的流中使用了批量大小500。这增加了几分钟的延迟时间。

Firehose通常便宜很多，但功能也有限。如果您正在传输大量数据（超过1 MB /分钟），则可以通过添加缓冲区大小提示将平均处理时间降至60秒以下。