AWS Kinesis Firehose 和 Streams 之间的处理时间是否有任何区别?

Question

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

有没有人对消息传递时间的任何差异有任何现实世界的见解？

[注释]

链接到 Firehose 常见问题解答，其中提到了延迟，基于 S3 事件的缓冲区大小。

Answer 1

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

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

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

Answer 2

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

我不能完全评论Kinesis Streams，因为我没有与他们进行过富有成效的合作。但 Streams 不仅仅是分区键所建议的缓冲区。Firehose试图解决的同一问题的不同方法，但在处理方式/位置方面更加灵活。

也许这对揭开比我能:)更好的东西的神秘面纱有任何用处https://www.sumologic.com/wp-content/uploads/DemystifyingAmazonKinesis_infographic.pdf

Answer 3

这让我感到惊讶，促使我进行调查并报告我的发现。我见过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云，您可以选择1-16 MiB的缓冲区大小和60-900秒的缓冲间隔。

从配置设置

Answer 4

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