AWS Kinesis Firehose和Streams在处理时间上有区别吗？

Question

阅读两种服务（Firehose 和 Streams）的文档后，听起来 Firehose 是“接近”实时的，可能在产生消息到发射之间有 60 秒的延迟，而 Streams 的文档没有提到这个潜在的延迟。请问有没有任何现实世界的见解，关于消息传递时间方面的差异？

【注】链接到 Firehose FAQ，提到基于 S3 事件缓冲区大小的延迟。

- Joshua Hansen

Answer 1

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

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

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

- Heikki Pulkkinen

Answer 2

这让我感到惊讶，促使我进行调查并报告我的发现。我曾看到Firehose在几种架构中被用作中间件，增加一分钟的延迟可能似乎是适得其反的。此外，水压下的压力可能会误导我，它更关注于包含和引导这种压力。流体动力学总是很难的。

缓冲区大小和缓冲区间隔

Kinesis Data Firehose将传入的流数据缓冲到一定大小或一定时间后再将其传递到目的地。缓冲区大小以MB为单位，缓冲区间隔以秒为单位。

来自什么是Firehose？

目标缓冲区大小和缓冲区间隔

Kinesis Data Firehose在将传入数据传输到指定的目的地之前对其进行缓存。 对于您选择的 Amazon S3、Amazon Redshift 和 Splunk 作为目的地，您可以选择 1-128 MiB 的缓冲区大小和 60-900 秒的缓冲区间隔。对于您选择的 Amazon Elasticsearch 作为目的地，您可以选择 1-100 MiBs 的缓冲区大小和 60-900 秒的缓冲区间隔。对于包括 Datadog 和 New Relic 在内的 HTTP 终端点目的地，您可以选择 1-64 MiBs 的缓冲区大小和 60-900 秒的缓冲区间隔。对于 MongoDB Cloud，您可以选择 1-16 MiBs 的缓冲区大小和 60-900 秒的缓冲区间隔。

来自配置设置。

- John

Answer 3

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

我不能完全评论 Kinesis Streams，因为我没有生产性地使用过它们。但是，Streams 比分区键所建议的缓冲区要复杂得多。这是解决 Firehose 尝试解决的同一问题的不同方法，但在处理方式/位置方面更加灵活。

也许这会比我更好地澄清什么是什么 :) https://www.sumologic.com/wp-content/uploads/DemystifyingAmazonKinesis_infographic.pdf

- Manny

Answer 4

深入研究后，我发现Firehose上的缓冲区/时间设置确实会增加额外的延迟。然而，对于我来说，Firehose的使用情况并不正确。如果您可以接受延迟，那么Firehose是更简单的选择，当然，如果您只是为了下游分析而摄取数据。对于实时处理，Kinesis Streams是前进的方向，因为延迟取决于应用程序。

- Joshua Hansen