両方の製品（FirehoseとStreams）のドキュメントを読むと、Firehoseはリアルタイムで「近く」のように聞こえるため、メッセージを生成するまでに60秒の遅れが生じる可能性がありますが、Streamsのドキュメントでは、ディレイ。AWS Kinesis FirehoseとStreamsの処理時間に違いはありますか？
メッセージの配信時間に関して、実際の洞察はありますか？
[ノート]
リンクFirehose FAQへS3イベントのバッファサイズに基づいて、遅延を言及します。
Kinesis Firehoseは、バッファがいっぱいになるまで、またはその中の最も古いメッセージがN秒前になるまで、データを収集するバッファーです（Nはユーザーによって構成され、900秒はバッファの内容全体が宛先に書き込まれます（例：S3）。スケーリングは、Streamsとは違って心配する必要はありません。
Kinesis Streamsは生産的に作業していないため、私はかなりコメントできません。しかし、Streamsは、パーティションキーで示唆されているように、バッファー以上のものです。同じ問題に対する別のアプローチFirehoseは解決しようとしていますが、どのように/どこで処理するかに柔軟性があります。
多分これは私はさらに、この掘り下げる後https://www.sumologic.com/wp-content/uploads/DemystifyingAmazonKinesis_infographic.pdf
を:)ことができるよりも何より良い何を分かりやすく説明するために、任意の使用されるであろう、私は消防ホースのバッファ/時間の設定が実際に追加の遅延を追加することを発見しました。しかし、Firehose（少なくとも私にとって）のユースケースは正しくありませんでした。レイテンシを許可しても問題ない場合、Firehoseはより簡単な方法であり、ダウンストリーム分析用のデータを取り込んでいる場合は明らかです。リアルタイムでは、レイテンシがアプリケーションに依存するため、Kinesis Streamsが前進しています。
キネシスストリームでは、処理時間を1秒未満にすることができます。私の現在のストリームでは、レイネスは、キネシスの部分では5.5ミリ秒、ラムダ関数では330ミリ秒と思われます。これはバッチサイズが1の場合です。つまり、ラムダ関数がレコードを1つずつ処理します。
キネシスストリームは少し高価です。私はいくつかのお金を節約するために、高いスループットで別のストリームでバッチサイズ500を使用しました。これにより数分の待ち時間が追加されました。
Firehoseは一般にはるかに安いですが、限られた機能も提供します。大量のデータ（1 MB /分以上）をストリーミングする場合は、バッファサイズヒントを追加することで、平均処理時間を60秒未満にすることができます。