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