Kafkaサイト によると:
「カクファは、リアルタイムデータパイプラインとストリーミングアプリの構築に使用されます。」
インターネットを広範囲にわたって検索したところ、「ストリームデータ」が次の一般的に受け入れられている定義であることがわかりました。
さて、私が上で言ったことが正しくない、不完全である、または完全に間違っている場合は、まず私を訂正してください!私が多かれ少なかれ軌道に乗っていると仮定すると、...
「ストリーミングデータ」とは何かが理解できたので、KafkaとKinesisが、ストリーミングデータを使用するアプリケーションの処理/ブローカーミドルウェアとして請求する場合の意味を理解しました。しかし、 KafkaまたはKinesisを従来のメッセージブローカーのような非ストリーミングデータに使用できますか?またはその逆:RabbitMQのような従来のMQを使用できます/すべきです、ActiveMQ、Apolloなどがデータのストリーミングに使用されますか?
アプリケーションが、処理が必要なJSONメッセージのバックエンドの一定の弾幕を送信し、処理がかなり複雑(検証、データの変換、フィルタリング、集計など)である例を見てみましょう。
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を使用し、リアルタイムのクライアント/サーバーメッセージにはメッセージキューを使用します。
pivotal の使用例:
Kafka:Webサイトアクティビティトラッキング、メトリック、ログ集計、ストリーム処理、イベントソーシング、コミットログ
RabbitMQ:汎用メッセージング...、多くの場合、ユーザーが結果を待つ間、リソースを大量に消費する手順を実行するのではなく、Webサーバーが要求にすばやく応答できるようにするために使用されます。 AMQP 0-9-1、STOMP、MQTT、AMQP 1.0などの既存のプロトコルを使用する必要がある場合に使用します
両方を使用すると便利な場合があります。たとえば、ユースケース#2で、これがペースメーカーからのデータストリームである場合、ペースメーカーに(MQTTのようなクールなプロトコルを使用して)RabbitMQメッセージキューにハートビートデータを送信させ、すぐに処理します。ソースの心臓がまだ鼓動しているかどうかを確認してください。これにより、ダッシュボードと緊急応答システムが強化されます。メッセージキューはまた、時系列データをKafkaにデポジットして、時間の経過とともにハートビートデータを分析できるようにします。たとえば、ハートビートストリームの傾向に気づくことで心臓病を検出するアルゴリズムを実装することができます。 。