阅读两个产品（Firehose和Streams）的文档，听起来像Firehose“接近”实时，在产生消息发送它之间可能有60秒的延迟，而Streams文档没有提到这个潜在的延迟。
有没有人真正了解有关邮件投放时间的任何差异？
[注释]
基于S3事件的缓冲区大小，链接到Firehose FAQ提及延迟。
答案 0 :(得分：1)
使用Kinesis Streams，您可以将处理时间缩短到一秒钟。在我当前的流中，Kinesis部分的延迟似乎是5.5毫秒，使用Lambda函数处理记录的延迟似乎是330毫秒。即批量大小为1，这意味着lambda函数逐个处理记录。
Kinesis Streams可能有点贵。为了节省一些钱，我在另一个流中使用批量大小为500，吞吐量更高。这增加了几分钟的延迟。
Firehose通常便宜得多，但也提供有限的功能。如果您要传输大量数据（超过1 MB /分钟），则可以通过添加缓冲区大小提示将平均处理时间降至60秒以下。
答案 1 :(得分：0)
我确实认为Kinesis Firehose或多或少是缓冲区收集数据，直到缓冲区运行满或其中最旧的消息为N秒（其中N由用户配置;我认为900秒是最大值） ），此时整个缓冲区内容被写入其目的地（例如S3）。与Streams不同，缩放是您无需担心的。
我无法对Kinesis Streams发表评论，因为我没有与他们合作过。但Streams不仅仅是分区键所建议的缓冲区。 Firehose试图解决相同问题的另一种方法，但在处理它的方式/位置上更灵活。
也许这可以用来揭开什么比我更好的神秘面纱:) https://www.sumologic.com/wp-content/uploads/DemystifyingAmazonKinesis_infographic.pdf
答案 2 :(得分：0)
在深入研究之后，我发现Firehose上的缓冲区/时间设置确实增加了额外的延迟。但是，Firehose的用例（至少对我来说）是不正确的。似乎如果你可以允许延迟，Firehose是更简单的前进方式，显然如果你只是为了下游分析而摄取数据。对于实时，Kinesis Streams是前进的方式，因为延迟取决于应用程序。
答案 3 :(得分：0)
这让我感到惊讶，促使我进行调查并报告我的发现。我曾看到 Firehose 在几种架构中用作中间件，在这种情况下，增加一分钟的延迟可能会适得其反。此外，压力下的水压可能误导了我，它更关心的是控制和引导压力。流体动力学总是很难。
<块引用>buffer size and buffer interval
Kinesis Data Firehose 将传入的流数据缓冲到特定大小或一段时间，然后再将其传送到目的地。 缓冲区大小以 MB 为单位，缓冲区间隔以秒为单位。
<块引用>目的地的缓冲区大小和缓冲区间隔
Kinesis Data Firehose 在将传入数据传送到指定目的地之前对其进行缓冲。对于作为您选择的目标的 Amazon S3、Amazon Redshift 和 Splunk，您可以选择 1–128 MiB 的缓冲区大小和 60–900 秒的缓冲区间隔。对于 Amazon Elasticsearch 作为您选择的目的地，您可以选择 1–100 MiB 的缓冲区大小和 60–900 秒的缓冲区间隔。对于 HTTP 端点目的地，包括 Datadog 和 New Relic，您可以选择 1-64 MiB 的缓冲区大小和 60-900 秒的缓冲区间隔。对于 MongoDB Cloud，您可以选择 1-16 MiB 的缓冲区大小和 60-900 秒的缓冲区间隔。