2
従来のメッセージブローカーとストリーミングデータ
カフカのサイトによると： 「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データがあります。従来のメッセージブローカーを使用して処理する必要があります。 だから私は尋ねる：データ（またはそれ以外）がストリームプロセッサとメッセージブローカーの間の決定を導くのに役立つのは、どちらもストリーミングデータを処理でき、両方が（非ストリーミング）メッセージデータを処理できるからですか？