従来のメッセージブローカーとストリーミングデータ

カフカのサイトによると：

「Kakfaは、リアルタイムデータパイプラインとストリーミングアプリの構築に使用されます。」

インターネットを広く検索して、「ストリームデータ」とは何かについて、一般に受け入れられている次の定義を見つけました。

• ストリームデータは、ネットワークを介してソースから宛先に連続して流れるデータです。そして
• ストリームデータは本質的にアトミックではありません。つまり、データのフローストリームのどの部分も意味があり、処理可能であることを意味します。そして
• ストリームデータはいつでも開始/停止できます。そして
• 消費者は自由にデータのストリームをアタッチおよびデタッチし、必要な部分だけを処理できます

さて、上で言ったことが間違っている、不完全である、または完全に間違っている場合、私を修正することから始めてください！多かれ少なかれ軌道に乗っていると仮定すると...

「ストリーミングデータ」が何であるかを理解したので、KafkaとKinesisがストリーミングデータを使用するアプリケーションの処理/仲介ミドルウェアとして自身に請求するときの意味を理解しました。しかし、それは私の興味をそそりました。KafkaやKinesisのような「ストリームミドルウェア」を、従来のメッセージブローカーのような非ストリーミングデータに使用できるかどうか。そしてその逆：RabbitMQ、ActiveMQ、Apolloなどの従来のMQをデータのストリーミングに使用できますか、または使用すべきですか？

アプリケーションが処理が必要なJSONメッセージのバックエンドの一定の集中砲火を送信する例を見てみましょう。処理はかなり複雑です（検証、データの変換、フィルタリング、集計など）。

• ケース＃1：メッセージは映画の各フレームです。これは、フレームデータといくつかのサポートメタデータを含むビデオフレームごとに1つのJSONメッセージです
• ケース＃2：メッセージは時系列データであり、おそらく時間の関数としての誰かのハートビートです。したがって、t = 1でのハートビートを表すメッセージ＃1が送信され、t = 2でのメッセージ＃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はまた、メッセージを失わないように多大な苦労をしています。ストリーミングビデオでは、通常UDPを使用し、ビデオを実行し続けるためにフレームをあちこちにドロップするコンテンツです。Kafka-backedプロセスのSLAは通常、正常な場合は数秒から数分、正常な場合は数時間から数日です。ストリーミングメディアのSLAは数十ミリ秒です。

Netflixは、Kafkaを使用して、1時間あたりテラバイトのビデオをトランスコードしてディスクに保存する内部システム内でフレームを移動できますが、画面に出荷することはできません。

ケース2：もちろん。私は雇用主でこのようにカフカを使用しています。

ケース3：この種のことにはKafkaを使用できますが、順序付けを維持するために不必要なオーバーヘッドを払っています。順序を気にしないので、おそらく別のシステムからさらにパフォーマンスを絞ることができます。ただし、会社がすでにKafkaクラスターを保守している場合は、別のメッセージングシステムの保守負担を負うのではなく、おそらく再利用するのが最善です。

Kafka / Kinesisはストリームとしてモデル化されています。ストリームには、メッセージとは異なるプロパティがあります。

• ストリームにはコンテキストがあります。彼らは秩序を持っています。ストリームにウィンドウ関数を適用できます。ストリーム内の各アイテムには意味がありますが、その周囲のコンテキストでより意味がある場合があります
• ストリームには順序があるため、これを使用して処理のセマンティクスに関する特定のステートメントを作成できます。例えば、Apache Tridentは、Kafkaストリームからコンシュームするときに1回だけのセマンティクスを持っていると思われます。
• 関数をストリームに適用できます。実際に消費せずにストリームを変換できます。ストリームを遅延消費できます。ストリームの一部をスキップできます。
• 本質的にKafkaでストリームを再生できますが、メッセージキューを（追加のソフトウェアなしで）再生することはできません。これは、データで何をしたいのかまだわからない場合に便利です。AIのトレーニングにも役立ちます。

一般に、オフラインストリーム処理にはKafkaを使用し、リアルタイムのクライアントサーバーメッセージにはメッセージキューを使用します。

ピボットからの使用例：

Kafka：Webサイトアクティビティトラッキング、メトリック、ログ集約、ストリーム処理、イベントソーシング、およびコミットログ

RabbitMQ：汎用メッセージング...。多くの場合、ユーザーが結果を待つ間、リソースを大量に消費する手順を実行せずに、Webサーバーがリクエストにすばやく応答できるようにします。AMQP 0-9-1、STOMP、MQTT、AMQP 1.0などの既存のプロトコルを使用する必要がある場合に使用します

両方を使用すると便利な場合があります！たとえば、ユースケース＃2で、これがペースメーカーからのデータストリームである場合、ペースメーカーにハートビートデータをRabbitMQメッセージキュー（MQTTなどのクールなプロトコルを使用）に送信させ、そこですぐに処理されますソースの心臓がまだ鼓動しているかどうかを確認します。これにより、ダッシュボードと緊急対応システムが強化されます。また、メッセージキューは時系列データをKafkaに格納し、時間の経過に伴うハートビートデータを分析できるようにします。たとえば、ハートビートストリームの傾向に注目して、心臓病を検出するアルゴリズムを実装できます。