ストリーム処理とメッセージ処理の違い

Question

ストリーム処理と従来のメッセージ処理の基本的な違いは何ですか？人々はkafkaはストリーム処理には良い選択だと言っていますが、本質的にkafkaはActivMQ、RabbitMQなどのメッセージングフレームワークです。

なぜ私たちは一般的にActiveMQがストリーム処理にも適しているとは言いません。

消費者がメッセージを消費するスピードは、それがストリームかどうかを判断しますか？

Answer 1

伝統的なメッセージ処理では、ほとんどの場合メッセージごとに個別の計算を適用します。

はストリーム処理では、（集計ようにと合流）同時に複数の入力ストリームと複数のレコード（すなわち、メッセージ）で複雑な操作を適用します。すなわち、自動的にそれらはすべての加入消費者に届けてしまった後にメッセージを削除 -

さらに、従来のメッセージングシステムは、「バックインタイム」に行くことができません。対照的に、Kafkaは、設定可能な時間の間、プルベースのモデル（すなわち、消費者がカフカからデータを引き出す）を使用するときにメッセージを保持する。これにより、消費者は複数回メッセージを「巻き戻し」、消費することができます。新しい消費者を追加すると、完全な履歴を読み取ることができます。これにより、より複雑なアプリケーションが可能になるため、ストリーム処理が可能になります。さらに、ストリーム処理は必ずしもリアルタイム処理ではなく、無限の入力ストリームを処理することです（有限の入力に適用されるバッチ処理とは対照的です）。

とカフカはカフカの接続およびストリームAPIを提供しています - それは（それはそれでこれを使用している場合でも、コアの）だけメッセージング/パブ・サブシステムストリーム処理プラットフォームでありません。

Answer 2

基本的にKafkaはActiveMQまたはRabbitMQに似たメッセージングフレームワークです。コンフルエントによってストリーミングが行われるようにカフカを取り入れる努力があります。

https://www.confluent.io/blog/introducing-kafka-streams-stream-processing-made-simple/

ストリーム処理について話すとき、なぜカフカは、画像に入ってきますか？

ストリーム処理フレームワークはdata.Inバッチ処理の入力と異なり、ファイルシステムに保存されているいくつかのファイルを持っていて、継続的にそれを処理し、いくつかのデータベースに格納します。 Spark、Stormなどのストリーム処理フレームワークでは、一部のセンサーデバイスからの連続入力が得られますが、ストリームフィードエンジンにはapiフィードとkafkaが使用されます。