AWS Kinesis Firehose和Streams在處理時間上有任何不同嗎？

Question

通過閱讀兩種產品（Firehose和Streams）的文檔，聽起來Firehose實時「接近」，在產生消息和發佈消息之間可能會有60秒的延遲，而Streams文檔沒有提到這種潛力延遲。

有沒有人有任何關於消息傳遞時間差異的現實洞察？

[註釋]

鏈接到Firehose FAQ提的延遲，根據緩衝器大小爲S3事件。

Answer 1

它看起來像我一樣Kinesis Firehose是或多或少的緩衝區收集數據，直到緩衝區運行完整或其中最舊的消息是N秒（其中N由用戶配置;我認爲900秒是最大），此時整個緩衝區內容被寫入其目的地（例如S3）。與Streams不同，縮放無需擔心。

我無法對Kinesis Streams做出相當評論，因爲我沒有與他們合作過。但Streams不僅僅是分區鍵所建議的緩衝區。對於Firehose正在嘗試解決的同一問題採用不同的方法，但在處理它的方式/位置方面更加靈活。

也許這將是任何使用的神祕性什麼是什麼更好的比我可以:) https://www.sumologic.com/wp-content/uploads/DemystifyingAmazonKinesis_infographic.pdf

Answer 2

挖掘到這進一步後，我發現，在流水中，緩衝器/時間設置確實添加額外的延遲。然而，Firehose的用例（至少對我來說）並不正確。看起來，如果您可以允許延遲，那麼Firehose就是更簡單的方法，顯然如果您只是爲了下游分析而採集數據。對於實時，Kinesis Streams是前進的方向，因爲延遲取決於應用程序。

Answer 3

通過Kinesis Streams，您可以將處理時間縮短到一秒以內。在我目前的流中，Kinesis部分的延遲似乎爲5.5毫秒，而用Lambda函數處理記錄的延遲爲330毫秒。這是批量大小爲1，這意味着lambda函數處理記錄一個接一個。

Kinesis Streams可能有點貴。爲了節省一些資金，我在另一個具有更高吞吐量的流中使用了批量大小500。這增加了幾分鐘的延遲時間。

Firehose通常便宜很多，但功能也有限。如果您正在傳輸大量數據（超過1 MB /分鐘），則可以通過添加緩衝區大小提示將平均處理時間降至60秒以下。