Amazon web services AWS Kinesis消防水带和溪流之间的处理时间是否有差异？

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

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

[Notes]

---

链接到提及延迟，基于S3事件的缓冲区大小。

在我看来，Kinesis Firehose或多或少是一个收集数据的缓冲区，直到缓冲区满了，或者其中最旧的消息有N秒（其中N由用户配置；我认为最大值为900秒），在这一点上，整个缓冲区内容被写入其目的地（如S3）。与流不同的是，缩放不需要担心

我不能很好地评论动觉流，因为我没有有效地使用它们。但流不仅仅是分区键所建议的缓冲区。Firehose正在尝试解决同一问题的不同方法，但在处理方式/地点上更灵活

---

也许这有助于揭开比我更好的东西的神秘面纱：）

深入研究后，我发现Firehose上的缓冲区/时间设置确实增加了额外的延迟。然而，Firehose的用例（至少对我来说）是不正确的。似乎如果您同意允许延迟，Firehose是一种更简单的方法，显然如果您只是接收数据进行下游分析。就实时而言，Kinesis Streams是前进的方向，因为延迟取决于应用程序。

使用Kinesis Streams，您可以将处理时间缩短到1秒以下。在我当前的流中，对于运动部分，延迟似乎是5.5毫秒，对于使用Lambda函数处理记录，延迟似乎是330毫秒。即批处理大小为1，这意味着lambda函数逐个处理记录

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

---

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

这让我感到惊讶，导致我进行调查，并报告我的发现。我曾看到Firehose在一些体系结构中被用作中间人，增加一分钟的延迟可能会适得其反。另外，水在压力下的压力可能误导了我，它更关心的是控制和引导压力。流体动力学总是很难

缓冲区大小和缓冲区间隔

Kinesis Data Firehose将传入的流式数据缓冲到一定大小或一定时间段，然后再将其发送到目的地缓冲区大小以MBs为单位，缓冲区间隔以秒为单位

从

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

Kinesis Data Firehose在将传入数据传送到指定目标之前对其进行缓冲。对于AmazonS3、AmazonRedshift和Splunk作为您选择的目的地，您可以选择1-128个MIB的缓冲区大小和60-900秒的缓冲区间隔。对于Amazon Elasticsearch作为您选择的目的地，您可以选择1–100 MIB的缓冲区大小和60–900秒的缓冲区间隔。对于HTTP端点目标，包括Datadog和New Relic，您可以选择1-64 MIB的缓冲区大小和60-900秒的缓冲区间隔。对于MongoDB云，您可以选择1-16个MIB的缓冲区大小和60-900秒的缓冲区间隔

从