従来のメッセージブローカーとストリーミングデータ
Kafkaサイト によると：
「カクファは、リアルタイムデータパイプラインとストリーミングアプリの構築に使用されます。」
インターネットを広範囲にわたって検索したところ、「ストリームデータ」が次の一般的に受け入れられている定義であることがわかりました。
- ストリームデータは、ネットワークを介して送信元から宛先に連続して流れるデータです。そして
- ストリームデータは本質的にアトミックではないであり、データのフローストリームのどの部分も意味があり、処理可能であることを意味します。それら;そして
- ストリームデータはいつでも開始/停止できます。そして
- 消費者は自由にデータのストリームに接続したり切り離したりでき、必要な部分だけを処理できます
さて、私が上で言ったことが正しくない、不完全である、または完全に間違っている場合は、まず私を訂正してください！私が多かれ少なかれ軌道に乗っていると仮定すると、...
「ストリーミングデータ」とは何かが理解できたので、KafkaとKinesisが、ストリーミングデータを使用するアプリケーションの処理/ブローカーミドルウェアとして請求する場合の意味を理解しました。しかし、 KafkaまたはKinesisを従来のメッセージブローカーのような非ストリーミングデータに使用できますか？またはその逆：RabbitMQのような従来のMQを使用できます/すべきです、ActiveMQ、Apolloなどがデータのストリーミングに使用されますか？
アプリケーションが、処理が必要なJSONメッセージのバックエンドの一定の弾幕を送信し、処理がかなり複雑（検証、データの変換、フィルタリング、集計など）である例を見てみましょう。
- ケース＃1：メッセージは映画の各フレームです。つまり、フレームデータといくつかのサポートメタデータを含むビデオフレームごとに1つのJSONメッセージです
- ケース＃2：メッセージは時系列データであり、おそらく時間の関数としての誰かの心拍です。したがって、メッセージ＃1はt = 1での私のハートビートを表し、メッセージ＃2はt = 2での私のハートビートを含む、というように送信されます。
- ケース＃3：データは完全に異種であり、時間によって、または「データストリーム」の一部として無関係です。おそらく、何百人ものユーザーがボタンをクリックしてアプリケーションをナビゲートし、アクションを実行するときに発生する監査/セキュリティイベント
Kafka/Kinesisの請求方法と、「ストリーミングデータ」とは何かについての私の理解に基づいて、それらはケース＃1（連続したビデオデータ）および＃2（連続した時系列データ）の明白な候補であるようです。ただし、RabbitMQなどの従来のメッセージブローカーがこれらの入力も効率的に処理できなかった理由は見当たらない。
ケース＃3では、発生したイベントのみが提供され、そのイベントへの反応を処理する必要があります。つまり、これは、RabbitMQのような従来のブローカーが必要であることを示しています。しかし、KafkaまたはKinesisがイベントデータの処理も処理できないようにすることができない理由もありません。
だから基本的に、私は言うルーブリックを確立しようとしています：Y特性を持つXデータがあります。それを処理するには、Kafka/Kinesisのようなストリームプロセッサを使用する必要があります。または、逆に、次のことを判断するのに役立つものを使用します：Z特性を持つWデータがあります。それを処理するには、従来のメッセージブローカーを使用する必要があります。
だから私は質問します：どちらがストリーミングデータを処理でき、両方が（非ストリーミング）メッセージデータを処理できるので、データに関する（またはその他の）要素はストリームプロセッサまたはメッセージブローカー間の決定を導くのに役立ちますか？
Kafkaは、アトミックメッセージの順序付けられたログを扱います。メッセージブローカーのpub/subモードのように表示できますが、厳密な順序と、ディスク上にまだ保持されている過去の任意の時点でメッセージのストリームを再生または検索する機能（永遠に）。
Kafkaのストリーミングスタンドのフレーバーは、ThriftやHTTPのようなリモートプロシージャコールや、Hadoopエコシステムのようなバッチ処理とは対照的です。 RPCとは異なり、コンポーネントは非同期に通信します。メッセージが送信されてから受信者が起動してメッセージを操作するまでに数時間または数日かかる場合があります。さまざまな時点で多くの受信者がいる可能性があります。または、誰もメッセージを消費することに煩わされることはないでしょう。複数のプロデューサが、コンシューマの知識なしに同じトピックをプロデュースする可能性があります。 Kafkaは、あなたがサブスクライブしているかどうか、またはメッセージが消費されたかどうかを知りません。メッセージはログにコミットされるだけで、関係者はそれを読むことができます。
バッチ処理とは異なり、メッセージの巨大なコレクションだけではなく、単一のメッセージに関心があります。 （KafkaメッセージをHDFS上のParquetファイルにアーカイブし、Hiveテーブルとしてクエリすることは珍しくありません）。
ケース1：Kafkaは、プロデューサーとコンシューマー間の特定の時間的関係を保持しません。Kafkaであるため、ストリーミングビデオには適していません。スローダウン、スピードアップ、フィットとスタートなどの移動が許可されています。ストリーミングメディアの場合、全体的なスループットを低く、より重要なのはstableレイテンシ（低ジッタとも呼ばれます）Kafkaは、メッセージを失わないようにするのにも非常に苦労します。ストリーミングビデオでは、通常UDPを使用し、フレームをドロップするコンテンツですビデオを実行し続けるためのあちこちにあります。SLA Kafka-backedプロセスの場合、通常、健全な場合は数秒から数分、健全な場合は数時間から数日です。SLA =ストリーミングメディアでは数十ミリ秒です。
Netflixは、Kafkaを使用して、1時間あたりテラバイトのビデオをトランスコードしてディスクに保存する内部システムでフレームを移動することができますが、画面に送信することはできません。
ケース2：もちろんです。私たちは雇用主でKafkaこのように使用しています。
ケース：この種の場合はKafkaを使用できますが、注文を維持するために不要なオーバーヘッドを払っています。気にしないので順序については、おそらく別のシステムからさらにパフォーマンスを引き出すことができます。ただし、会社がすでにKafkaクラスターを維持している場合は、別のメッセージングのメンテナンスの負担を負うのではなく、それを再利用するのがおそらく最善ですシステム。
Kafka/Kinesisはストリームとしてモデル化されています。ストリームには、メッセージとは異なるプロパティがあります。
- ストリームはそれらにコンテキストを持っています。彼らは秩序を持っています。ストリームにウィンドウ関数を適用できます。ストリーム内の各アイテムは意味がありますが、周囲のコンテキストにより意味がある場合があります
- ストリームには順序があるため、それを使用して処理のセマンティクスについて特定のステートメントを作成できます。例えば。 Kafkaストリームから消費する場合、Apache Tridentはおそらく1回だけのセマンティクスを持っています。
- ストリームに関数を適用できます。ストリームを実際に消費することなく変換できます。ストリームを遅延して消費できます。ストリームの一部をスキップできます。
- 本質的にKafkaでストリームを再生できますが、（追加のソフトウェアなしで）メッセージキューを再生することはできません。これは、データの処理方法がまだわからない場合に役立ちます。 AIのトレーニングにも役立ちます。
一般に、オフラインストリーム処理にはKafkaを使用し、リアルタイムのクライアント/サーバーメッセージにはメッセージキューを使用します。
pivotal の使用例：
Kafka：Webサイトアクティビティトラッキング、メトリック、ログ集計、ストリーム処理、イベントソーシング、コミットログ
RabbitMQ：汎用メッセージング...、多くの場合、ユーザーが結果を待つ間、リソースを大量に消費する手順を実行するのではなく、Webサーバーが要求にすばやく応答できるようにするために使用されます。 AMQP 0-9-1、STOMP、MQTT、AMQP 1.0などの既存のプロトコルを使用する必要がある場合に使用します
両方を使用すると便利な場合があります。たとえば、ユースケース＃2で、これがペースメーカーからのデータストリームである場合、ペースメーカーに（MQTTのようなクールなプロトコルを使用して）RabbitMQメッセージキューにハートビートデータを送信させ、すぐに処理します。ソースの心臓がまだ鼓動しているかどうかを確認してください。これにより、ダッシュボードと緊急応答システムが強化されます。メッセージキューはまた、時系列データをKafkaにデポジットして、時間の経過とともにハートビートデータを分析できるようにします。たとえば、ハートビートストリームの傾向に気づくことで心臓病を検出するアルゴリズムを実装することができます。 。