AWS Kinesis Firehose 和 Streams 的处理时间有什么不同吗？

Question

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

有没有人对消息传递时间方面的任何差异有任何实际见解？

[笔记]

Link to Firehose FAQ mentioning the delay, based on buffer size for S3 events.

Answer 1

借助 Kinesis Streams，您可以将处理时间缩短至不到一秒。在我当前的流中，Kinesis 部分的延迟似乎为 5.5 毫秒，使用 Lambda 函数处理记录的延迟为 330 毫秒。即批量大小为 1，这意味着 lambda 函数会一条一条地处理记录。

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

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

Answer 2

在我看来，Kinesis Firehose 或多或少是一个收集数据的缓冲区，直到缓冲区已满或其中最旧的消息已存在 N 秒（其中 N 由用户配置；我认为 900 秒是最大值），在此时整个缓冲区内容将被写入其目的地（例如 S3）。与 Streams 不同，您无需担心扩展。

我无法对 Kinesis Streams 发表太多评论，因为我没有有效地使用它们。但 Streams 不仅仅是分区键所建议的缓冲区。Firehose 正在尝试解决同一问题的不同方法，但处理方式/位置更加灵活。